¿Requieres de una instalación o configuración de Linux o sus servicios?
¿Un desarrollo WEB empresarial a la medida?
¿Un curso o capacitación a la medida?
Revisa el sitio de SERVICIOS de LinuxTotal

Errores comunes en la administraci�n de sistemas GNU/Linux 

Copyright © 2005-2019 LinuxTotal.com.mx
Se concede permiso para copiar, distribuir y/o modificar este documento siempre y cuando se cite al autor y la fuente de linuxtotal.com.mx y según los términos de la GNU Free Documentation License, Versión 1.2 o cualquiera posterior publicada por la Free Software Foundation.

Autor: Sergio González D.  (sergio.gonzalez.duran@gmail.com)

---

Todos, absolutamente TODOS los administradores de sistemas Linux (más correcto GNU/Linux) hemos cometido errores al emitir algún comando que, o por las prisas se escribe con las opciones incorrectas o que no se querían, o simplemente pensamos que el resultado iba a salir de un modo y resulta total y catastróficamente diferente. ¡¡¡Hechando a perder se aprende!!!, nada más cierto, pero evita que te suceda en carne propia, aprende de los errores de otros. En este artículo te presento varios de los errores que como administrador Linux he realizado y otros tantos que he evitado oportunamente, varios los he recopilado por aqui y por allá, ten esta página en tus favoritos, tal vez un día te evite perder el trabajo y siempre, pero siempre recuerda que en comandos peligrosos debes de pensar y releer esa instrucción dos o tres veces antes de presionar el maldito 'Enter'.

"rm -rf" Mi favorito!!!

Nada como dejar totalmente inútil todo un servidor de producción, la sensación de enorme angustia tan solo 4 o 5 segundos después de haber presionado 'Enter' no tiene igual, y después descubrir que por más que presiones 'Ctrl-C' tratando de deshacer el error causa todavía más pánico y angustia, solo para descubrir una y otro vez que borraste medio disco duro sin remedio.

El comando rm, que permite eliminar archivos, al usarlo con las opciones -r que elimina recursivamente y -f que elimina sin preguntar, puede resultar desastroso si no se usa adecuadamente, y más si estás como el usuario root. Ejemplos:

Debería borrar desde el directorio actual hacía abajo, pero el espacio después del
punto, elimina el directorio actual y además desde la raíz /, eliminado TODO el
sistema de archivos!!!
rm -rf . /*      (lo correcto es: rm -rf ./* pero revisa muchas veces donde estás)
-------------------------
No estamos concentrados y pensamos que estamos por ejemplo en /home/sergio/etc y
acabamos de borar completamente /etc, dejando inútil el sistema
> pwd
/etc
rm -rf *    
-------------------------
Queremos borrar todos los archivos que comienzan con reportes2011 y graficos2011
y el último argumento separamos por error el asterisco haciendo que borremos
todo el directorio
rm -f reportes2011* graficos2011 *   

Ahhhhh, y jamás te confies en que si indicas lo siguiente rm reportes2011*, el sistema te va a preguntar archivo por archivo si deseas eliminarlo si o no, Redhat, CentOS y otras distribucciones tienen el mal hábito de crear el alias 'rm' para 'rm -i', la opción -i es la que realmente realiza la acción de interrogar archivo por archivo si se desea eliminar o no, pero el comportamiento normal de rm en casi todas las distribucciones es simplemente eliminar sin preguntar, asi que cuidado con eso.

Tan solo escribe el comando alias para que veas una lista de los alias de comandos de tu sistemas. Comprueba como esta la entrada para rm

No solo con rm sucede también con chmod y otros

El trabajar con / o ./ o ./* o /* o la combinación que quieras, aplica para cualquier comando de linux que permita el uso de metacaracteres y trabaje con archivos, por ejemplo esto también lo he visto suceder:

(ubicado digamos en /tmp y queriendo cambiar permisos)
#> cd /tmp
#> chmod -R 777 /*
Todo el sistema de archivos quedó con permisos completos!!!, lo correcto es:
#> chmod -R 777 ./*

Más sobre permisos en Linux aqui.

Otra variante de rm, ahora con find

Cuidado con la opción exec del comando find especialmente si se combina con rm. Este caso aparentemente real, lo encontré en un comentario de un foro, es muy ilustrativo:

Me encuentro en la tarea de remover todos los archivos 'core'
que se encuentren en el sistema, asi que utilizó

# find / -local -type f -name ‘core*’ -exec rm -f {} \;

para realizarlo en un solo paso.

Poco tiempo después el teléfono suena, es el DBA quejándose que su
base de datos ha dejado de funcionar.

¿Cuál base de datos? -- le pregunto.
"Core" responde.

Lo anterior resulta hasta cómico viéndolo desde afuera, pero definitavemente para asustarse si eres el sysadmin al que le sucedió esto. Definitavemente esto demuestra que tener respaldos (si, en plural) es algo imprescindible, obligatorio y necesario.

Consejo: Cuando uses un comando del tipo find ... -exec rm {} \;, siempre verifica que toda salga bien primero usando la opción -print en vez de -exec rm {} \; asi primero solo imprimes el resultado en pantalla, si ves que todo esta bien a como tu lo esperas, pasas a usar -exec

Más sobre find aqui.

ohhh yes

El aparentemente inocente e inútil comando yes que sirve básicamente para "estresar" a un servidor al saturar ciclos de CPU y realizar por ejemplo pruebas de desempeño, etc., puede ser también causa de perdición. yes repite indefinidamente la letra "y" si se usa sin argumentos, asi que si abres tres o cuatro sesiones con este comando, volverás el sistema extremadamente lento, pero fácilmente solucionable al suspender con killall yes desde otra terminal.

El problema que yo tuve con yes fue el de al estar probando cuotas de disco en un sistema quise crear de manera rápida archivos de gran tamaño, de varios megas. Y se me hizo como fácil opción realizar lo siguiente:

$> yes "una frase larga aqui" > archivo01

y en otra consola, desde otra cuenta algo similar

$> yes "otra frase larga aqui" > archivo02

Si lo anterior, incluso un solo archivo, lo dejas ejecutar por unos minutos se generan archivos enormes, y se puede llenar una partición en muy poco tiempo, si esta partición es / o la única que tienes además de /boot, tendrás un sistema inutilizable en muy poco tiempo. Afortunadamente la solución es fácil, entrar con un disco de rescate borrar los archivos culpables y listo.

"userdel -r" diciéndole adios a un usuario

Como es sabido, la información de un usuario, su mailbox, sitio web personal (si lo usa), sus documentos, etc. se guardan bajo su directorio de trabajo o HOME y generalmente esta ubicado bajo /home. Cuando un usuario ya no es parte de la organización generalmente damos de baja al usuario con el comando userdel, esta bien si lo utilizas de la siguiente manera:

#> userdel juan

El "error" está en que se pudiera tener la tentación de usuar lo opción -r asi:

#> userdel -r juan

Esto eliminará al usuario junto con TODO su directorio de trabajo, sin la opción -r solo elimina al usuario de /etc/passwd pero conserva íntegro su directorio HOME, la sorpresa y los problemas para el sysadmin puede venir después cuando la gerencia nos pide que le enviemos todos los archivos que ese usuario manejaba y si no hay un respaldo, ya estarás inventando una buena excusa para tu negligencia.

Te recomiendo jamás usar la opción -r sin antes asegurarte de tener un buen respaldo(s) de los archivos del usuario, o mejor aun, si el usuario era alguien que pudiera regresar o importante por algún motivo, no lo elimines, solo suspéndelo:

#> passwd -l juan  (bloquea (lock) la cuenta)
#> passwd -u juan  (desbloquea (unlock) la cuenta)

Broma pesada con /etc/inittab

No realmente un error (¿o si?) pero en alguna ocasión fui llamado por un cliente donde un servidor Linux se volvió "loco", repentinamente, después de un corte de luz al volver el servidor a prenderse, este no dejaba de reiniciarse, iniciaba y se reiniciaba. Al entrar como root con un disco de rescate se encontró el problema en el archivo /etc/inittab en la línea:

id:6:initdefault:

Esta línea indica el nivel de ejecución (runlevel) por defecto del sistema, el 6 indica "reboot" lo que hacía que el sistema se reiniciara todo el tiempo. Lo correcto en esta línea es un nivel de ejecución 3 (multiusuario con red) o 5 (lo mismo más X11) (aprende más sobre esto en este tutorial sobre servicios de LinuxTotal).

De las 3 personas que trabajaban en ese departamento nadie admitió haber cambiado el archivo, la fecha de modificación era de varios meses atrás, asi que no se supo quien cometió el "error" o hizo la broma pesada.

init - No todos los Unix son iguales

Otro punto sobre los niveles de ejecución. Estos pueden cambiarse en caliente con el comando init, por ejemplo en CentOS y Redhat:

#> init 3

(cambia el nivel de ejecución a 3, multiusuario sin Xwindow o X11)

Pero esto no es igual en todas las distribucciones y mucho menos en los distintos sabores de Unix, por ejemplo si emites init 5 en Solaris estarás apagando el equipo, mientras que en Redhat, Fedora y CentOS estarás cambiando al ambiente gráfico.

Evita errores, en un equipo que no conozcas siempre verifica los niveles de ejecución propios de ese equipo Unix o Linux:

#> more /etc/inittab

Prácticamente este archivo existe en todos los sabores de Linux o Unix, y generalmente tiene al principio en forma de comentarios la descripción de los niveles de ejecución.

> en vez de >>

El error en el uso de > y >> es típico, por ejemplo, tienes un archivo de bitácora donde se registran via un script automatizado con cron registros sobre el estatus del servidor, logins de los usuarios, lo que hicieron, lo que consultaron, etc, etc. Y eventualmente lo revisas y decides añadirle anotaciones manualmente por alguna razón y haces lo siguiente:

$> echo "Revisado, todo bien hasta el 20111230 18:00" > /bitacoras/bitacora2012

Upssss, y no tenías respaldo del archivo. Lo que acabas de hacer es sobreescribirlo todo con esa sola línea al utilizar el redireccionamiento > en vez de >> que hubiera "añadido" la línea al final del archivo.

Ahora bien, lo anterior pudiera ser no tan crítico, pero que tal si en un servidor de producción con Apache, queriendo agregar una directiva al vuelo, haces lo siguiente:

$> echo "DirectoryIndex index.html index.php" > /etc/httpd/conf/httpd.conf | service httpd restart
(adios configuración de Apache, debiste usar >>)

En achivos de configuración importantes mejor usa un editor como vim, nunca hagas cosas como lo anterior es bastante, frustrante reconfigurar todo desde cero y más si no hay respaldos, lo se por experiencia.

"shutdown -h" cuidado con los apagados remotos

Esta historia le sucedió a un conocido que le daba servicio a un servidor remoto en una sucursal de su empresa ubicada en una ciudad a 150 kilómetros. Viernes por la noche, ya no había nadie en la sucursal, y regresaban hasta el lunes, el servidor es de correo y dns y se requiere 24/7. Después de loguearse remoto via ssh y hacer su rutina e instalar actualizaciones via yum decide reiniciarlo para ello emite:

#> shutdown -h now
(y como casi siempre, segundos o centésimas de segundos después de
presionar 'Enter' comienzas a sudar frio al darte cuenta que no hay retorno.)

La opción -h "halt" apaga el equipo, mientras que la opción -r "reset" reinicia el equipo.

A este pobre tipo no le quedó más remedio que tomar el carro y manejar por una hora y media (más el regreso), ya que es obvio que el servidor no contaba con un hardware de control remoto tipo ILOM o DRAC, además de tener que despertar a alguien para que le abrieran la oficina.

Presionar 'Enter' para despertar la pantalla

Esta pequeña historia es una joya, lo encontré también en un foro, la transcribo traducida tal cual, se autoexplica.

******

Mientras un colega se encontraba fuera de su lugar de trabajo, tecleé en su terminal lo siguiente:

#> rm -rf *

... pero no presioné 'Enter'. Se trataba de una broma, yo esperaba que al regresar y viera esa línea se asustara y después viera que se trataba de una broma y nos rieramos, después presionaría 'backspace' y nada pasaba.

Pero lo impensable pasó, la pantalla se puso a dormir con el protector y cuando regresa presiona 'Enter' unas cuantas veces para despertarla!!!!!!. Se perdieron 3 días de trabajo y algunos posibles clientes nuevos, el costo estimado de la "broma" resultó en unos 50,000 dólares.

******

Conclusión: en una terminal o consola Linux dormida, jamás, pero jamás uses 'Enter' para revivirla, usa 'Shift' o la barra espaciadora pero nunca 'Enter', no se sabe lo que pudiera estar ahi esperando.

crontab -r VS crontab -e

Muchos hemos sufrido este error clásico, el confundir la opción -r que remueve o elimina el contenido del archivo crontab del usuario en vez de haber indicado la opción -e que edita el mismo.

Tal vez tiene algo que ver que la e y la r están juntas en el teclado, o quizás es una simple dislexia, etc. El chiste es que no es gracioso ver tu querida lista de crones desaparecer por una tecla de por medio.

Autogol con Firewall iptables

Esto también es relativamente un error frecuente, y es que a través de ssh te conectas a tu servior Linux remoto y en la terminal que abriste cambias reglas del firewall, las aplicas. Solo para encontrarte que la siguiente vez que deseas conectarte ya no puedes conectarte de nuevo debido a las reglas de iptables que acabas de crear. Por ejemplo:

(reglas originales)
iptables -A INPUT -s 192.168.1.10 -p tcp --dport 22 -j ACCEPT   (solo tu puedes entrar)
iptables -A input -p tcp --dport 22 -j DROP                     (nadie más puede loguearse)

(modificas o eliminas tu propio acceso, solo dejando esta)
iptables -A input -p tcp --dport 22 -j DROP                     (nadie más puede loguearse)

También, me ha pasado que empiezas a desarrollar un firewall (de forma remota) y cambias las póliticas a que por defecto sean DROP en vez de ACCEPT pero no incluyes reglas para darte permiso a ti mismo o al administrador Linux y te quedas bloqueado, sin que tengas más remedio que trasladarte al equipo en si para arreglar el problema.

Una solución fácil y muy práctica, pero insegura por lo que debes ser muy cuidadoso, es que cuando administres firewalls remotos, en el tiempo que estes probando las reglas del nuevo firewall, ejecutes via cron un script con un firewall abierto que te permita cada cierto tiempo asegurarte que por cualquier error en las reglas que te bloqueen, puedas volver a ingresar. Es decir, digamos cada 5 minutos se activa el siguiente script:

#!/bin/bash
# script para resetear a un firewall totalmente abierto
# se ejecuta cada 5 minutos via está línea en /etc/crontab
#   */5 * * * * root /root/firewall_reset.sh
#   ADVERTENCIA: solo debe usarse en lo que se prueba via remota
#   el firewall seguro que se esté desarrollando.
#   borrar la tarea en /etc/crontab una vez que se tenga probado
#   y funcionando el firewall definitivo.

