Comment faites-vous comprendre que vous êtes sur un système de production?

Certains d’entre nous dans mon entreprise ont un accès root sur des serveurs de production. Nous recherchons un bon moyen de rendre les choses extrêmement claires lorsque nous avons ssh'd dans.

Quelques idées que nous avons eues sont:

• Invite rouge vif
• Répondre à une énigme avant d'obtenir une coquille
• Tapez un mot au hasard avant d'obtenir un shell

Quelles techniques utilisez-vous pour différencier les systèmes de production?

L'invite rouge est une bonne idée, que j'utilise aussi.

Une autre astuce consiste à placer un grand avertissement ASCII-art dans le /etc/motdfichier.
Avoir quelque chose comme cela vous saluer lorsque vous vous connectez devrait attirer votre attention:

 _______ _ _ _____ _____ _____ _____            
| __ __ | | | | _ _ | / ____ | | _ _ | / ____ | / \    
   | | | | __ | | | | | (___ | | | (___ / \   
   | | | __ | | | \ ___ \ | | \ ___ \ / / \ \  
   | | | | | | _ | | _ ____) | _ | | _ ____) | / ____ \
   | _ | | _ | | _ | _____ | _____ / | _____ | _____ / / _ _ / \ _ \


 _____ _____ ____ _____ _ _ _____ _______ _____ _____ _ 
| __ \ | __ \ / __ \ | __ \ | | | | / ____ | __ __ | _ _ / __ \ | \ | |
| | __) | | __) | | | | | | | | | | | | | | || | | | \ | |
| ___ / | _ / | | | | | | | | | | | | | | || | | | . `|
| | | | \ \ | | __ | | | __ | | | __ | | | ____ | | _ | || | __ | | | \ |
| _ | | _ | \ _ \\ ____ / | _____ / \ ____ / \ _____ | | _ | | _____ \ ____ / | _ | \ _ |


 __ __ _____ _ _ _____ _ _ ______ 
| \ / | / \ / ____ | | | | _ _ | \ | | ____ |
| \ / | / \ | | | | __ | | | | | \ | | | __   
| | \ / | | / / \ \ | | | __ | | | | . `| __ |  
| | | | / ____ \ | ____ | | | | _ | | _ | | \ | | ____
| _ | | _ / _ / \ _ \ _____ | _ | | _ | _____ | _ | \ _ | ______ |

Vous pouvez générer un tel avertissement sur ce site Web ou utiliser la figlet commande.

Comme Nicholas Smith l'a suggéré dans les commentaires, vous pouvez pimenter des choses avec des dragons ou d'autres animaux à l'aide de la cowsaycommande.

Au lieu d'utiliser le fichier / etc / motd, vous pouvez également appeler cowsayou figletdans le .profilefichier.

Ce n’est pas tout à fait la même chose, mais ce site Web recommande à vos développeurs de porter un sombrero rose lorsqu’ils apportent des modifications aux systèmes de production. Vous pourriez probablement avoir une règle similaire pour les insérer.

Le plus important que j'ai utilisé est un schéma de nommage discret où les systèmes de production sont nommés de manière différente des instances de test / dev. L'invite de style "Nom d'utilisateur @ Nom d'hôte:" est visiblement différente. Et, évidemment, je veux dire plus que des mots différents, mais aussi des formats différents:

exemple: PRD-WEB001 vs DEVEL-BOB-WEB001

Cela a plusieurs avantages:

• Le bloc hyper-affolé en fait un jeu de trois au lieu d'un jeu de deux.
• Le premier de l'ensemble est une longueur différente.
• La longueur totale des noms est très différente, ce qui rend l'espacement des lignes de commande différent les uns des autres et du texte de la fenêtre.

Et le meilleur de tout, il n’exige pas de configuration de terminal spéciale pour la production, juste pour éviter les erreurs Oops.

D'après mon expérience, vous voulez quelque chose qui vous rappelle constamment où vous en êtes. Les méthodes de connexion telles que les énigmes durent environ 10 secondes, jusqu'à ce que vous oubliez quelle fenêtre est quelle fenêtre. Tout ce qu'il faut, c'est faire un lsdans le mauvais répertoire pour faire défiler la bannière de connexion menaçante, enfouir la fenêtre du terminal sous une fenêtre du navigateur tout en cherchant quelque chose, alt-tab pour revenir à la mauvaise fenêtre et le chaos qui s'ensuit. Il est préférable d’avoir un repère visuel constant comme une invite de commande très différente.

