viernes, 21 de junio de 2019

Hetzner ¿Por qué nos has abandonado?

"Viendo Pilato que nada adelantaba, sino que se hacía más alboroto, tomó agua y se lavó las manos delante del pueblo, diciendo: Inocente soy yo de la sangre de este justo; allá vosotros."  Así versa Mateo 27:24 de la Biblia. Es este el famoso "yo me lavo las manos" de Poncio Pilato. Esto que ocurrió hace más de 2000 años.  Y cuando algunos hostings o registrantes de servidores se comportan como PIlato abandonando a su suerte a sus clientes, podemos hablar de que se está cometiendo un gran injusticia.



Esto es importante que lo tengáis en cuenta, si contratáis un servidor dedicado puede que la empresa con la que lo contratáis, en caso de fallos más graves no se haga cargo. Este es el caso de Hetzner. No es el único, es cierto ¿Cómo saber esto? Revisando en detenimiento el pliego de condiciones que cada empresa tiene. Este es el de Hetzner. El punto importante es el 7.



Hay veces que se lo puedes pelear, pues muchas veces son ambiguos como veis, pero el no por respuesta lo vais a tener siempre y os tocará a vosotros encargaros de solucionar el problema muchas veces, por lo que tened eso en cuenta antes de contratar un servicio.

Ahora voy a lo que nos ocurrió. Resulta que un día (no voy a contar lo que llevó a esa situación por temas de contratos de confidencialidad) me encontré con que una de las máquinas no arrancaba tras un reinicio que realizó una persona. Tocaba batallar.

Hetzner te posibilita que hagas un reinicio de hardware, pero no suele funcionar para problemas de este tipo. La solución está en algo que provocará que tengamos que dedicar aún más tiempo, activar el modo rescate de Hetzner.

Cuando hagamos esto, tendremos que reiniciar de nuevo la máquina desde Hetzner y, tras una hora más o menos, podríamos acceder de nuevo a nuestra máquina mediante ssh, pero tendremos que hacer algunas cosillas antes.

Eliminar las claves ssh de nuestro usuario para ese server

ssh-keygen -R [IP || DOMAIN]

Esto lo podemos hacer con ssh-keygen y especificando, tras la opción -R, la dirección IP o el dominio de nuestro servidor. Así eliminaremos nuestra clave, de lo contrario veremos un mensaje como el siguiente.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:vkmt7OOEhTDMfWwGIoaAZALq5PzJ2WGLp7zNlwCT1Lc.
Please contact your system administrator.
Add correct host key in /home/[USER]/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/[USER]/.ssh/known_hosts:27
  remove with:
  ssh-keygen -f "/home/[USER]/.ssh/known_hosts" -R [IP || DOMAIN]
ECDSA host key for [IP || DOMAIN] has changed and you have requested strict checking.
Host key verification failed.

Veremos que nos alertan de que posiblemente se esté haciendo un ataque de MiTM, pero nada más lejos de la realidad, es simplemente que la clave pública del servidor se ha eliminado y ya.

Una vez que hayamos hecho esto, tendremos que entrar como root y con la contraseña que Hetzner nos ha tenido que dar.

ls /dev/[hsv]d[a-z]*[0-9]*
/dev/sda1  /dev/sda2  /dev/sdb1  /dev/sdb2

Listaremos todo lo que nos encontremos en /dev/ con el objeto de encontrar los discos que hay disponibles. Yo me encontré por un lado sdaX y por otro sdbX, esto ya nos podía adelantar algo que nos iba a complicar un poco la tarea. Estamos tratando con un Raid 1. 

root@rescue ~ # lsblk
NAME           MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
loop0            7:0    0    3G  1 loop 
sda              8:0    0  1.8T  0 disk 
├─sda1           8:1    0    1G  0 part 
│ └─md0          9:0    0 1023M  0 raid1
└─sda2           8:2    0  1.8T  0 part 
  └─md1          9:1    0  1.8T  0 raid1
    ├─vg0-swap 253:0    0    6G  0 lvm  
    ├─vg0-root 253:1    0  100G  0 lvm  
    ├─vg0-home 253:2    0  100G  0 lvm  
    └─vg0-var  253:3    0   50G  0 lvm  
sdb              8:16   0  1.8T  0 disk 
├─sdb1           8:17   0    1G  0 part 
│ └─md0          9:0    0 1023M  0 raid1
└─sdb2           8:18   0  1.8T  0 part 
  └─md1          9:1    0  1.8T  0 raid1
    ├─vg0-swap 253:0    0    6G  0 lvm  
    ├─vg0-root 253:1    0  100G  0 lvm  
    ├─vg0-home 253:2    0  100G  0 lvm  
    └─vg0-var  253:3    0   50G  0 lvm  
root@rescue ~ #

Aquí ya nos cercioramos al mirar nuestras particiones. Estamos ante un Raid 1 con copias en espejo de sdaX a sdbX.

