administrosistemas.com | Guías y notas de un administrador de sistemas

Eliminar partición de disco GPT o MSDOS con «parted» de Linux

De Killall el 18 julio, 2017 · Add Comment

Vamos a suponer que tenemos un servidor con una partición de SWAP que queremos eliminar, no la necesitamos.

root@admsistemas:~# ls -lh /dev/sda*                                          
brw-rw---- 1 root disk 8, 0 Jul 18 10:50 /dev/sda
brw-rw---- 1 root disk 8, 1 Jul 18 10:50 /dev/sda1
brw-rw---- 1 root disk 8, 2 Jul 18 10:50 /dev/sda2
brw-rw---- 1 root disk 8, 2 Jul 18 10:50 /dev/sda5


root@admsistemas:~# parted -l /dev/sda
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    Type      File system     Flags
 1      1049kB  20.4GB  20.4GB  primary   ext4            boot
 2      20.4GB  21.5GB  1072MB  extended
 5      20.4GB  21.5GB  1072MB  logical   linux-swap(v1)


root@admsistemas:~# free -m
              total        used        free      shared  buff/cache   available
Mem:            996          30         776           1         189         832
Swap:          1021           0        1021

root@admsistemas:~# ls -lh /dev/sda*

brw-rw---- 1 root disk 8, 0 Jul 18 10:50 /dev/sda

brw-rw---- 1 root disk 8, 1 Jul 18 10:50 /dev/sda1

brw-rw---- 1 root disk 8, 2 Jul 18 10:50 /dev/sda2

brw-rw---- 1 root disk 8, 2 Jul 18 10:50 /dev/sda5

root@admsistemas:~# parted -l /dev/sda

Model: ATA VBOX HARDDISK (scsi)

Disk /dev/sda: 21.5GB

Sector size (logical/physical): 512B/512B

Partition Table: gpt

Disk Flags:

Number Start End Size Type File system Flags

1 1049kB 20.4GB 20.4GB primary ext4 boot

2 20.4GB 21.5GB 1072MB extended

5 20.4GB 21.5GB 1072MB logical linux-swap(v1)

root@admsistemas:~# free -m

total used free shared buff/cache available

Mem: 996 30 776 1 189 832

Swap: 1021 0 1021

Primero, vamos a desmontar la SWAP.

root@admsistemas:~# swapoff -a



root@admsistemas:~# free -m
              total        used        free      shared  buff/cache   available
Mem:            996          30         777           1         188         832
Swap:             0           0           0

root@admsistemas:~# swapoff -a

root@admsistemas:~# free -m

total used free shared buff/cache available

Mem: 996 30 777 1 188 832

Swap: 0 0 0

Para eliminar la partición 5 que corresponde a la SWAP, vamos a usar la herramienta parted.

root@admsistemas:~# apt-get update && apt-get install -y parted

1	root@admsistemas:~# apt-get update && apt-get install -y parted

Empezamos:

# Podemos ejecutar directamente "parted" o especificar el dispositivo "parted /dev/sda"
# Sino especificamos nada, por defecto será /dev/sda


root@admsistemas:~# parted
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) help                                                             
  align-check TYPE N                        check partition N for TYPE(min|opt) alignment
  help [COMMAND]                           print general help, or help on COMMAND
  mklabel,mktable LABEL-TYPE               create a new disklabel (partition table)
  mkpart PART-TYPE [FS-TYPE] START END     make a partition
  name NUMBER NAME                         name partition NUMBER as NAME
  print [devices|free|list,all|NUMBER]     display the partition table, available devices, free space, all found partitions, or a particular partition
  quit                                     exit program
  rescue START END                         rescue a lost partition near START and END
  resizepart NUMBER END                    resize partition NUMBER
  rm NUMBER                                delete partition NUMBER
  select DEVICE                            choose the device to edit
  disk_set FLAG STATE                      change the FLAG on selected device
  disk_toggle [FLAG]                       toggle the state of FLAG on selected device
  set NUMBER FLAG STATE                    change the FLAG on partition NUMBER
  toggle [NUMBER [FLAG]]                   toggle the state of FLAG on partition NUMBER
  unit UNIT                                set the default unit to UNIT
  version                                  display the version number and copyright information of GNU Parted


# Podemos cambiar de dispositivo en cualquier momento dentro de 'parted'
(parted) select /dev/sda                                                  
Using /dev/sda


# Listamos las particiones del dispositivo seleccionado.
(parted) print                                                            
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    Type      File system     Flags
 1      1049kB  20.4GB  20.4GB  primary   ext4            boot
 2      20.4GB  21.5GB  1072MB  extended
 5      20.4GB  21.5GB  1072MB  logical   linux-swap(v1)


# Borramos la partición 5, corresponde a la antigua SWAP
(parted) rm 5


# Volvemos a listar la tabla de particiones, ahora sin la 5
(parted) print
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type      File system  Flags
 1      1049kB  20.4GB  20.4GB  primary   ext4         boot
 2      20.4GB  21.5GB  1072MB  extended


# Salimos, automáticamente se guarda
(parted) quit                                                             
Information: You may need to update /etc/fstab.

# Podemos ejecutar directamente "parted" o especificar el dispositivo "parted /dev/sda"

# Sino especificamos nada, por defecto será /dev/sda

root@admsistemas:~# parted

GNU Parted 3.2

Using /dev/sda

Welcome to GNU Parted! Type 'help' to view a list of commands.

(parted) help

align-check TYPE N check partition N for TYPE(min|opt) alignment

help [COMMAND] print general help, or help on COMMAND

mklabel,mktable LABEL-TYPE create a new disklabel (partition table)

mkpart PART-TYPE [FS-TYPE] START END make a partition

name NUMBER NAME name partition NUMBER as NAME

print [devices|free|list,all|NUMBER] display the partition table, available devices, free space, all found partitions, or a particular partition

quit exit program

rescue START END rescue a lost partition near START and END

resizepart NUMBER END resize partition NUMBER

rm NUMBER delete partition NUMBER

select DEVICE choose the device to edit

disk_set FLAG STATE change the FLAG on selected device

disk_toggle [FLAG] toggle the state of FLAG on selected device

set NUMBER FLAG STATE change the FLAG on partition NUMBER

toggle [NUMBER [FLAG]] toggle the state of FLAG on partition NUMBER

unit UNIT set the default unit to UNIT

version display the version number and copyright information of GNU Parted

# Podemos cambiar de dispositivo en cualquier momento dentro de 'parted'

(parted) select /dev/sda

Using /dev/sda

# Listamos las particiones del dispositivo seleccionado.

(parted) print

Model: ATA VBOX HARDDISK (scsi)

Disk /dev/sda: 21.5GB

Sector size (logical/physical): 512B/512B