N'oubliez pas que ceci doit être un rappel persistant, pas seulement un indicateur au moment de la connexion. Très souvent, une personne a plusieurs obus qui courent en même temps dans des onglets différents et qui se déplacent entre eux. Certains seront dev, certains production. Ainsi, lorsque vous exécutez une commande, vous devez avoir un indicateur à ce stade. Donc, selon mon expérience, avoir une invite spéciale est la meilleure méthode, un titre / une barre de tabulation modifiée étant un bon complément pour trouver facilement la bonne fenêtre / onglet.

Je vous recommande donc d’avoir une invite colorée (le rouge étant le choix évident) et une majuscule pour le nom d’hôte, avec un comportement similaire pour l’utilisateur (privilégié ou non privilégié). Quelques exemples:

Généralement quelque chose comme

set prompt =  "%{\033[1;44m%}`whoami`@`hostname -s`#%{\033[0m%} "` 

dans votre fichier de démarrage shell. Celui-ci est pour le bleu. Remplacez le 44avec du 41sapin rouge et 42du vert. Autres couleurs et motifs sauvages disponibles aussi .

Ce sont mes suggestions:

1) Assurez-vous que la plupart des commandes (rm, chown, chmod, /etc/init.d/*) de l'environnement de production nécessitent un accès sudo

2) Utilisez PS1 / PS2 pour indiquer que l'utilisateur est sur un serveur de production.

bash-3.2$  export PS1="[\u@\h \W]\$ "

Cela affichera l'invite de commande sous la forme

[sridhar@prodappserver901 conf]$

3) Si vous utilisez des clients Putty / SSH, vous pouvez toujours configurer une couleur / un profil d’arrière-plan unique pour différencier les serveurs de production.

Considérez simplement que vos deuxième et troisième idées vous aident lors de la connexion initiale, mais n’ont aucune valeur si vous avez plusieurs terminaux ouverts et que vous passez de l’un à l’autre. sysadmin1138 a l'idée d'utiliser l'attribution de nom est bonne lorsqu'elle peut être appliquée, mais il existe de nombreux cas où elle ne peut pas l'être.

La seule chose que je trouve vraiment utile est une invite de couleur. J'aime le vert pour dev / testing, le rouge pour la production et le bleu pour les machines de la zone démilitarisée. Ainsi, même si j'ai deux machines du même nom (dans des réseaux différents), par exemple lors de la préparation d'une machine de remplacement, je peux toujours savoir facilement sur laquelle je suis.

L'invite de commande rouge / spéciale est bonne. Une autre chose pourrait être une déconnexion automatique plus rapide sur les ordinateurs utilisant la variable TMOUT. Si vous avez ouvert plusieurs fenêtres, celles de production disparaîtront plus rapidement.

Cela devrait conduire à un comportement différent:

1. Développer
2. Tester
3. Apportez vos modifications sur un serveur de transfert
4. Ensuite seulement, lancez-vous rapidement dans la production et déployez-vous là-bas (exactement comme vous l'avez fait sur le serveur intermédiaire).

Travailler sur une machine de production avec un compte root simple n’est jamais une bonne idée.

Vous avez un compte avec les autorisations complètes sudo. Ne permet pas de sauvegarder la session sudo. Interdire sudo su. Utilisez un mot de passe distinct pour celui-ci (pas celui que vous avez pour votre machine dev). Probablement de modifier sudo pour notifier l’identité de production du shell avant d’exécuter la commande (via alias).

Cela fera des erreurs accidentelles assez difficiles. Et l'invite rouge ne fait jamais de mal.

J'y suis allé avec l'idée du message d'erreur rouge, et j'ai trouvé assez fastidieux de trouver du code fonctionnel .bashrc.

Alors voici ma version, prête à être incluse dans .bashrc- https://github.com/RichVel/nicer-bash-prompt . Il est complètement tirée par le nom d' hôte, donc tant que vous avez un modèle approprié pour hostnames de production ( par exemple xyprod01, xyprod02etc.) , il fonctionne bien, et vous pouvez utiliser la même .bashrcdans tous les environnements.

Cela ressemble à ceci:

Cela crée une invite plus agréable, y compris une invite rouge sur les hôtes de production - vous indique également la branche git actuelle et les 2 derniers répertoires dans $ PWD. Il prend soin d'éviter de perturber l'affichage des invites lorsque vous utilisez Ctrl / R (recherche inversée) en bash.

Inclut également une fonctionnalité facultative permettant de synchroniser l’historique de votre bash dans toutes les fenêtres du terminal, selon les lignes de cette réponse . C'est bien, mais tout le monde ne le veut pas, il est donc désactivé par défaut.

Bien que je ne sache pas à quoi ressemble votre configuration informatique, une solution efficace consisterait à créer une salle spéciale dans laquelle vous devez accéder à SSH sur des serveurs de production en tant que root. Si vous avez un centre de données, il peut s'agir de la salle des serveurs elle-même, mais disposer d'un emplacement physique séparé à partir duquel le travail n'est pas "normal" ne servirait plus à vous rappeler de manière constante que vous accédez aux machines de production.

Juste un tweak sur les suggestions ci-dessus. J'utilise CDE comme bureau Unix et tous les systèmes de production auxquels j'accède via un menu au format .dt / dtwmrc. Sur tous les systèmes de développement et UAT, je conserve mon jeu de couleurs normal, mais sur les systèmes de production, je règle le terminal sur un fond rouge. Je n'aime pas le look mais c'est un peu le point.

eta - Karol a laissé entendre essentiellement la même chose

Lorsque je me connecte à une machine de production, je reçois un paragraphe m'avertissant qu'il s'agit d'une machine de production, ainsi qu'une courte liste de directives. Si je ne pense pas pouvoir effectuer mon travail seul et en toute sécurité, je peux appeler un numéro de support pour UNIX, rappelant que le fait d'exploser une machine de production peut coûter cher, et que toutes les tâches que je fais sont enregistrées.

edit: Je travaille dans le secteur des transports.

Dans PuTTY, vous pouvez remplacer le titre de la fenêtre par un nom autre que celui par défaut d'une session enregistrée spécifique. Cela reste toujours sur la fenêtre, peu importe ce que vous faites à l'intérieur de la fenêtre. Cela apparaît également dans la barre des tâches.

Développez la fenêtre, cliquez sur Comportement. Entrez quelque chose dans le titre de la fenêtre comme:

  * * * * * * * * * * * * PRODUCTION  * * * * * * * * * * * * PRODUCTION  * * * * * * * * * * * *

Réponse simple? Changez la couleur de votre shell en rouge dans la configuration du shell. Ce sera évident et simple à mettre en place. Non seulement cela, mais contrairement aux en-têtes de serveur, il ne disparaîtra pas après quelques commandes.

Voici ce que j'ai fait sur mon Mac. Pour chaque serveur, j'ajoute une entrée dans le fichier ~ / .ssh / config, par exemple

Host app13
    HostName server.example.com
    User tom
    PermitLocalCommand yes
    LocalCommand osascript %d/bin/change_terminal_colours.scpt 12 35 35

Cet Applescript est déclenché une fois la session SSH établie. Il définit la couleur d’arrière-plan du terminal sur les valeurs RVB fournies (ou sur la valeur par défaut si aucune valeur de couleur n’est fournie). La partie potentiellement délicate consiste à intercepter la fin de la session SSH pour rétablir les couleurs par défaut. Pour cela, j'ai créé le script suivant sous le nom ~ / bin / ssh afin de remplacer la commande ssh par défaut. Cela intercepte et encapsule essentiellement tous les appels à la commande SSH. J'ai essayé d'utiliser l'aliasing et les fonctions, mais cette solution a fonctionné le mieux:

#!/bin/bash
/usr/bin/ssh $@
osascript ~/bin/change_terminal_colours.scpt

Voici la source du script change_terminal_colours.scpt . Mettez ceci aussi dans votre répertoire ~ / bin:

on run argv
    tell application "Terminal"
        # NOTE: Color values range from 0 to 65535.
        if (count of argv) > 0 then
            set backgroundColor to {(item 1 of argv) * 256, (item 2 of argv) * 256, (item 3 of argv) * 256}
        else
            set backgroundColor to background color of default settings
        end if

        try
            set background color of (selected tab of front window) to backgroundColor
        end try
    end tell
end run

J'ai écrit cette solution il y a une semaine et l'utilise depuis. J'espère que les autres le trouvent utile. Je trouve que cela fonctionne mieux que toutes les solutions que j'ai trouvées par Google.

Mon groupe utilise visionapp Remote Desktop (édition 2017: le produit a été renommé, mais je pense que c'est la même chose), à ​​la fois en RDP dans les machines Windows et en SSH dans les machines Linux. Nos connexions sont regroupées dans des dossiers par niveau et se voient attribuer une couleur de tabulation.

Donc, chaque fois que nous ouvrons une connexion de production - bam! - nous avons du rouge vif sur notre visage:

C'est certainement un investissement rentable si vous êtes un grand magasin Windows et que vous comptez beaucoup sur RDP. Je parie qu'il existe d'autres outils formidables si tout ce dont vous avez besoin est SSH.

Outre une invite unique (qui semble être la solution la plus fiable), si vous vous connectez à partir du même poste de travail, vous pouvez utiliser différents profils pour vos sessions SSH.

Par exemple, j'ai des arrière-plans rouges pour les systèmes de production, verts pour le développement, bleu pour les infrastructures (routeurs, etc.) et blanc pour les postes de travail locaux.

Si vous utilisez GNOME, il existe un moyen simple d'établir une connexion SSH avec le profil souhaité:

gnome-terminal --window-with-profile=production -e 'ssh root@production.example.com'

Le principal inconvénient est qu'il s'agit du côté client. Une invite spéciale reste donc votre meilleur choix si vous accédez à des serveurs situés à différents endroits.

Une autre façon de préciser que vous vous trouvez sur un système de production consiste à définir la fonctionnalité TMOUT (déconnexion automatique) sur le système de production.

En raison des vastes exigences réglementaires lorsque vous travaillez dans un secteur particulier, les activités de chacun sont ici consignées de manière décisive pour tout litige futur. En raison de cela, l'accès est également restreint et vous devez parcourir quelques "menus" qui vous permettent d'accéder à une machine en tant qu'un des nombreux utilisateurs de confiance. En configurant ce système, la personne doit sélectionner avec soin l’environnement PRODUCTION ou QA, puis choisir l’hôte auquel elle souhaite accéder dans la liste. Cela a également une période de temporisation afin que vous ne vous retrouviez pas dans une situation de connexion à un hôte de prod et que vous oubliez dans quel environnement vous vous trouvez le lendemain.

J'utilise les changements rapides comme les autres ici. Son rapide et méchant, mais fonctionne bien pour mes fins. Cela vous donnera en rouge un utilisateur normal sur un système de production et en majuscule rouge en tant que root sur un système prod.

Il pourrait être écrit en moins de lignes mais je le fais comme ça pour pouvoir ajuster les 2 autres cas (non root-non prod) si je le souhaite.

Nous partons du principe qu’un serveur de production n’utilise pas DHCP, mais que vous pouvez utiliser n’importe quelle autre méthode pour déterminer s’il s’agit d’un système de production. Tout ce qui fonctionne pour vous.

productionSrv=1
grep -qi bootproto=dhcp /etc/sysconfig/network-scripts/ifcfg-*
if [ "$?" -eq 0 ]; then
    productionSrv=0
fi
hostName=`hostname`
userName=`whoami`
if [ $userName == "root" ]
then
    if [ "$productionSrv" == 1 ]
    then
        hostName=`echo $hostName | tr [:lower:] [:upper:]`
        PS1='[\e[0;31m]\u[\e[0m]@[\e[0;31m]$hostName[\e[0m][$?][\e[0;31m][\W][\e[0m][\e[0;31m]\$[\e[0m]: '
    else
        PS1='[\e[0;31m]\u[\e[0m]@[\e[0;35m]$hostName[\e[0m][$?][\e[0;31m][\W][\e[0m][\e[0;31m]\$[\e[0m]: '
    fi
    PATH=$PATH:/sbin/
else
    if [ "$productionSrv" == 1 ]
    then
        PS1='[\e[0;32m]\u[\e[0m]@[\e[0;31m]$hostName[\e[0m][$?][\e[0;31m][\W][\e[0m][\e[0;32m]\$[\e[0m]: '
    else
        PS1='[\e[0;32m]\u[\e[0m]@[\e[0;35m]$hostName[\e[0m][$?][\e[0;31m][\W][\e[0m][\e[0;32m]\$[\e[0m]: '
    fi
fi

Utilisez un mot de passe root différent (peut-être plus long) sur les machines de production.

Vous pouvez créer un sudo (ou un wrapper) spécial, de sorte qu'un message spécial soit généré pour les machines de production.

Ici, nous avons des configurations de mastic par défaut pour rendre la couleur de premier plan de tout l’écran en rose vif.

• Prod: rose vif.
• Régression: vert pâle
• Modèle: bleu pâle
• Dev: normal

Cela fonctionne assez bien, mais j'aime bien certaines des autres idées ici.

• Pro: à moins que quelque chose n'utilise pas la couleur de premier plan .., chaque écran de produit est rose vif.
• Contre: Évidemment, si vous passez par autre chose que la configuration par défaut du mastic, cela ne fait rien.

dans le .bashrc / .bash_profile

echo " THIS IS THE PRODUCTION SYSTEM. BE RESPONSIBLE.. " ..