iptables -F
iptables -F -t nat
iptables -F -t mangle
iptables -X

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

Asi, si algo salió mal, solo espera máximo 5 minutos y te conectas de nuevo. Tener este script a la mano y solo usarlo si consideras que que pudieras quedar bloqueado al estar probando el firewall en el equipo remoto, de lo contrario mejor no lo uses, ya que dejarás totalmente expuesto el servidor. Igualmente si consideras que 5 minutos es demasiado puedes bajarlo a 2 o 3 minutos y asegurate siempre de haber eliminado el script y la línea de la tarea en crontab una vez que termines.

IMPORTANTE: realmente el tener este script es solo una garantía cuando pruebes el firewall, ya que un nuevo firewall SIEMPRE debes probarlo primero en un equipo de pruebas o en una máquina virtual y solo llevarlo a producción cuando estes perfectamente seguro que trabaja ccorectamente, el script solo debería ejecutarse una o dos veces máximo en lo que terminas de afinar el definitivo.

Puedes aprender o entender más de cron aqui.

Miscelanea de errores

ifconfig

Dar de baja una de las tarjetas de red para realizar alguna tarea fuera de línea:

#> ifconfig eth1 down

Y no volverla a dar de alta (ifconfig eth1 up) por descuido y olvido.

kill

Teclear lo siguiente:

#> kill 1

En vez de:

#> kill %1

En el primer caso (el error) estás matando el PID 1, es decir el proceso init, al matar este proceso terminas efectivamente con todo el servidor, no queda más que reiniciar.

Lo correcto '%1' mata el job o el trabajo 1 del usuario que lo invocó, es algo muy distinto.

Puedes aprender o entender más de servicios aqui.

pkill

pkill permite terminar (o enviar señales) a los procesos por nombre u otro atributo.

#> pkill -9 -t pts

Lo anterior terminará con todas las terminales conectadas en ese momento al sistema, ocasionando que todos los usuarios pierdan su sesión. Lo correcto debería ser:

#> pkill -9 -t pts/2

Con esto terminarías con la terminal pts/2 solamente que quizás estaba bloqueada.

Puedes aprender un poco más de esto aqui
usermod -G

Tienes que agregar a un nuevo grupo a un usuario existente que ya pertence a los grupos "contabilidad", "gerentes" y otros más:

#> usermod -G ventas alejandro

Upsss, acabas de eliminar todos los grupos de "alejandro" solo dejándolo en el grupo "ventas". Lo correcto sería:

#> usermod -G ventas,contabilidad,gerentes,equipo1,equipo7 alejandro

La opción -G de usermod se le debe indicar completamente todos los grupos a los que ya pertenece, más el nuevo. Puedes descubrir a que grupos pertenece el usuario asi:

#> id alejandro

Tutorial sobre la administración de usuarios aqui

Conclusión:

• Recuerda siempre examinar tu comando o script 2 o 3 veces antes de presionar 'Enter', sobre todo si conlleva rm u otros comandos que afectan al sistema de archivos, procesos, usuarios, etc.
• Hoy en día es imperdonable no probar comandos peligrosos o que alteraran el sistema en un ambiente de pruebas como máquinas virtuales. JAMAS hagas pruebas en servidores de producción.
• Dominar Linux es como cualquier otra profesión: práctica, práctica y más práctica, y después de eso más práctica. No hay atajos, ni fórmulas mágicas para dominar la línea de comandos.

Errores siempre vamos a tener, la idea es minimizarlos aprendiendo de los errores de otros. Comparte tus errores, tus historias en los comentarios, alguien te lo va agradecer.

---

¿Requieres de una instalación o configuración de Linux o sus servicios?
¿Un desarrollo WEB empresarial a la medida?
¿Un curso o capacitación a la medida?
Revisa el sitio de SERVICIOS de LinuxTotal