Mes 10 erreurs de ligne de commande linux et unix

Quiconque n'a jamais commis d'erreur n'a jamais essayé quelque chose de nouveau. - Albert Einstein.
Voici quelques erreurs que j'ai commises en travaillant à UNIX prompt. Certaines erreurs m'ont causé une bonne quantité de temps d'arrêt. La plupart de ces erreurs datent de mes débuts en tant qu'administrateur système UNIX. Cette page liste mes dix principales erreurs de ligne de commande Linux ou Unix.

Une liste de mes 10 erreurs en ligne de commande UNIX

On dit : "L'échec est la clé du succès ; chaque erreur nous apprend quelque chose." J'espère que vous apprendrez quelque chose de mes 10 erreurs de ligne de commande Linux ou Unix ainsi que des commentaires postés ci-dessous par mes lecteurs.

Commande userdel

Le dossier /etc/deluser.conf était configuré pour supprimer le répertoire personnel (cela avait été fait par l'administrateur système précédent et c'était mon premier jour de travail) et le spool de courrier de l'utilisateur à supprimer. Je voulais juste supprimer le compte utilisateur et j'ai fini par tout effacer (note -r était activé via le deluser.conf) :

Boîte Solaris redémarrée

Sous Linux, la commande killall tue les processus par nom (killall httpd). Sous Solaris, elle tue tous les processus actifs. En tant que root, j'ai tué tous les processus, c'était notre boîte principale Oracle db :

Détruit named.conf

Je voulais ajouter une nouvelle zone au fichier /var/named/chroot/etc/named.conf, mais je finis par exécuter :

Destruction des sauvegardes de travail avec Tar et Rsync (sauvegardes personnelles)

Je n'avais qu'une seule copie de sauvegarde de mon projet QT et je voulais juste récupérer un répertoire appelé functions. J'ai fini par effacer toute la sauvegarde (notez l'option -c au lieu de -x) :

Suppression de Apache DocumentRoot

J'avais des liens symétriques pour le docroot de mon serveur web (/home/httpd/http était lié par un lien symétrique à /www). J'ai oublié le problème des liens symboliques. Pour économiser de l'espace disque, j'ai exécuté rm -rf sur le répertoire http. Heureusement, j'avais un jeu de sauvegarde complet.

Changement accidentel du nom d'hôte et déclenchement d'une fausse alarme

J'ai accidentellement changé le nom d'hôte actuel (je voulais voir les paramètres actuels du nom d'hôte) pour l'un de nos nœuds de cluster. En quelques minutes, j'ai reçu un message d'alerte sur mon téléphone portable et par courriel.

Fermeture de l'interface du réseau public

Je voulais arrêter l'interface VPN eth0, mais j'ai fini par arrêter eth1 alors que j'étais connecté via SSH en utilisant la commande ifconfig :

Verrouillage du pare-feu

J'ai apporté des modifications à sshd_config et changé le numéro du port ssh de 22 à 1022, mais je n'ai pas réussi à mettre à jour les règles du pare-feu. Après une mise à jour rapide du noyau, j'ai redémarré la boîte. J'ai dû appeler le technicien du centre de données distant pour réinitialiser les paramètres du pare-feu. (Maintenant, j'utilise le script de réinitialisation du pare-feu pour éviter les blocages).

Taper les commandes UNIX sur la mauvaise boîte

Je voulais arrêter mon système de bureau Fedora local, mais j'ai émis un arrêt sur le serveur distant (j'étais connecté à la boîte distante via SSH) :

Entrée CNAME DNS incorrecte

Création d'une entrée DNS CNAME erronée dans le fichier de zone de example.com. Le résultat final - quelques visiteurs sont allés dans /dev/null :

Échec de la mise à jour de la configuration RBL de Postfix

En 2006, ORDB a cessé de fonctionner. Mais, j'ai omis de mettre à jour les paramètres de ma RBL Postfix. Un jour, ORDB a été réactivé et il retournait chaque adresse IP interrogée comme étant sur sa liste noire. Le résultat final était un désastre.

Conclusion

Tous les hommes font des erreurs, mais seuls les hommes sages apprennent de leurs erreurs - Winston Churchill.
De toutes ces erreurs, j'ai appris que :

1. Vous devez conserver un bon ensemble de sauvegardes. Testez également vos sauvegardes régulièrement.
2. Le choix évident pour préserver toutes les données des systèmes de fichiers UNIX est dump, qui est le seul outil qui garantit la récupération dans toutes les conditions. (voir Les programmes de sauvegarde et d'archivage à l'épreuve de la torture papier).
3. N'utilisez jamais rsync avec un seul répertoire de sauvegarde. Créez des snapshots en utilisant rsync ou rsnapshots.
4. Utilisez CVS/git pour stocker les fichiers de configuration.
5. Attendez et lisez deux fois la ligne de commande avant d'appuyer sur la touche [Enter].
6. Utilisez vos scripts perl / shell bien testés et un logiciel de gestion de configuration open source tel que puppet, Ansible, Cfengine ou Chef pour configurer tous les serveurs. Ceci s'applique également aux tâches quotidiennes telles que la création des utilisateurs et autres.

Les erreurs sont inévitables, alors avez-vous fait des erreurs qui ont causé une sorte de temps d'arrêt ? Veuillez les ajouter dans la section des commentaires ci-dessous.