Podcast: Descargar (Duración: 1:08:03 — 65.0MB)
Cambiar el nombre de una máquina
En distribuciones anteriores, NO basadas todavía en systemd se hacía así:
Ubuntu:
Editar como root el fichero /etc/hostname y el /etc/hosts tras lo cual reiniciamos la máquina.
RedHat/Centos:
Editar el archivo /etc/sysconfig/network (típica pregunta de Certificación en Linux).
… HOSTNAME=nombre_del_host …
Hay que reiniciar la máquina. Requiere downtime ¡ojo!
El comando hostname también permitía cambiar el nombre de la máquina pero no de forma permanente. Al reinicar, este nuevo nombre puesto con el comando hostname, desaparecía y volvía al original.
En distribuciones más modernas ya SI basadas en systemd se hace así:
Tanto en Ubuntu como en RedHat/Centos
hostnamectl set-hostname (intro)
Un sencillo logoff y logon y veremos el nuevo nombre de la máquina ya disponible.
No requiere reinicio, no hay por tanto downtime. Eso es una vantaja con respecto a versiones anteriores
Problema: Muy contentos pero hemos metido la pata ja ja ja y hasta el fondo.
Vino como una tarea de Service Now o Remedy. El cambio que hemos hecho tiene un impacto considerable…. Teníamos que haber rechazado este encargo en principio.
- Este cambio de nombre no lleva asociado otra tarea de cambio en DNS.
- Este cambio de nombre no lleva asociado un cambio en la CMDB.
- ¿Monitoring, Backup, etc. están enterados de este cambio?
No debería haber llegado como una tarea sino como un cambio con varias tareas asociadas.
TAREA PARA DNS TAREA PARA CMDB TAREA PARA LINUX Y una tarea de verificación… que vea el revisor vía nslookup / dig la nueva resolución, vía Service Now que el nuevo ítem aparece en la CMDB, en Linux ejecutar hostname y verificar el nuevo nombre…. Cerrar el cambio…
Las cosas no son tan fáciles como parecen a primera vista… más aun…
Después hablar con el cliente no se hace nada de lo anterior…. Ja ja ja Sorprendente!!!
¡¡ Un sencillo alias en el DNS resolvería el problema del cliente !!
Cambiar el nombre de una máquina en entornos grandes y no tan grandes tiene un serio impacto, antes de “lucirnos” en la capa de Linux abrir un investigación y consultar a los equipos implicados.
DEBIDO A UNA MIGRACION EN UN ENTORNO CRITICO, NOS PIDEN COPIAR DE UN HOST A OTRO UNA CONSIDERABLE CANTIDAD DE DATOS (MEDIO TERA, POR EJEMPLO).Se sospecha de que la copia ha podido fallar en algún archivo.
Primera manera:
# scp -pr /dir/origen/* hostdestino:/dir/destino echo $?
0
-p’ Preserves modification times, access times, and modes from the original file.
-r’ Recursively copy entire directories. Note that scp follows symbolic links encountered in the tree traversal
Host origen: centos-1 Host destino: centos-2
Primera manera:
En origen, centos-1:
# tree /documentum/files/data/ ó # ls –ltR /documentum/files/data echar un vistazo a lo que voy a copiar
# du -bsh /documentum/files/data/ ver los megas/gigas que voy a copiar
En destino, centos-2
#cd /documentum/files/data/ ; df –hP .
¿Hay espacio suficiente en el destino?
¡¡¡ Todo OK, me lanzo !!!
Primera manera:
# time scp -pr /documentum/files/data/* centos-2: /documentum/files/data/
…. Tarda un buen rato y se va observando el progreso, el comando time me informa del tiempo que tarda en ejecutarse el comando…
# echo $? 0
Eso 0 denota que el comando anterior se ejecutó correctamente. Implica copia correcta?
Supongamos que tarda poco más de una hora. Veo que todo OK y cierro mi tarea. Comunico al coordinador del cambio y líder de la migración que mi parte ya está hecha. Me da las gracias y nosotros Felices…
A las dos horas me suena el móvil y me preguntan que si se ha copiado todo bien. JA JA JA
Ese echo $? No es garantía de que en ese medio Tera que hemos copiado no se haya corrompido algo. Son miles de archivos quizá alguno se ha truncado y el comando scp no lo ha visto.
¡¡¡No ponemos manos a la obra!!! Vamos a generar tres evidencias A, B y C !!!
A.- Cuento en origen y destino el nro. de ficheros y directorios:
find /documentum/files/data/ -type f|wc –l 48980 find /documentum/files/data/ -type d|wc –l 42620 …….. [root@centos-2 data]# hostname en host destino centos-2 find /documentum/files/data/ -type f|wc –l 48980 find /documentum/files/data/ -type d|wc –l 42620
Ya sabemos que no es porque algo no se ha copiado.
B.- Saco un informe en origen y destino de lo cheksusm de cada fichero
En origen centos-1: md5 checksums de todos los archivos y de forma recursiva
Desde /documentum/files/data/
find -type f \( -not -name "checklist_origen.chk" \) -exec md5sum '{}' \; > checklist_origen.chkson miles de archivos pero de aquel o aquellos que se sospeche bastara comparar sus checksums
En destino centos-2: md5 checksums de todos los archivos y de forma recursiva
Desde /documentum/files/data/
find -type f \( -not -name "checklist_destino.chk" \) -exec md5sum '{}' \; > checklist_destino.chkRecordemos que cuando nos bajamos una ISO por ejemplo no dan en el portal de descarcas el checksum del fichero. Si tras descargarlo el checksum calculado con el comando md5sum es el mismo, inferimos que en la descarga el fichero no se ha corrompido y es realmente una copia exacta del original.
C.- Vamos a montar el directorio /documentum/files/data/ de centos-2 en el directorio /mnt de centos-1
# sudo yum update
# sudo yum install sshfs
# sshfs root@centos-2:/documentum/files/data /mnt
Vamos a demostrar de forma irrefutable que /documentum/files/data en centos-1 y /mnt, que es realmente /documentum/files/data en centos-2 son idénticos.
# diff -rq --no-dereference /documentum/files/data/ /mnt
Si no hay salida es que ambos directorios, son idénticos y si alguno difiere informa de ello. Informa que archivo o archivos son diferentes en ambos lados.
Segunda manera (con rsync): En vez de scp usamos rsync, aporta ventajas.
# rsync -ravz /documentum/files/data/ centos-2:/documentum/files/data --log-file=FILE
Picardía: día u horas antes lo lanzo y luego cuando me toque lo vuelvo a lanzar… lo que no haya cambiado no se copia de nuevo y se gana tiempo.
Ventajas – -log-file y solo copia las diferencias podemos lanzarlo antes de nuestro turno en el cambio y dejarlo acabar… cuando nos toque de verdad se saltará lo que ya este copiado, podemos así ahorrar mucho tiempo.
Las evidencias de los pasos A, B y C se aportan al cliente en Service Now. Si se ha producido un error, será en otra fase del cambio y NO en la nuestra. Se lo demostramos al cliente y normalizamos este proceder para el futuro.
Sobreponernos a un kernel panic después de un parcheo o actualización del Kernel.
/boot [root@iscsi boot]# uname -r 3.10.0-1127.8.2.el7.x86_64 [root@iscsi boot]# ls … initramfs-3.10.0-1127.8.2.el7.x86_64.img vmlinuz-3.10.0-1127.8.2.el7.x86_64 …
Suponemos que el fichero de imagen initramfs no se ha generado correctamente o sencillamente está ausente. Esta causará un kernel panic.
Por cada kernel vmlinuz-3.10.0-1127.8.2.el7.x86_64 tiene que haber un initramfs-3.10.0-1127.8.2.el7.x86_64.img
Fijaros en la versión… es la misma 3.10.0-1127.8.2.el7.x86_64
[root@iscsi boot]# uname -r 3.10.0-1127.8.2.el7.x86_64
El disco RAM inicial o initrd, por sus siglas en inglés es un sistema de ficheros temporal usado por el núcleo Linux durante el inicio del sistema.Kernel initramfs+version y vmlinuz+version hacen pareja:
-rw-------. 1 root root 31421984 May 25 2020 initramfs-3.10.0-1127.8.2.el7.x86_64.img -rwxr-xr-x. 1 root root 6762688 May 12 2020 vmlinuz-3.10.0-1127.8.2.el7.x86_64
Supongamos que initramfs no está presente u ocupa muy poco, sospecha de corrupción o mal generado en la actualización del kernel.
[root@iscsi boot]# file initramfs-3.10.0-1127.8.2.el7.x86_64.img initramfs-3.10.0-1127.8.2.el7.x86_64.img: ASCII cpio archive (SVR4 with no CRC)
comando file no sabe decirnos que tipo de fichero es pues esta corrupto…
Arrancar la maquina desde un kernel anterior y volver a generar initramfs-3.10.0-1127.8.2.el7.x86_64.img
# dracut -v - -force initramfs-3.10.0-1127.8.2.el7.x86_64.img 3.10.0-1127.8.2.el7.x86_64
Cerciorarse de que lo ha creado reiniciar la máquina con el kernel deseado.
Arrancamos desde otro kernel…
[root@iscsi boot]# ls -l initramfs-3.10.0-1127.8.2.el7.x86_64.img -rw-------. 1 root root 31420513 Jun 18 20:37 initramfs-3.10.0-1127.8.2.el7.x86_64.img
Ya está otra vez, reiniciamos con el kernel de antes… después del reinicio…
[root@iscsi ~]# cd /boot [root@iscsi boot]# uname -r 3.10.0-1127.8.2.el7.x86_64
Arrancó, todo OK!!!
[root@iscsi boot]# ls -l vmlinuz-3.10.0-1127.8.2.el7.x86_64 initramfs-3.10.0-1127.8.2.el7.x86_64.img -rw-------. 1 root root 31420513 Jun 18 20:37 initramfs-3.10.0-1127.8.2.el7.x86_64.img -rwxr-xr-x. 1 root root 6762688 May 12 2020 vmlinuz-3.10.0-1127.8.2.el7.x86_64
Adiós a los ficheritos de texto con sitios, usuarios y contraseñas.
Hemos recibido en la empresa un mail del departamento de Seguridad, diciéndonos que queda terminantemente prohibido alojar datos de acceso en ficheros de texto.
Todos nuestros accesos tienen que ser migrados a un gestor de contraseñas tipo Keepass.
El auditor nos va a llamar, daremos a compartit pantalla y le tenemos que demostrar que no hacemos ningún acceso con una contraseña visible y que además un backup del fichero maestro de contraseñas tiene que estar en lugar seguro.
1Password – https://1password.com/
Esta es muy conocida sobre todo para los usuarios de Mac y ya está disponible en otras:
Apps for Mac, iOS, Windows, Android, Linux, and Chrome OS
36 dólares al año la personal, la familiar hasta 5 personas 70 dólares al año y para uso empresarial son 95 dólares al año por usuarios
Bitwarden
Open source, que siempre es un plus, hay versión gratuita y también hay versión para todo
Puedes instalarte tu propio servidor de bitwarden, lo cual es un plus total (https://bitwarden.com/help/article/install-on-premise/)
Keepass (https://keepass.info/)
Gratuito, necestias un fichero donde se guardan las contraseñas, puedes usar un punto local para compartirlo con vario usuarios. NextCloud por ejemplo
Hay un montón de clientes de Keepass (https://keepass.info/download.html)
Otros
- myki
- Enpass
- Buttercup
- LastPass