Partition Table: gpt

Disk Flags:

Number Start End Size Type File system Flags

1 1049kB 20.4GB 20.4GB primary ext4 boot

2 20.4GB 21.5GB 1072MB extended

5 20.4GB 21.5GB 1072MB logical linux-swap(v1)

# Borramos la partición 5, corresponde a la antigua SWAP

(parted) rm 5

# Volvemos a listar la tabla de particiones, ahora sin la 5

(parted) print

Model: ATA VBOX HARDDISK (scsi)

Disk /dev/sda: 21.5GB

Sector size (logical/physical): 512B/512B

Partition Table: msdos

Disk Flags:

Number Start End Size Type File system Flags

1 1049kB 20.4GB 20.4GB primary ext4 boot

2 20.4GB 21.5GB 1072MB extended

# Salimos, automáticamente se guarda

(parted) quit

Information: You may need to update /etc/fstab.

Eso es todo, podemos verificar como el sistema ya no detecta la partición 5 de la antigua SWAP.

root@admsistemas:~# ls -lh /dev/sda*                                          
brw-rw---- 1 root disk 8, 0 Jul 18 15:56 /dev/sda
brw-rw---- 1 root disk 8, 1 Jul 18 15:56 /dev/sda1
brw-rw---- 1 root disk 8, 2 Jul 18 15:56 /dev/sda2

root@admsistemas:~# ls -lh /dev/sda*

brw-rw---- 1 root disk 8, 0 Jul 18 15:56 /dev/sda

brw-rw---- 1 root disk 8, 1 Jul 18 15:56 /dev/sda1

brw-rw---- 1 root disk 8, 2 Jul 18 15:56 /dev/sda2

Cifrar password de usuarios en el dashboard de HAProxy

De Killall el 11 enero, 2017 · Add Comment

La configuración básica de HAProxy permite añadir el listado de usuarios que tendrá acceso al dashboard para ver el estado del servicio, los nodos del backend, estadísticas, etc.

Un ejemplo de configuración básico de usuarios para HAProxy: vi /etc/haproxy/haproxy.cfg

userlist STATSUSERS
        group admin users admin
        user admin insecure-password mi_passwd_texto_plano

userlist STATSUSERS

group admin users admin

user admin insecure-password mi_passwd_texto_plano

Siguiendo la documentación propia de HAProxy para la versión 1.5.X, sección 3.4 «Userlists»:
http://www.haproxy.org/download/1.5/doc/configuration.txt

Ahora vamos a cifrar el anterior password con SHA-512.

sysadmin@admsistemas:~$ mkpasswd -m sha-512 mi_passwd_texto_plano
$6$IRdTDaxv$l7oq.3BsfwcgvVmD4fAntv7XASVpqQPyvXE02aW08RUNvQBASJLCrzlv..tqmXjHLWXBmp6I1.9kjCf9a8Z1h1

1 2	sysadmin@admsistemas:~$ mkpasswd -m sha-512 mi_passwd_texto_plano $6$IRdTDaxv$l7oq.3BsfwcgvVmD4fAntv7XASVpqQPyvXE02aW08RUNvQBASJLCrzlv..tqmXjHLWXBmp6I1.9kjCf9a8Z1h1

Ahora cambiamos la configuración del haproxy.cfg fácilmente con:

userlist STATSUSERS
        group admin users admin
        user admin password $6$IRdTDaxv$l7oq.3BsfwcgvVmD4fAntv7XASVpqQPyvXE02aW08RUNvQBASJLCrzlv..tqmXjHLWXBmp6I1.9kjCf9a8Z1h1

userlist STATSUSERS

group admin users admin

user admin password $6$IRdTDaxv$l7oq.3BsfwcgvVmD4fAntv7XASVpqQPyvXE02aW08RUNvQBASJLCrzlv..tqmXjHLWXBmp6I1.9kjCf9a8Z1h1

Por último, no olvidar hacer un reload del servicio HAProxy para aplicar los cambios.

Ver con el comando bash ‘watch’ otro comando que es un alias de bash

De Killall el 1 octubre, 2016 · Add Comment

Anteriormente vimos como crear alias de comandos bash, para agilizar nuestro trabajo, ya sea acortando comandos largos, comandos muy habituales u otras necesidades que puedan aparecernos.

Vamos a ver un ejemplo utilizando un alias del siguiente comando:

sysadmin@admsistemas:~$ alias ll='ls -alF'

sysadmin@admsistemas:~/Desktop$ ll 
total 9148 
drwxr-xr-x  3 sysadmin sysadmin    4096 set 28 09:52 ./ 
drwxr-xr-x 44 sysadmin sysadmin    4096 oct  1 12:16 ../ 
-rw-rw-r--  1 sysadmin sysadmin     825 set 19 11:20 1.png 
-rw-rw-r--  1 sysadmin sysadmin  590675 set 19 12:16 Dark.png 
-rw-rw-r--  1 sysadmin sysadmin    2360 ago 22 16:51 PHPInfo 
drwxrwxr-x  3 sysadmin sysadmin    4096 ago 24 17:19 WPTest/

sysadmin@admsistemas:~$ alias ll='ls -alF'

sysadmin@admsistemas:~/Desktop$ ll

total 9148

drwxr-xr-x 3 sysadmin sysadmin 4096 set 28 09:52 ./

drwxr-xr-x 44 sysadmin sysadmin 4096 oct 1 12:16 ../

-rw-rw-r-- 1 sysadmin sysadmin 825 set 19 11:20 1.png

-rw-rw-r-- 1 sysadmin sysadmin 590675 set 19 12:16 Dark.png

-rw-rw-r-- 1 sysadmin sysadmin 2360 ago 22 16:51 PHPInfo

drwxrwxr-x 3 sysadmin sysadmin 4096 ago 24 17:19 WPTest/

Es habitual ver la salida de algunos comandos cada ‘x‘ segundos, para ver si hay cambios, si nuestro automatización crea nuevos archivos, si aparecen nuevas conexiones, etc. Todo esto sin necesidad de ejecutar el comando cada momento, podemos usar el comando watch, que se encarga de ir ejecutando el comando cada ‘x‘ segundos, por defecto hará intervalos de 2 segundos.

Pero el comando watch no funciona al ejecutar comandos que son alias de bash:

sysadmin@admsistemas:~$ watch ll

Every 2,0s: ll                                                                                                                                                                            Sat Oct  1 12:21:58 2016 

sh: 1: ll: not found

sysadmin@admsistemas:~$ watch ll

Every 2,0s: ll Sat Oct 1 12:21:58 2016

sh: 1: ll: not found

Así que para poderlo utilizar hay un workarround, hay que crear otro alias de watch con un espacio al final:

sysadmin@admsistemas:~$ alias watch='watch '


sysadmin@admsistemas:~/Desktop$ watch ll

Every 2,0s: ls --color=auto -alF                                                                                                                                                          Sat Oct  1 12:26:28 2016 
 
total 9148 
drwxr-xr-x  3 sysadmin sysadmin    4096 set 28 09:52 ./ 
drwxr-xr-x 44 sysadmin sysadmin    4096 oct  1 12:21 ../ 
-rw-rw-r--  1 sysadmin sysadmin     825 set 19 11:20 1.png 
-rw-rw-r--  1 sysadmin sysadmin  590675 set 19 12:16 Dark.png 
-rw-rw-r--  1 sysadmin sysadmin    2360 ago 22 16:51 PHPInfo 
drwxrwxr-x  3 sysadmin sysadmin    4096 ago 24 17:19 WPTest/

sysadmin@admsistemas:~$ alias watch='watch '

sysadmin@admsistemas:~/Desktop$ watch ll

Every 2,0s: ls --color=auto -alF Sat Oct 1 12:26:28 2016

total 9148

drwxr-xr-x 3 sysadmin sysadmin 4096 set 28 09:52 ./

drwxr-xr-x 44 sysadmin sysadmin 4096 oct 1 12:21 ../

-rw-rw-r-- 1 sysadmin sysadmin 825 set 19 11:20 1.png

-rw-rw-r-- 1 sysadmin sysadmin 590675 set 19 12:16 Dark.png

-rw-rw-r-- 1 sysadmin sysadmin 2360 ago 22 16:51 PHPInfo

drwxrwxr-x 3 sysadmin sysadmin 4096 ago 24 17:19 WPTest/

Conectarse por SSH a instancia de CoreOS de un clúster Kubernetes en AWS

De Killall el 1 octubre, 2016 · Add Comment

Hace unos días vimos como desplegar un clúster de Kubernetes con el sistema operativo CoreOS en Amazon Web Services (AWS).

El despliegue lo hicimos con la herramienta kube-aws que nos facilita la tarea. Igualmente eso no nos impide a conectarnos por SSH a las instancias desplegadas y poder ver configuraciones o ajustar parámetros, etc.

En el archivo cluster.yaml configuramos el parámetro:

keyName: miclave_admsistemas

1	keyName: miclave_admsistemas

Esta clave será una de las que tenemos creadas en EC2 y será la que nos va a permitir conectarnos por SSH, bastará con hacerlo con la clave privada, usuario ‘core‘ y la IP pública:

sysadmin@admsistemas:~$ ssh -i coreaws.pem core@52.211.197.243
CoreOS stable (1122.2.0)
Last login: Sat Oct  1 09:35:14 2016 from 79.152.96.151
Update Strategy: No Reboots


core@ip-10-0-0-132 ~ $ sudo su
ip-10-0-0-132 core # whoami
root
ip-10-0-0-132 core # pwd
/home/core


ip-10-0-0-132 core # ls -l /
total 120
lrwxrwxrwx.   1 root root     7 Sep  6 15:00 bin -> usr/bin
drwxr-xr-x.   6 root root 16384 Jan  1  1970 boot
drwxr-xr-x.  15 root root  2780 Sep 26 06:21 dev
drwxr-xr-x.  41 root root  4096 Sep 26 06:21 etc
drwxr-xr-x.   3 root root  4096 Sep  6 15:00 home
lrwxrwxrwx.   1 root root     5 Sep  6 15:02 lib -> lib64
lrwxrwxrwx.   1 root root     9 Sep  6 15:00 lib64 -> usr/lib64
drwx------.   2 root root 16384 Sep  6 15:00 lost+found
drwxrwxrwt.   2 root root    40 Sep 26 06:21 media
drwxr-xr-x.   2 root root  4096 Sep  6 15:00 mnt
drwxr-xr-x.   3 root root  4096 Sep 26 06:21 opt
dr-xr-xr-x. 114 root root     0 Sep 26 06:21 proc
drwx------.   2 root root  4096 Sep  6 15:00 root
drwxr-xr-x.  24 root root   620 Sep 26 06:21 run
-rw-r--r--.   1 root root     0 Sep 26 06:21 s0:c206,c530
-rw-r--r--.   1 root root     0 Sep 26 06:21 s0:c352,c368
-rw-r--r--.   1 root root     0 Sep 26 06:22 s0:c385,c880
lrwxrwxrwx.   1 root root     8 Sep  6 15:00 sbin -> usr/sbin
drwxr-xr-x.   2 root root  4096 Sep 26 06:21 srv
dr-xr-xr-x.  13 root root     0 Sep 26 06:21 sys
drwxrwxrwt.   8 root root   160 Sep 26 06:22 tmp
drwxr-xr-x.  10 root root  4096 Sep  6 15:05 usr
drwxr-xr-x.   9 root root  4096 Sep 26 06:21 var

sysadmin@admsistemas:~$ ssh -i coreaws.pem core@52.211.197.243

CoreOS stable (1122.2.0)

Last login: Sat Oct 1 09:35:14 2016 from 79.152.96.151

Update Strategy: No Reboots

core@ip-10-0-0-132 ~ $ sudo su

ip-10-0-0-132 core # whoami

root

ip-10-0-0-132 core # pwd

/home/core

ip-10-0-0-132 core # ls -l /

total 120

lrwxrwxrwx. 1 root root 7 Sep 6 15:00 bin -> usr/bin

drwxr-xr-x. 6 root root 16384 Jan 1 1970 boot

drwxr-xr-x. 15 root root 2780 Sep 26 06:21 dev

drwxr-xr-x. 41 root root 4096 Sep 26 06:21 etc

drwxr-xr-x. 3 root root 4096 Sep 6 15:00 home

lrwxrwxrwx. 1 root root 5 Sep 6 15:02 lib -> lib64

lrwxrwxrwx. 1 root root 9 Sep 6 15:00 lib64 -> usr/lib64

drwx------. 2 root root 16384 Sep 6 15:00 lost+found

drwxrwxrwt. 2 root root 40 Sep 26 06:21 media

drwxr-xr-x. 2 root root 4096 Sep 6 15:00 mnt

drwxr-xr-x. 3 root root 4096 Sep 26 06:21 opt

dr-xr-xr-x. 114 root root 0 Sep 26 06:21 proc

drwx------. 2 root root 4096 Sep 6 15:00 root

drwxr-xr-x. 24 root root 620 Sep 26 06:21 run

-rw-r--r--. 1 root root 0 Sep 26 06:21 s0:c206,c530

-rw-r--r--. 1 root root 0 Sep 26 06:21 s0:c352,c368

-rw-r--r--. 1 root root 0 Sep 26 06:22 s0:c385,c880

