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


135

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?


11
Existe-t-il un moyen d'apprendre aux gens à éviter de passer aux systèmes de production? Si vous avez tout vérifié dans Puppet, par exemple, il vous suffira de vous connecter aux systèmes de production pour le dépannage.
Alex Holst

37
Vous autorisez l’accès root à ssh sur vos systèmes de production ???? !!!!!
symcbean

7
@symcbean: ce n'est pas ce que Sionide a dit. Il aurait pu vouloir dire après votre SSH dans votre compte utilisateur.
Zan Lynx

3
Cette question est-elle en train de devenir candidate au wiki de la communauté?
MadHatter

15
Vous pouvez rendre extrêmement clair qu'il s'agit d'un système de production en désactivant SSH. Ça ne peut pas être plus clair que ça.
Franci Penov

Réponses:


137

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.

figue

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.

Dragon Cowsay

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


3
Ooh j'aime ça!
Sionide21

13
Si vous avez tapé dans une commande, vous ne le verrez plus.
Nils

3
C’est vrai que c’est là que l’invite rouge est utile.
Kenny Rasschaert

41
Sur les serveurs Windows, j'utilise une couleur de bureau rose vif et des barres de titre / jeux de couleurs jaune vif pour que ce soit vraiment, vraiment évident. Voici notre version d'une invite de commande colorée
Mark Henderson

8
J'aimerais ajouter des dragons ASCII au mélange.
Nicholas Smith

80

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.

développeur portant un sombrero rose


1
Haha! +1 parce que j'ai raté Mais sérieusement, les gens peuvent chercher leurs lunettes manquantes en les portant, je doute qu'un chapeau serve de "rappel constant". En outre, cela ne vous aide pas à vous rappeler quelle fenêtre est laquelle.
Felix Dombek

7
Oui, vous devrez changer votre processus pour être: 1) Déclarez le désir de modifier la production. 2) Sortez le sombrero et fermez toutes les autres fenêtres. 3) Faire des trucs de production pendant que tout le monde regarde. 4) Déconnectez-vous de la session et supprimez sombrero.
Aric TenEyck

1
"2) Sortez le sombrero et fermez toutes les autres fenêtres" Cela ne fonctionnera pas vraiment dans mon entreprise, car c'est la deuxième étape de toutes nos procédures d'exploitation standard. L'étape 1 consiste bien sûr à "allumer les lumières", car, avec les fenêtres fermées, il peut faire très sombre dans ce bureau.
Parthian Shot

50

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.


Cela fonctionne vraiment bien pour les systèmes de base, mais dès que vous modifiez un développement, les développeurs gémissent et gémissent, la moitié de leurs liens cessant de fonctionner (peu importe le nombre de fois que vous l'avez déjà fait), et parfois le Le système lui-même marche à moitié jusqu'à ce que vous corrigiez toutes les nombreuses références à l'ancien nom dans les fichiers de configuration. Surtout avec les logiciels propriétaires installés, et les alias DNS ne sont d’une grande aide. Pire encore, il est facile d'oublier complètement l'invite lors du changement de fenêtre.
SilverbackNet

Les développeurs doivent créer des paramètres qui fonctionnent sur dev / test / staging / production (c'est ce que je fais, mais c'est une autre histoire). Pour une "invite rouge" opérationnelle pour bash (plus difficile qu'il n'y paraît), consultez ma réponse à l' adresse serverfault.com/a/479718/79266
RichVel le

39

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:

exemple des invites colorées

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 .


Pour une "invite rouge" fonctionnelle pour bash (plus difficile qu'il n'y paraît), consultez ma réponse sur serverfault.com/a/479718/79266 - affiche également la branche git, le répertoire actuel tronqué, etc.
RichVel,

14

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.


# 1 est une idée intéressante mais peu pratique car les scripts exécutés en tant que démons peuvent nécessiter l’utilisation de rm, chmod, etc.
Zan Lynx

13

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.


11

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).

9

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.


et par "sudo su", vous voulez dire "sudo -i" ou tout au moins "sudo su -", n'est-ce pas?
Sparr

Whoa! c'est Sparr! Petit monde :)
Sionide21

