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 anterioresProblema: 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 ejecuta...