lrwxrwxrwx. 1 root root 8 Sep 6 15:00 sbin -> usr/sbin

drwxr-xr-x. 2 root root 4096 Sep 26 06:21 srv

dr-xr-xr-x. 13 root root 0 Sep 26 06:21 sys

drwxrwxrwt. 8 root root 160 Sep 26 06:22 tmp

drwxr-xr-x. 10 root root 4096 Sep 6 15:05 usr

drwxr-xr-x. 9 root root 4096 Sep 26 06:21 var

Desactivar usuario FTP del ProFTPD sin necessidad de eliminar el usuario, trabajando con mod_sql

De Killall el 28 septiembre, 2016 · Add Comment

Podemos trabajar con el servicio ProFTPD con el modulo mod_sql, para tener usuarios virtuales y obtener las credenciales de una base de datos. Este sistema será válido tanto para FTP como SFTP.

La estructura de las tablas SQL que nos proponen inicialmente no permite tener usuarios dados de alta, pero inactivos a nivel de servicio, sin permitir su autenticación.

Así que haremos unos pequeños cambios, primero modificando la tabla SQL:

ALTER TABLE `ftpuser` ADD `LoginAllowed` VARCHAR(3) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT 'yes' AFTER `shell`;

1	ALTER TABLE `ftpuser` ADD `LoginAllowed` VARCHAR(3) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT 'yes' AFTER `shell`;

Para acabar, debemos tener un archivo sql.conf similar a este:

SQLAuthenticate users* groups*
SQLConnectInfo  ftpusr@IP_MYSQL ftpdb MI_PASSWD_SQL
SQLUserInfo     ftpuser userid passwd uid gid homedir shell
SQLGroupInfo    ftpgroup groupname gid members

SQLAuthenticate users* groups*

SQLConnectInfo ftpusr@IP_MYSQL ftpdb MI_PASSWD_SQL

SQLUserInfo ftpuser userid passwd uid gid homedir shell

SQLGroupInfo ftpgroup groupname gid members

Y añadiremos la línea SQLUserWhereClause, quedando así:

SQLAuthenticate users* groups*
SQLConnectInfo  ftpusr@IP_MYSQL ftpdb MI_PASSWD_SQL
SQLUserInfo     ftpuser userid passwd uid gid homedir shell
SQLUserWhereClause "LoginAllowed = 'yes'"
SQLGroupInfo    ftpgroup groupname gid members

SQLAuthenticate users* groups*

SQLConnectInfo ftpusr@IP_MYSQL ftpdb MI_PASSWD_SQL

SQLUserInfo ftpuser userid passwd uid gid homedir shell

SQLUserWhereClause "LoginAllowed = 'yes'"

SQLGroupInfo ftpgroup groupname gid members

Ahora ya podemos desactivar cuentas FTP, cuando haga falta únicamente habrá que cambiar el campo LoginAllowed, por ejemplo así:

UPDATE ftpuser SET LoginAllowed='no' WHERE userid='ftp_user_client';

1	UPDATE ftpuser SET LoginAllowed='no' WHERE userid='ftp_user_client';

Arrancar contenedor Docker con un Debian básico sin ningún servicio en marcha, solo un terminal bash

De Killall el 26 septiembre, 2016 · Add Comment

Generalmente los contenedores Docker se usan para arrancar servicios como Nginx, Apache, PHP-FPM, Redis, etc. Estos servicios se basan en entornos Alpine Linux, Debian u otros.

Cuando el contenedor arrancar con un servicio, su PID será el 1, pero si queremos realizar pruebas con un Debian pelado sin servicios.
¿Como vamos a arrancarlo sin que se nos pare el contenedor Docker?

Muy fácil, vamos a arrancar un contenedor Docker de la imagen base de Debian, lanzando un terminal bash como proceso principal.

sysadmin@admsistemas:~$ docker run -it --name "deb" -d debian:8 bash
Unable to find image 'debian:8' locally
8: Pulling from library/debian
6a5a5368e0c2: Pull complete 
Digest: sha256:677f184a5969847c0ad91d30cf1f0b925cd321e6c66e3ed5fbf9858f58425d1a
Status: Downloaded newer image for debian:8
bea274ef0e24fb0ad3a8abe918dd533858a7c4e69f54be0a48124c0a85a1444e


sysadmin@admsistemas:~$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
bea274ef0e24        debian:8            "bash"              44 seconds ago      Up 43 seconds                           deb

sysadmin@admsistemas:~$ docker run -it --name "deb" -d debian:8 bash

Unable to find image 'debian:8' locally

8: Pulling from library/debian

6a5a5368e0c2: Pull complete

Digest: sha256:677f184a5969847c0ad91d30cf1f0b925cd321e6c66e3ed5fbf9858f58425d1a

Status: Downloaded newer image for debian:8

bea274ef0e24fb0ad3a8abe918dd533858a7c4e69f54be0a48124c0a85a1444e

sysadmin@admsistemas:~$ docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

bea274ef0e24 debian:8 "bash" 44 seconds ago Up 43 seconds deb

Ahora podemos ver como el PID número 1 corresponde a un terminal bash, pero si entramos dentro del contenedor vamos a abrir un bash independiente, con lo cual si salimos y entramos no se detendrá el contenedor al no finalizar el PID 1. Nuestro bash dentro del contenedor para trabajar y realizar pruebas será el que tiene PID 7.

sysadmin@admsistemas:~$ docker exec -it deb bash
root@bea274ef0e24:/# ps faux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         7  1.0  0.0  20244  3120 ?        Ss   16:28   0:00 bash
root        13  0.0  0.0  17496  2084 ?        R+   16:28   0:00  \_ ps faux
root         1  0.0  0.0  20244  3076 ?        Ss+  16:28   0:00 bash
root@bea274ef0e24:/# exit


sysadmin@admsistemas:~$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
bea274ef0e24        debian:8            "bash"              6 minutes ago       Up 6 minutes                            deb

sysadmin@admsistemas:~$ docker exec -it deb bash

root@bea274ef0e24:/# ps faux

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND

root 7 1.0 0.0 20244 3120 ? Ss 16:28 0:00 bash

root 13 0.0 0.0 17496 2084 ? R+ 16:28 0:00 \_ ps faux

root 1 0.0 0.0 20244 3076 ? Ss+ 16:28 0:00 bash

root@bea274ef0e24:/# exit

sysadmin@admsistemas:~$ docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

bea274ef0e24 debian:8 "bash" 6 minutes ago Up 6 minutes deb

Modificar kubectl para trabajar con otro clúster de Kubernetes, cambiar «current-context»

De Killall el 26 septiembre, 2016 · Add Comment