1
Il est impossible d'empêcher les gens d'avoir un shell racine. ( sudo bash) Vous pouvez obtenir un shell root à partir de n'importe quelle configuration 'liste noire'. (Si vous êtes prudent, vous pouvez l'arrêter avec une configuration de liste blanche, mais ce n'est généralement pas garanti.)
utilisateur606723 Le

1
Il n’est pas censé empêcher l’accès prévu à l’enveloppe racine - c’est seulement certaines des manières habituelles d’habituer les gens à le faire inconsciemment, sans y prêter attention.
Mihails Strasuns

8

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:

capture d'écran de l'invite rouge

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.


5

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.


2
Cela serait certes efficace, mais dans la plupart des cas, ce serait aussi extrêmement contre-productif.
John Gardeniers

Je suis d'accord avec John, mais c'est certainement une chose à laquelle réfléchir.
user606723

@JohnGardeniers: contre-productif? Vous voulez dire que cela nuirait à la productivité?
LarsH

@LarsH, le fait de devoir se rendre inutilement dans différentes pièces pour effectuer différentes tâches de son travail nuit certainement à la productivité. Votre réseau entier doit pouvoir être géré à partir d’un seul emplacement.
John Gardeniers

@JohnGardeniers: compris. Lorsque vous avez initialement déclaré «contre-productif», je pensais que son effet allait à l'encontre de l'objectif déclaré, à savoir de vous rappeler en permanence que vous accédez aux machines de production.
LarsH

4

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


4

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.


Aie. Bien que je puisse comprendre la nécessité de cela, je suis heureux de ne pas travailler dans ce type d’environnement.
LarsH

1
Je suis heureux de travailler dans les transports, et ces systèmes ne coûtent pas seulement de l'argent quand ils tombent en panne, ils coûtent la vie.
Basil

Je suis content que tu sois aussi prudent!
LarsH

3

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  * * * * * * * * * * * *

3

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.


3

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.


3

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:

entrez la description de l'image ici

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.


2

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.


2

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.


1
Comment cela est-il clair? C'est également potentiellement très dangereux, car des commandes ou des processus peuvent être en cours d'exécution et seront soudainement interrompus si la session est déconnectée.
John Gardeniers

3
Je viens de tester TMOUT et il semble que si une commande longue est en cours d'exécution, elle ne met pas fin à la session. Il ne le termine que lorsque vous êtes assis à l'invite de commande. Nils a également suggéré cela et cela a du sens pour moi.
Sjbotha

1
C'est la très bonne chose à propos de TMOUT. Nous avons utilisé autolog ou même killerd avant de découvrir TMOUT. Autolog et Killerd ne sont pas si gentils. Killerd est aussi un buggy et a tendance à bloquer un processeur complet ...
Nils

2

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.


2

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


Bien que le script soit intéressant, l'hypothèse d'une IP statique uniquement sur les systèmes de production n'est pas courante. Dans la plupart des cas, tous les serveurs auront des adresses IP statiques, tant pour le développement que pour la production.
Martijn Heemels

1
chevaux pour les cours vraiment. nos systèmes de développement utilisent des réservations DHCP. Vous pouvez utiliser n’importe quel système qui fonctionne pour vous, par exemple comparer le nom d’hôte, le sous-réseau, le vlan, etc.
Sirex

@Sirex, l'inverse est également possible. Par exemple, les serveurs virtuels EC2 d'Amazon utilisent des baux DHCP statiques sur les serveurs de production et les adresses IP publiques sont transférées. L'instance elle-même ne sait pas directement sur quelle adresse IP publique elle s'exécute, du moins pas au niveau de l'interface réseau.
Matthew Scharley

1
Ouaip. Vous pouvez toujours avoir simplement un paquetage rpm de rôle qui crée un fichier / etc / PRODUCTION et le tester. C'est comme tu veux.
Sirex

1

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.


.. Un mot de passe root différent sur les machines de production? pourquoi n'ai-je pas pensé à ça!?
user606723

En outre, sudo dispose déjà de nombreuses options de configuration. Je serais surpris si vous ne pouvez pas déjà le faire. Un sudo personnalisé est une idée terrible car il ne serait pas testé suffisamment pour obtenir le bit suid.
user606723

1

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.

1

dans le .bashrc / .bash_profile

echo " THIS IS THE PRODUCTION SYSTEM. BE RESPONSIBLE.. " .. 
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.