Comment expliquez-vous que vous êtes sur un système de production?
Certains d'entre nous dans mon entreprise ont un accès root sur les serveurs de production. Nous recherchons un bon moyen de le rendre excessivement clair quand nous aurons intégré.
Voici quelques idées que nous avons eues:
- Invite rouge vif
- Répondez à une énigme avant d'obtenir un Shell
- Tapez un mot aléatoire 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 également.
Une autre astuce consiste à mettre un grand avertissement ASCII-art dans le /etc/motd fichier.
Le fait de vous accueillir lorsque vous vous connectez devrait attirer votre attention:
_______ _ _ _____ _____ _____ _____ | __ __ | | | | _ _ |/____ | | _ _ |/____ |/\ | | | | __ | | | | | (___ | | | (___/\ | | | __ | | |\___\| |\___ \//\\ | | | | | | _ | | _ ____) | _ | | _ ____) |/____\ | _ | | _ | | _ | _____ | _____/| _____ | _____// _/\ _\ _____ _____ ____ _____ _ _ _____ _______ _____ ____ _ _ | __\| __ \/__\| __\| | | |/____ | __ __ | _ _/__\|\| | | | __) | | __) | | | | | | | | | | | | | | || | | |\| | | ___/| _/| | | | | | | | | | | | | | || | | | . "| | | | |\\ | | __ | | | __ | | | __ | | | ____ | | _ | || | __ | | |\| | _ | | _ |\_ \\ ____/| _____/\ ____/\ _____ | | _ | | _____\____/| _ |\_ | __ __ _____ _ _ _____ _ _ ______ | \/|/\/____ | | | | _ _ |\| | ____ | | \/|/\ | | | | __ | | | | |\| | | __ | | \/| |//\\ | | | __ | | | | . `| __ | | | | |/____\| ____ | | | | _ | | _ | |\| | ____ | _ | | _/_/\ _\_____ | _ | | _ | _____ | _ |\_ | ______ |
Vous pouvez générer un tel avertissement sur ce site Web ou vous pouvez utiliser la commande figlet.
Comme Nicholas Smith l'a suggéré dans les commentaires, vous pouvez pimenter les choses avec des dragons ou d'autres animaux en utilisant la commande cowsay.
Au lieu d'utiliser le fichier/etc/motd, vous pouvez également appeler cowsay ou figlet dans le .profile fichier.
Pas tout à fait la même chose, mais ce site Web recommande que vos développeurs portent un sombrero rose lorsqu'ils apportent des modifications aux systèmes de production. Vous pourriez probablement avoir une règle similaire pour les utiliser.
Le plus gros que j'ai utilisé est un schéma de nommage discret dans lequel les systèmes de production sont nommés de manière évidemment différente des instances de test/dev. Cela rend l'invite de style "Nom d'utilisateur @ Nom d'hôte:" visiblement différente. Et par évident, je veux dire plus que des mots différents, des formats différents aussi:
exemple: PRD-WEB001 vs DEVEL-BOB-WEB001
Cela a plusieurs avantages:
- Le bloc hyperhéné supplémentaire en fait un ensemble de trois au lieu d'un ensemble de deux.
- Le premier de l'ensemble est d'une longueur différente.
- La longueur globale des noms est nettement différente, ce qui rend l'espacement de la ligne de commande différent les uns par rapport aux autres et aux autres textes de la fenêtre.
Et surtout, il ne nécessite 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 êtes. Les méthodes de connexion comme les énigmes sont bonnes pendant environ 10 secondes, jusqu'à ce que vous oubliez quelle fenêtre est laquelle. Tout ce qu'il faut faire est de faire un ls dans le mauvais répertoire pour faire défiler la bannière de connexion inquiétante hors de vue, enterrer la fenêtre du terminal sous une fenêtre de navigateur tout en recherchant quelque chose, alt-tab retour à la mauvaise fenêtre et chaos s'ensuit. Il est préférable d'avoir un signal visuel constant comme une invite de commande significativement différente.
Une chose que vous devez garder à l'esprit est que cela doit être un rappel persistant, pas seulement un indicateur au moment de la connexion. Très souvent, quelqu'un aura plusieurs obus exécutés en même temps dans différents onglets et se déplacera entre eux. Certains seront du développement, d'autres de la production. Ainsi, lorsque vous exécutez une commande, vous devez disposer d'un indicateur à ce stade. Donc, avoir une invite spéciale est la meilleure méthode, selon mon expérience, avec une barre de titre/onglet modifiée étant un bon complément à cela pour trouver facilement la bonne fenêtre/onglet.
Je recommanderais donc d'avoir une invite colorée (le rouge étant le choix évident) et toutes les majuscules pour le nom d'hôte, avec un comportement similaire pour l'utilisateur (privilégié vs non privilégié) comme votre invite. Quelques exemples:
Habituellement, 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. Remplace le 44 avec 41 rouge sapin et 42 pour le vert. Autres couleurs et motifs sauvages également disponibles .
Ce sont mes suggestions:
1) Assurez-vous que la plupart des commandes (rm, chown, chmod, /etc/init.d/*) sur l'environnement de production nécessitent un accès Sudo
2) Utilisez PS1/PS2 pour indiquer que l'utilisateur se trouve sur un serveur Prod
bash-3.2$ export PS1="[\u@\h \W]\$ "
Cela affichera l'invite de commande comme
[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 faire ressortir 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 lorsque vous avez plusieurs terminaux ouverts et passez de l'un à l'autre. L'idée de sysadmin1138 d'utiliser la dénomination est bonne lorsqu'elle peut être appliquée, mais il y a de nombreux cas où elle ne peut pas l'être.
La seule chose que j'ai trouvée vraiment intéressante est une invite colorée. J'aime le vert pour le développement/test, le rouge pour la production et le bleu pour les machines dans la DMZ. De cette façon, même si j'ai deux machines portant le même nom (dans différents réseaux), comme lors de la préparation d'une machine de remplacement, je peux toujours facilement dire sur laquelle je me trouve.
L'invite de commande rouge/spéciale est bonne. Une autre chose pourrait être une déconnexion automatique plus rapide sur ces machines à l'aide de la variable TMOUT. Si vous avez ouvert de nombreuses fenêtres, celles de production disparaîtront plus rapidement.
Cela devrait conduire à un comportement différent:
- Développer
- Tester
- Apportez vos modifications à un serveur de transfert
- Ensuite, lancez rapidement la production et déployez-le là-bas (exactement comme vous l'avez fait sur le serveur de transfert)
Travailler sur une machine de production avec un compte root simple n'est jamais une bonne idée.
Avoir un compte avec des autorisations Sudo complètes. Ne permet pas d'enregistrer la session Sudo. Interdire Sudo su. Utilisez un mot de passe distinct pour celui-ci (pas celui que vous avez pour votre machine de développement). Probablement Tweak Sudo pour notifier l'identité de production du Shell avant d'exécuter la commande (via un alias).
Cela fera des erreurs accidentelles assez difficiles. Et l'invite rouge ne fait jamais de mal.
Je suis allé avec l'idée d'invite rouge, et j'ai trouvé assez fastidieux de trouver du code de travail pour .bashrc.
Voici donc ma version, prête à être incluse dans .bashrc - https://github.com/RichVel/nicer-bash-Prompt . Il est entièrement piloté par le nom d'hôte, donc tant que vous disposez d'un modèle approprié pour la production des noms d'hôte (par exemple xyprod01, xyprod02, etc.) cela fonctionnera bien, et vous pouvez utiliser le même .bashrc dans tous les environnements.
Cela ressemble à ceci:
Cela crée une invite bash plus agréable, y compris une invite rouge sur les hôtes de production - vous montre également la branche git actuelle et les 2 derniers répertoires dans $ PWD. Il prend soin d'éviter de gâcher l'affichage de l'invite lorsque vous effectuez Ctrl/R (recherche inversée) dans bash.
Comprend également une fonctionnalité facultative pour synchroniser votre historique de bash sur toutes les fenêtres de terminal, le long 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 qui pourrait être efficace serait d'avoir une salle spéciale dans laquelle vous devez vous rendre en SSH sur les serveurs de production en tant que root. Si vous avez un centre de données, cela pourrait être la salle des serveurs elle-même, mais avoir un emplacement physique distinct à partir duquel le travail `` normal '' n'est pas effectué servirait très efficacement de rappel constant que vous accédez à des machines de production.
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. Il y a un numéro que je peux appeler pour le support UNIX si je ne pense pas pouvoir effectuer ma tâche seul en toute sécurité, un rappel que faire sauter une machine de production peut me coûter mon travail et un rappel que tout ce que je fais est enregistré.
edit: Je travaille dans l'industrie du transport.
Juste un petit coup d'œil 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 en .dt/dtwmrc. Sur tous les systèmes de développement et UAT, je conserve mon schéma 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 - Manqué Karol suggérant essentiellement la même chose
Voici ce que j'ai fait sur mon Mac. Pour chaque serveur, j'ajoute une entrée pour celui-ci dans mon fichier ~/.ssh/config, par ex.
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 revient à 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 Shell suivant en tant que ~/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'alias 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 aussi ceci 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 je l'utilise depuis. J'espère que d'autres le trouveront 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: on dirait que le produit a été renommé mais je pense que c'est la même chose) à la fois RDP dans les machines Windows et SSH dans les machines Linux. Nos connexions sont regroupées dans des dossiers par niveau et affectées à une couleur d'onglet.
Donc, chaque fois que nous ouvrons une connexion de production - bam! - nous obtenons du rouge vif sur notre visage:
C'est certainement un investissement utile si vous êtes un grand magasin Windows et que vous comptez beaucoup sur RDP. Je parie qu'il existe d'autres excellents outils si vous n'avez besoin que de SSH.
Réponse simple? Changez la couleur de votre Shell en rouge dans la configuration 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 avoir tapé quelques commandes.
Dans PuTTY, vous pouvez changer le titre de la fenêtre pour autre chose que la valeur par défaut pour 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 * * * * * * * * * * * *
Une autre façon d'indiquer clairement que vous êtes sur un système de production consiste à définir la fonction TMOUT (sortie automatique) sur le système de production.
En raison des vastes exigences réglementaires tout en travaillant dans une industrie particulière, les activités de chacun sont enregistrées pour tous les futurs conflits. À cause de cela, l'accès est également restreint et vous devez parcourir quelques "menus" qui vous permettent d'accéder à une machine en tant que l'un des rares utilisateurs de confiance. En configurant ce système, la personne doit choisir 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 rencontriez pas de situation de connexion à un hôte prod et d'oublier l'environnement dans lequel vous vous trouvez le lendemain.
j'utilise les changements rapides comme les autres ici. C'est rapide et désagréable mais fonctionne bien pour mes besoins. Cela vous donnera le rouge en tant qu'utilisateur normal sur un système de production et le rouge en majuscule en tant que root sur un système de production.
Il pourrait être écrit en moins de lignes mais je le fais comme ça pour que je puisse modifier les 2 autres cas (non root-non prod) si je le veux.
Nous partons du principe qu'un serveur de production n'utilise pas DHCP, mais vous pouvez utiliser toute 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
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, vert pour le développement, bleu pour l'infrastructure (routeurs, etc.) et blanc pour le poste de travail local.
Si vous utilisez GNOME, il existe un moyen simple de lancer une connexion SSH avec le profil souhaité:
gnome-terminal --window-with-profile=production -e 'ssh [email protected]'
Le principal inconvénient - c'est côté client, donc une invite spéciale est toujours votre meilleur pari si vous accédez à des serveurs à partir de différents emplacements.
dans le .bashrc/.bash_profile
echo " THIS IS THE PRODUCTION SYSTEM. BE RESPONSIBLE.. " ..
Avoir un mot de passe root différent (peut-être plus long) sur les machines de production.
Vous pouvez créer un Sudo spécial (ou un Sudo wrapper), de sorte qu'un message spécial soit émis pour les machines de production.
Ici, nous avons des configurations PuTTY par défaut pour que la couleur de premier plan de tout l'écran soit rose vif.
- Prod: rose vif.
- Régression: vert pâle
- Modèle: bleu pâle
- Dev: normal
Cela fonctionne assez bien, mais j'aime certaines des autres idées ici.
- Pro: à moins que quelque chose n'utilise pas la couleur de premier plan .., CHAQUE écran de prod est rose vif.
- Con: Évidemment, si vous passez par autre chose que la configuration PuTTY par défaut, cela ne fait rien.