El binario kubectl nos permite trabajar con un clúster de Kubernetes, ver PODs, RCs, SVC, crearlos, eliminarlos, ver logs u otras tareas.

Por otro lado solo nos permite trabajar con un clúster a la vez, es decir si queremos trabajar con otro clúster debemos cambiar de contexto.

Podemos ver las configuraciones con el propio binario o también en nuestro home: ~/.kube/config

sysadmin@admsistemas:~$ kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://146.148.11.113
  name: gke_admsistemas_europe-west1-d_cluster1
- cluster:
    certificate-authority-data: REDACTED
    server: https://130.211.57.89
  name: gke_admsistemas_europe-west1-d_cluster2
contexts:
- context:
    cluster: gke_admsistemas_europe-west1-d_cluster1
    user: gke_admsistemas_europe-west1-d_cluster1
  name: gke_admsistemas_europe-west1-d_cluster1
- context:
    cluster: gke_admsistemas_europe-west1-d_cluster2
    user: gke_admsistemas_europe-west1-d_cluster2
  name: gke_admsistemas_europe-west1-d_cluster2
current-context: gke_admsistemas_europe-west1-d_cluster2
kind: Config
preferences: {}
users:
- name: gke_admsistemas_europe-west1-d_cluster1
  user:
    auth-provider:
      config:
        access-token: ya29.CjBqAxlv9HTLZUPgR_JAmYkyHT5RpZRvt88ZoL_D0wybNvsBM8sbJZOUrKEFpooQ-R0
        expiry: 2016-09-26T13:54:32.888407166+02:00
      name: gcp
- name: gke_admsistemas_europe-west1-d_cluster2
  user:
    auth-provider:
      config:
        access-token: ya29.CjBqA6juqDyOSdK8DtnQQIotYEifuj6ygmuWHopEA7iRcxPGdyVp-JL2XVJrLfCYeIo
        expiry: 2016-09-26T18:52:44.504249617+02:00
      name: gcp

sysadmin@admsistemas:~$ kubectl config view

apiVersion: v1

clusters:

- cluster:

certificate-authority-data: REDACTED

server: https://146.148.11.113

- cluster:

certificate-authority-data: REDACTED

server: https://130.211.57.89

contexts:

- context:

cluster: gke_admsistemas_europe-west1-d_cluster1

user: gke_admsistemas_europe-west1-d_cluster1

- context:

cluster: gke_admsistemas_europe-west1-d_cluster2

user: gke_admsistemas_europe-west1-d_cluster2

current-context: gke_admsistemas_europe-west1-d_cluster2

kind: Config

preferences: {}

users:

- name: gke_admsistemas_europe-west1-d_cluster1

user:

auth-provider:

config:

access-token: ya29.CjBqAxlv9HTLZUPgR_JAmYkyHT5RpZRvt88ZoL_D0wybNvsBM8sbJZOUrKEFpooQ-R0

expiry: 2016-09-26T13:54:32.888407166+02:00

- name: gke_admsistemas_europe-west1-d_cluster2

user:

auth-provider:

config:

access-token: ya29.CjBqA6juqDyOSdK8DtnQQIotYEifuj6ygmuWHopEA7iRcxPGdyVp-JL2XVJrLfCYeIo

expiry: 2016-09-26T18:52:44.504249617+02:00

En este instante, el clúster de trabajo actual lo podemos ver reflejado aquí:

sysadmin@admsistemas:~$ kubectl config view | grep "current-context"
current-context: gke_admsistemas_europe-west1-d_cluster2


sysadmin@admsistemas:~$ kubectl get nodes
NAME                                       STATUS    AGE
gke-cluster2-default-pool-2edef98b-s7bd   Ready     6d

sysadmin@admsistemas:~$ kubectl config view | grep "current-context"

current-context: gke_admsistemas_europe-west1-d_cluster2

sysadmin@admsistemas:~$ kubectl get nodes

NAME STATUS AGE

gke-cluster2-default-pool-2edef98b-s7bd Ready 6d

Y ahora cambiamos el clúster de trabajo actual para kubectl con el siguiente comando:

sysadmin@admsistemas:~$ kubectl config use-context gke_admsistemas_europe-west1-d_cluster1
switched to context "gke_admsistemas_europe-west1-d_cluster1".


sysadmin@admsistemas:~$ kubectl config view | grep "current-context"
current-context: gke_admsistemas_europe-west1-d_cluster1


sysadmin@admsistemas:~$ kubectl get nodes
NAME                                STATUS    AGE
gke-admsistemas-pool-1-0fdc0081-orq8   Ready     21d

sysadmin@admsistemas:~$ kubectl config use-context gke_admsistemas_europe-west1-d_cluster1

switched to context "gke_admsistemas_europe-west1-d_cluster1".

sysadmin@admsistemas:~$ kubectl config view | grep "current-context"

current-context: gke_admsistemas_europe-west1-d_cluster1

sysadmin@admsistemas:~$ kubectl get nodes

NAME STATUS AGE

gke-admsistemas-pool-1-0fdc0081-orq8 Ready 21d

Recibir X-Forwarded-For en backend HTTP con un LoadBalancer de Google Cloud en Kubernetes

De Killall el 24 septiembre, 2016 · Add Comment

Este tema me ha llevado bastante quebraderos de cabeza y hoy voy a explicar qué pasa y como recibir en la cabecera HTTP el X-Forwarded-For.

El objetivo es obtener la IP real del cliente origen cuando tenemos un LoadBalancer de Google Cloud en su Kubernetes con Container Engine. Ya que sino es así todos los logs de Apache/Nginx del backend van a registrar la IP interna del LoadBalancer y no tendremos la IP real del cliente, haciendo imposible por ejemplo la generación de estadísticas reales de visitas.

Cuando levantamos un Service (SVC) de Kubernetes lo hacemos de la siguiente manera:

apiVersion: v1
kind: Service
metadata:
  name: nginx-back
  labels:
    company: Admsistemas
spec:
  type: LoadBalancer
  ports:
     - port: 80
       name: nginx80
       protocol: TCP
  selector:
    name: nginx-back

apiVersion: v1

kind: Service

metadata:

labels:

company: Admsistemas

spec:

type: LoadBalancer

ports:

- port: 80

protocol: TCP

selector:

El «type: LoadBalancer» va aprovisionar un LoadBalancer de la plataforma de GCP directamente a nuestro ReplicationController asignado con el «selector».

Este LoadBalancer va a ser del tipo TCP y ese será el motivo real por el cual no vayamos a recibir la cabecera X-Forwarded-For.

Esto no sucede igual en AWS, que quizás por defecto levantan un LoadBalancer HTTP así que en GCP hay que hacerlo de otro modo.

