Trata como un Técnico Senior estos 4 sencillos emprendimientos en Linux con LinuxDoesMatter

Podcast de Redes de Eduardo Collado

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 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.