Los 10 errores comunes en la línea de comandos de Linux y UNIX

Albert Einstein dijo una vez: «Cualquiera que nunca haya cometido un error, nunca ha intentado algo nuevo». A continuación, se presentan algunos errores que cometí mientras trabajaba con el prompt de UNIX. Algunos de estos errores causaron tiempos de inactividad significativos. Esta lista resume mis diez principales errores en la línea de comandos de Linux o Unix, con la esperanza de que otros puedan aprender de ellos.

Lista de los 10 Errores en la Línea de Comandos de UNIX

Dicen que «el fracaso es la clave del éxito; cada error nos enseña algo». A continuación, se presentan mis diez errores en la línea de comandos de Linux o Unix, esperando que otros puedan aprender de ellos.

Comando userdel

El archivo /etc/deluser.conf estaba configurado para eliminar el directorio home y el spool de correo del usuario a ser eliminado, una configuración realizada por el administrador anterior. Mi intención era solo eliminar la cuenta de usuario, pero terminé borrando todo:

# userdel foo

Reiniciar el Servidor Solaris

En Linux, el comando killall termina los procesos por nombre (killall httpd). En Solaris, mata todos los procesos activos. Como root, maté todos los procesos en nuestro servidor principal de base de datos Oracle:

# killall process-name

Destruir named.conf

Quería añadir una nueva zona al archivo /var/named/chroot/etc/named.conf, pero terminé ejecutando:

# ./mkzone example.com > /var/named/chroot/etc/named.conf

Destruir Copias de Seguridad con Tar y Rsync (copias personales)

Solo tenía una copia de seguridad de mi proyecto QT y quería obtener un directorio llamado functions. Terminé borrando toda la copia de seguridad (usé el switch -c en lugar de -x):

# cd /mnt/bacupusbharddisk
# tar -zcvf project.tar.gz functions

No tenía otra copia de seguridad. Similarmente, ejecuté el comando rsync y borré todos los archivos nuevos al sobrescribir archivos del conjunto de respaldo (ahora uso rsnapshot):

# rsync -av -delete /dest /src

Eliminar DocumentRoot de Apache

Tenía enlaces simbólicos para el docroot de mi servidor web (/home/httpd/http estaba enlazado a /www). Olvidé el problema del enlace simbólico y, para ahorrar espacio en disco, ejecuté rm -rf en el directorio http. Afortunadamente, tenía un conjunto de respaldo completo.

Cambio Accidental del Nombre del Host y Alarma Falsa

Accidentalmente cambié el nombre del host actual (quería ver la configuración del nombre del host) de uno de nuestros nodos de clúster. En pocos minutos, recibí una alerta en mi móvil y correo electrónico:

# hostname foo.example.com

Apagar la Interfaz de Red Pública

Quería apagar la interfaz VPN eth0, pero terminé apagando eth1 mientras estaba conectado vía SSH usando el comando ifconfig:

# ifconfig eth1 down

Bloqueo del Firewall

Hice cambios en sshd_config y cambié el número de puerto de ssh de 22 a 1022, pero no actualicé las reglas del firewall. Después de una rápida actualización del kernel, reinicié el servidor y tuve que llamar al centro de datos remoto para restablecer la configuración del firewall.

Ejecutar Comandos UNIX en la Máquina Incorrecta

Quería apagar mi sistema de escritorio Fedora local, pero emití halt en un servidor remoto (estaba conectado al servidor remoto vía SSH):

# halt
# service httpd stop

Entrada CNAME de DNS Incorrecta

Creé una entrada CNAME de DNS incorrecta en el archivo de zona example.com. El resultado fue que algunos visitantes fueron dirigidos a /dev/null:

# echo 'foo 86400 IN CNAME lb0.example.com' >> example.com && rndc reload

Falla en la Actualización de la Configuración RBL de Postfix

En 2006, ORDB dejó de operar, pero no actualicé la configuración RBL de Postfix. Un día, ORDB se reactivó y devolvía todas las direcciones IP consultadas como si estuvieran en su lista negra. El resultado fue un desastre.

Winston Churchill dijo: «Todos los hombres cometen errores, pero solo los sabios aprenden de sus errores». De todos estos errores, he aprendido que:

• Debes mantener un buen conjunto de copias de seguridad y probarlas regularmente.
• La elección clara para preservar todos los datos de los sistemas de archivos UNIX es dump, que garantiza la recuperación bajo todas las condiciones.
• Nunca uses rsync con un único directorio de respaldo. Crea instantáneas utilizando rsync o rsnapshots.
• Utiliza CVS/git para almacenar archivos de configuración.
• Lee y verifica dos veces la línea de comandos antes de presionar la tecla Enter.
• Usa scripts perl/shell bien probados y software de gestión de configuración de código abierto como puppet, Ansible, Cfengine o Chef para configurar todos los servidores, así como para tareas diarias como la creación de usuarios.

Los errores son inevitables, así que ¿has cometido algún error que haya causado algún tiempo de inactividad? Por favor, agrégalo en la sección de comentarios a continuación.

Fuente: NixCraft