Así que el objetivo será levantar un LoadBalancer HTTP de la plataforma de GCP, eso lo haremos con Ingress de Kubernetes.

Vamos a modificar nuestro SVC actual cambiando el «type: LoadBalancer» por «type: NodePort«, aplicamos las nuevas configuraciones.

sysadmin@admsistemas:~$ kubectl get svc
NAME                    CLUSTER-IP      EXTERNAL-IP      PORT(S)             AGE
kubernetes              10.27.240.1     <none>           443/TCP             39d
nginx-back              10.27.254.176   104.199.19.129   80/TCP              1m


sysadmin@admsistemas:~$ kubectl describe svc nginx-back
Name:                   nginx-back
Namespace:              default
Labels:                 company=Admsistemas
Selector:               name=nginx-back
Type:                   LoadBalancer
IP:                     10.27.254.176
LoadBalancer Ingress:   104.199.19.129
Port:                   nginx80     80/TCP
NodePort:               nginx80     31778/TCP
Endpoints:              10.24.1.4:80
Session Affinity:       None
Events:
  FirstSeen     LastSeen        Count   From                    SubobjectPath   Type            Reason                  Message
  ---------     --------        -----   ----                    -------------   --------        ------                  -------
  1m            1m              1       {service-controller }                   Normal          CreatingLoadBalancer    Creating load balancer
  49s           49s             1       {service-controller }                   Normal          CreatedLoadBalancer     Created load balancer


sysadmin@admsistemas:~$ kubectl apply -f nginx-back-svc.yaml 
service "nginx-back" configured


sysadmin@admsistemas:~$ kubectl get svc
NAME                    CLUSTER-IP      EXTERNAL-IP      PORT(S)             AGE
kubernetes              10.27.240.1     <none>           443/TCP             39d
nginx-back              10.27.254.176   <nodes>          80/TCP              2m


sysadmin@admsistemas:~$ kubectl describe svc nginx-back
Name:                   nginx-back
Namespace:              default
Labels:                 company=Admsistemas
Selector:               name=nginx-back
Type:                   NodePort
IP:                     10.27.254.176
Port:                   nginx80     80/TCP
NodePort:               nginx80     31778/TCP
Endpoints:              10.24.1.4:80
Session Affinity:       None
Events:
  FirstSeen     LastSeen        Count   From                    SubobjectPath   Type            Reason                  Message
  ---------     --------        -----   ----                    -------------   --------        ------                  -------
  4m            4m              1       {service-controller }                   Normal          CreatingLoadBalancer    Creating load balancer
  3m            3m              1       {service-controller }                   Normal          CreatedLoadBalancer     Created load balancer
  2m            2m              1       {service-controller }                   Normal          Type                    LoadBalancer -> NodePort
  2m            2m              1       {service-controller }                   Normal          DeletingLoadBalancer    Deleting load balancer
  1m            1m              1       {service-controller }                   Normal          DeletedLoadBalancer     Deleted load balancer

sysadmin@admsistemas:~$ kubectl get svc

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE

kubernetes 10.27.240.1 <none> 443/TCP 39d

nginx-back 10.27.254.176 104.199.19.129 80/TCP 1m

sysadmin@admsistemas:~$ kubectl describe svc nginx-back

Name: nginx-back

Namespace: default

Labels: company=Admsistemas

Selector: name=nginx-back

Type: LoadBalancer

IP: 10.27.254.176

LoadBalancer Ingress: 104.199.19.129

Port: nginx80 80/TCP

NodePort: nginx80 31778/TCP

Endpoints: 10.24.1.4:80

Session Affinity: None

Events:

FirstSeen LastSeen Count From SubobjectPath Type Reason Message

--------- -------- ----- ---- ------------- -------- ------ -------

1m 1m 1 {service-controller } Normal CreatingLoadBalancer Creating load balancer

49s 49s 1 {service-controller } Normal CreatedLoadBalancer Created load balancer

sysadmin@admsistemas:~$ kubectl apply -f nginx-back-svc.yaml

service "nginx-back" configured

sysadmin@admsistemas:~$ kubectl get svc

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE

kubernetes 10.27.240.1 <none> 443/TCP 39d

nginx-back 10.27.254.176 <nodes> 80/TCP 2m

sysadmin@admsistemas:~$ kubectl describe svc nginx-back

Name: nginx-back

Namespace: default

Labels: company=Admsistemas

Selector: name=nginx-back

Type: NodePort

IP: 10.27.254.176

Port: nginx80 80/TCP

NodePort: nginx80 31778/TCP

Endpoints: 10.24.1.4:80

Session Affinity: None

Events:

FirstSeen LastSeen Count From SubobjectPath Type Reason Message

--------- -------- ----- ---- ------------- -------- ------ -------

4m 4m 1 {service-controller } Normal CreatingLoadBalancer Creating load balancer

3m 3m 1 {service-controller } Normal CreatedLoadBalancer Created load balancer

2m 2m 1 {service-controller } Normal Type LoadBalancer -> NodePort

2m 2m 1 {service-controller } Normal DeletingLoadBalancer Deleting load balancer

1m 1m 1 {service-controller } Normal DeletedLoadBalancer Deleted load balancer

Ahora ya tenemos un SVC nginx-back que va a ser únicamente accesible desde dentro del clúster de Kubernetes. No tendremos visibilidad desde el exterior.

Para ello vamos a crear un Ingress que va aprovisionar un LoadBalancer HTTP en GCP. Vamos a crear un YAML nuevo: vi nginx-back-ing.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-back
spec:
  backend:
    serviceName: nginx-back
    servicePort: 80

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

spec:

backend:

serviceName: nginx-back

servicePort: 80

Ahora debemos tener un poco de paciencia para que se aprovisione correctamente el LoadBalancer HTTP e ir observando los cambios.

sysadmin@admsistemas:~$ kubectl create -f nginx-back-ing.yaml 
ingress "nginx-back" created


sysadmin@admsistemas:~$ kubectl get ing
NAME            HOSTS     ADDRESS   PORTS     AGE
nginx-back      *                   80        6s


# Esperamos un poco mas y ya tendremos IP pública assignada
sysadmin@admsistemas:~$ kubectl get ing
NAME            HOSTS     ADDRESS          PORTS     AGE
nginx-back      *         130.211.42.153   80        1m


sysadmin@admsistemas:~$ kubectl describe ing nginx-back
Name:                   nginx-back
Namespace:              default
Address:                130.211.42.153
Default backend:        nginx-back:80 (10.24.1.4:80)
Rules:
  Host  Path    Backends
  ----  ----    --------
  *     *       nginx-back:80 (10.24.1.4:80)