root@rescue ~ # mount /dev/sda2 /mnt/
mount: unknown filesystem type 'linux_raid_member'
root@rescue ~ #

Si intentamos montar las particiones, veremos que nos da un error, pero eso es porque tenemos que utiliza mdadm.

root@rescue ~ # mdadm --misc --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Fri Apr 20 16:15:38 2018
     Raid Level : raid1
     Array Size : 1047552 (1023.00 MiB 1072.69 MB)
  Used Dev Size : 1047552 (1023.00 MiB 1072.69 MB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Sat Jun 15 08:27:19 2019
          State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
  Spare Devices : 0

           Name : rescue:0  (local to host rescue)
           UUID : e6d2aa64:9661614c:b957b84f:6c1cf49d
         Events : 65

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1

Tendremos que informarnos muy bien, por lo que vamos a mostrar información detallada con el anterior comando.  No obstante, esta información no nos va a ser suficiente.

root@rescue ~ # cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sda2[0] sdb2[1]
      1952332864 blocks super 1.2 [2/2] [UU]
      bitmap: 0/15 pages [0KB], 65536KB chunk

md0 : active raid1 sda1[0] sdb1[1]
      1047552 blocks super 1.2 [2/2] [UU]
     
unused devices: <none>
root@rescue ~ #

Podemos mirar también en el archivo /proc/mdstat, pero lo que obtenemos nuevamente es que tenemos un raid el cual tendremos que montar junto a sus particiones para recuperar los datos, copiarlos y restablecerlos en una nueva máquina. 

root@rescue ~ # mdadm --assemble /dev/md0 /dev/sdb1
mdadm: /dev/sdb1 is busy - skipping
root@rescue ~ # mdadm --assemble /dev/md0 /dev/sdb2
mdadm: /dev/sdb2 is busy - skipping
root@rescue ~ #

No nos haría falta, pero se nos podría ocurrir montar nuestro sistema con mdadm desde /dev/md0 a los distintos discos. Pero veremos que no podemos hacerlo. 

root@rescue ~ # pvscan; vgscan; vgchange -a y
  PV /dev/md1   VG vg0             lvm2 [1.82 TiB / 1.57 TiB free]
  Total: 1 [1.82 TiB] / in use: 1 [1.82 TiB] / in no VG: 0 [0   ]
  Reading volume groups from cache.
  Found volume group "vg0" using metadata type lvm2
  4 logical volume(s) in volume group "vg0" now active
root@rescue ~ #

 Las buenas noticias salen cuando lanzamos pvscan, vgscan y vgchange y vemos que localiza el volumen vg0, es una buena noticia, solamente tendremos que buscar /dev/vg0 y montar las particiones.

root@rescue ~ # ls -ltrah /dev/vg0
total 0
lrwxrwxrwx  1 root root    7 Jun 15 08:28 var -> ../dm-3
drwxr-xr-x 17 root root 7.8K Jun 15 08:28 ..
lrwxrwxrwx  1 root root    7 Jun 15 08:28 home -> ../dm-2
lrwxrwxrwx  1 root root    7 Jun 15 08:28 swap -> ../dm-0
lrwxrwxrwx  1 root root    7 Jun 15 08:28 root -> ../dm-1
drwxr-xr-x  2 root root  120 Jun 15 08:28 .
root@rescue ~ #


Ahí las tenemos, es una buena noticia, por lo que recuperaremos los datos de var, home y root simplemente creando dichas carpetas bajo /mnt y y montando ahí las particiones.

root@rescue /mnt # mkdir var
root@rescue /mnt # mkdir home
root@rescue /mnt # mkdir root
root@rescue /mnt # mount /dev/vg0/home /mnt/home
root@rescue /mnt # mount /dev/vg0/var /mnt/var
root@rescue /mnt # mount /dev/vg0/root /mnt/root
root@rescue /mnt # ls -ltrah
total 12K
drwxr-xr-x 13 root root 4.0K Apr 23  2018 var
drwxr-xr-x 23 root root 4.0K Apr 23  2018 root
drwxr-xr-x  9 root root 4.0K Apr  7 20:45 home
drwxr-xr-x  1 root root  180 Jun 15 08:27 ..
drwxr-xr-x  1 root root  100 Jun 15 12:37 .
root@rescue /mnt # 

Hemos salvado los datos que es lo más importante. Sólo nos queda pasarlos, para esto es ideal contar con un servidor propio de copias de seguridad. Si lo tenemos, lo ideal es lanzar rsync para copiar todos los directorios (comprobar que se mantengan los permisos, es importante), ya que rsync es bastante más rápido que scp, y ante archivos y directorios de este tipo (muy pesados) es lo mejor para reducir tiempos.

Todo esto hay que saberlo o estamos expuestos pues, como he mencionado, Hetzner (y otros muchos proveedores de servidores) no se hacen cargo, algo que considero una total irresponsabilidad, pero sobre esto, ya hablaré en otro artículo y sobre el por qué esto no es más que el interés del capital nuevamente.

¿Hackeamos el Mundo?

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...