Annotations:
  backends:             {"k8s-be-31778--8e50d4941921ec0b":"Unknown"}
  forwarding-rule:      k8s-fw-default-nginx-back--8e50d4941921ec0b
  target-proxy:         k8s-tp-default-nginx-back--8e50d4941921ec0b
  url-map:              k8s-um-default-nginx-back--8e50d4941921ec0b
Events:
  FirstSeen     LastSeen        Count   From                            SubobjectPath   Type            Reason  Message
  ---------     --------        -----   ----                            -------------   --------        ------  -------
  1m            1m              1       {loadbalancer-controller }                      Normal          ADD     default/nginx-back
  28s           28s             1       {loadbalancer-controller }                      Normal          CREATE  ip: 130.211.42.153

sysadmin@admsistemas:~$ kubectl create -f nginx-back-ing.yaml

ingress "nginx-back" created

sysadmin@admsistemas:~$ kubectl get ing

NAME HOSTS ADDRESS PORTS AGE

nginx-back * 80 6s

# Esperamos un poco mas y ya tendremos IP pública assignada

sysadmin@admsistemas:~$ kubectl get ing

NAME HOSTS ADDRESS PORTS AGE

nginx-back * 130.211.42.153 80 1m

sysadmin@admsistemas:~$ kubectl describe ing nginx-back

Name: nginx-back

Namespace: default

Address: 130.211.42.153

Default backend: nginx-back:80 (10.24.1.4:80)

Rules:

Host Path Backends

---- ---- --------

* * nginx-back:80 (10.24.1.4:80)

Annotations:

backends: {"k8s-be-31778--8e50d4941921ec0b":"Unknown"}

forwarding-rule: k8s-fw-default-nginx-back--8e50d4941921ec0b

target-proxy: k8s-tp-default-nginx-back--8e50d4941921ec0b

url-map: k8s-um-default-nginx-back--8e50d4941921ec0b

Events:

FirstSeen LastSeen Count From SubobjectPath Type Reason Message

--------- -------- ----- ---- ------------- -------- ------ -------

1m 1m 1 {loadbalancer-controller } Normal ADD default/nginx-back

28s 28s 1 {loadbalancer-controller } Normal CREATE ip: 130.211.42.153

Hasta que la línea «backends» de la sección «Annotations» no aparezca como HEALTHY no será 100% funcional nuestro LoadBalancer HTTP en GCP con Ingress de Kubernetes.

sysadmin@admsistemas:~$ kubectl describe ing nginx-back
Name:                   nginx-back
Namespace:              default
Address:                130.211.42.153
Default backend:        nginx-back:80 (10.24.1.4:80)
Rules:
  Host  Path    Backends
  ----  ----    --------
  *     *       nginx-back:80 (10.24.1.4:80)
Annotations:
  backends:             {"k8s-be-32374--8e50d4941921ec0b":"HEALTHY"}
  forwarding-rule:      k8s-fw-default-nginx-back--8e50d4941921ec0b
  target-proxy:         k8s-tp-default-nginx-back--8e50d4941921ec0b
  url-map:              k8s-um-default-nginx-back--8e50d4941921ec0b
Events:
  FirstSeen     LastSeen        Count   From                            SubobjectPath   Type            Reason  Message
  ---------     --------        -----   ----                            -------------   --------        ------  -------
  18m           18m             1       {loadbalancer-controller }                      Normal          ADD     default/nginx-back
  17m           17m             1       {loadbalancer-controller }                      Normal          CREATE  ip: 130.211.42.153

sysadmin@admsistemas:~$ kubectl describe ing nginx-back

Name: nginx-back

Namespace: default

Address: 130.211.42.153

Default backend: nginx-back:80 (10.24.1.4:80)

Rules:

Host Path Backends

---- ---- --------

* * nginx-back:80 (10.24.1.4:80)

Annotations:

backends: {"k8s-be-32374--8e50d4941921ec0b":"HEALTHY"}

forwarding-rule: k8s-fw-default-nginx-back--8e50d4941921ec0b

target-proxy: k8s-tp-default-nginx-back--8e50d4941921ec0b

url-map: k8s-um-default-nginx-back--8e50d4941921ec0b

Events:

FirstSeen LastSeen Count From SubobjectPath Type Reason Message

--------- -------- ----- ---- ------------- -------- ------ -------

18m 18m 1 {loadbalancer-controller } Normal ADD default/nginx-back

17m 17m 1 {loadbalancer-controller } Normal CREATE ip: 130.211.42.153

Recuperar un clúster MariaDB Galera después de un apagado general, galera_recovery

De Killall el 9 septiembre, 2016 · Add Comment

Suponemos el caso que tenemos un clúster MariaDB Galera con 3 nodos en la misma infraestructura. Puede darse el caso que haya un problema de electricidad y se detengan todos los nodos de golpe.

Cuando vuelvan a arrancar los nodos, cada nodo intentará sincronizarse con los demás nodos que tampoco estarán levantados y no arrancará nuestro clúster.

En este instante es cuando tenemos que decidir cual es el nodo que ha realizado el último commit (INSERT / UPDATE) y tiene los datos mas actualizados.

Para ello basta con ejecutar el mismo binario en todos los nodos, este se encargará de buscar el número del último commit. De los 3 nodos, el que tenga el número mas alto debe ser el que haga el bootstrap para arrancar el clúster de MariaDB Galera.

sysadmin@nodo1:~$ galera_recovery 
2016-09-09 17:02:26 140470984587200 [Note] /usr/sbin/mysqld (mysqld 10.1.17-MariaDB-1~jessie) starting as process 5968 ...
WSREP: Recovered position dbc1469f-4f20-11e6-82a1-9fad63d0e2ba:26289
--wsrep_start_position=dbc1469f-4f20-11e6-82a1-9fad63d0e2ba:26289


sysadmin@nodo2:~$
2016-09-09 17:02:28 140470984587200 [Note] /usr/sbin/mysqld (mysqld 10.1.17-MariaDB-1~jessie) starting as process 5968 ...
WSREP: Recovered position dbc1469f-4f20-11e6-82a1-9fad63d0e2ba:26288
--wsrep_start_position=dbc1469f-4f20-11e6-82a1-9fad63d0e2ba:26288


sysadmin@nodo3:~$
2016-09-09 17:02:30 140470984587200 [Note] /usr/sbin/mysqld (mysqld 10.1.17-MariaDB-1~jessie) starting as process 5968 ...
WSREP: Recovered position dbc1469f-4f20-11e6-82a1-9fad63d0e2ba:26287
--wsrep_start_position=dbc1469f-4f20-11e6-82a1-9fad63d0e2ba:26287

sysadmin@nodo1:~$ galera_recovery

2016-09-09 17:02:26 140470984587200 [Note] /usr/sbin/mysqld (mysqld 10.1.17-MariaDB-1~jessie) starting as process 5968 ...

WSREP: Recovered position dbc1469f-4f20-11e6-82a1-9fad63d0e2ba:26289

--wsrep_start_position=dbc1469f-4f20-11e6-82a1-9fad63d0e2ba:26289

sysadmin@nodo2:~$

2016-09-09 17:02:28 140470984587200 [Note] /usr/sbin/mysqld (mysqld 10.1.17-MariaDB-1~jessie) starting as process 5968 ...

WSREP: Recovered position dbc1469f-4f20-11e6-82a1-9fad63d0e2ba:26288

--wsrep_start_position=dbc1469f-4f20-11e6-82a1-9fad63d0e2ba:26288

sysadmin@nodo3:~$

2016-09-09 17:02:30 140470984587200 [Note] /usr/sbin/mysqld (mysqld 10.1.17-MariaDB-1~jessie) starting as process 5968 ...

WSREP: Recovered position dbc1469f-4f20-11e6-82a1-9fad63d0e2ba:26287

--wsrep_start_position=dbc1469f-4f20-11e6-82a1-9fad63d0e2ba:26287

El nodo1 es el que tiene el commit mas alto, 26289 y este es el candidato a levantar el clúster en primera instancia.

sysadmin@nodo1:~$ galera_new_cluster 
 
# Verificamos que el nodo está activo (Primary)
sysadmin@nodo1:~$ mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_status';"
Enter password: 
+----------------------+---------+
| Variable_name        | Value   |
+----------------------+---------+
| wsrep_cluster_status | Primary |
+----------------------+---------+
 
# Verificamos el tamaño del clúster, solo 1 nodo
sysadmin@nodo1:~$ mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';"
Enter password: 
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+

sysadmin@nodo1:~$ galera_new_cluster

# Verificamos que el nodo está activo (Primary)

sysadmin@nodo1:~$ mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_status';"

Enter password:

+----------------------+---------+

| Variable_name | Value |

+----------------------+---------+

| wsrep_cluster_status | Primary |

+----------------------+---------+

# Verificamos el tamaño del clúster, solo 1 nodo

sysadmin@nodo1:~$ mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';"

Enter password:

+--------------------+-------+

| Variable_name | Value |

+--------------------+-------+

| wsrep_cluster_size | 1 |

+--------------------+-------+

Bastará con realizar el bootstrap del nodo1 siguiendo estas indicaciones:

Realizar bootstrap de un clúster MariaDB Galera con systemd en Debian 8 Jessie, galera_new_cluster

Por último, podemos arrancar los otros dos nodos de la forma habitual con systemd.

sysadmin@nodo2:~$ systemctl start mysql

sysadmin@nodo3:~$ systemctl start mysql

# Verificamos el tamaño del cĺúster, debería ser de 3
sysadmin@nodo1:~$ mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';"
Enter password: 
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

sysadmin@nodo2:~$ systemctl start mysql

sysadmin@nodo3:~$ systemctl start mysql

# Verificamos el tamaño del cĺúster, debería ser de 3

sysadmin@nodo1:~$ mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';"

Enter password:

+--------------------+-------+

| Variable_name | Value |

+--------------------+-------+

| wsrep_cluster_size | 3 |

+--------------------+-------+

-1

Realizar bootstrap de un clúster MariaDB Galera con systemd en Debian 8 Jessie, galera_new_cluster

De Killall el 9 septiembre, 2016 · Add Comment

En versiones anteriores de Debian se utilizaba init como gestor de arranque de los procesos, pero a partir de Debian 8 Jessie se ha cambiado por el gestor systemd.

Eso ha hecho que cambiara el método para realizar el bootstrap (inicializar) un clúster de base de datos MariaDB Galera. Es decir, arrancar el primer nodo de una agrupación.

En versiones anteriores de Debian, bastaba con ejecutar en el primer nodo:

sysadmin@admsistemas:~$ /etc/init.d/mysql bootstrap

1	sysadmin@admsistemas:~$ /etc/init.d/mysql bootstrap

Pero con Debian 8 Jessie y la llegada de systemd eso ha dejado de funcionar.

sysadmin@admsistemas:~$ systemctl bootstrap mysql
Unknown operation 'bootstrap'.

1 2	sysadmin@admsistemas:~$ systemctl bootstrap mysql Unknown operation 'bootstrap'.

La gente de MariaDB ha añadido un excelente binario que facilita la tarea y fácil de recordar: galera_new_cluster

sysadmin@admsistemas:~$ galera_new_cluster 

# Verificamos que el nodo está activo (Primary)
sysadmin@admsistemas:~$ mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_status';"
Enter password: 
+----------------------+---------+
| Variable_name        | Value   |
+----------------------+---------+
| wsrep_cluster_status | Primary |
+----------------------+---------+

# Verificamos el tamaño del clúster, solo 1 nodo
sysadmin@admsistemas:~$ mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';"
Enter password: 
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+

sysadmin@admsistemas:~$ galera_new_cluster

# Verificamos que el nodo está activo (Primary)

sysadmin@admsistemas:~$ mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_status';"

Enter password:

+----------------------+---------+

| Variable_name | Value |

+----------------------+---------+

| wsrep_cluster_status | Primary |

+----------------------+---------+

# Verificamos el tamaño del clúster, solo 1 nodo

sysadmin@admsistemas:~$ mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';"

Enter password:

+--------------------+-------+

| Variable_name | Value |

+--------------------+-------+

| wsrep_cluster_size | 1 |

+--------------------+-------+

Eliminar partición de disco GPT o MSDOS con «parted» de Linux

Cifrar password de usuarios en el dashboard de HAProxy

Ver con el comando bash ‘watch’ otro comando que es un alias de bash

Conectarse por SSH a instancia de CoreOS de un clúster Kubernetes en AWS

Desactivar usuario FTP del ProFTPD sin necessidad de eliminar el usuario, trabajando con mod_sql

Arrancar contenedor Docker con un Debian básico sin ningún servicio en marcha, solo un terminal bash

Modificar kubectl para trabajar con otro clúster de Kubernetes, cambiar «current-context»

Recibir X-Forwarded-For en backend HTTP con un LoadBalancer de Google Cloud en Kubernetes

Recuperar un clúster MariaDB Galera después de un apagado general, galera_recovery

Realizar bootstrap de un clúster MariaDB Galera con systemd en Debian 8 Jessie, galera_new_cluster

Síguenos en Twitter

Entradas populares

Entradas aleatorias

Entradas recientes

Categorías

Archivos

Meta

Hosting patrocinado

Síguenos en Twitter

Entradas populares

Entradas aleatorias

Entradas recientes

Nube de etiquetas

Categorías

Archivos

Meta

Hosting patrocinado

Esta web usa cookies