Production is Red, Development is Blue

http://jeffmiller.github.com/2011/01/10/ssh-host-color

by fukumoto • 16 years ago

173 48 16 years ago

jeffmiller.github.com

olalonde• 16 years ago

Any chance it is possible to accomplish on Ubuntu?

there3• 16 years ago

you could use something like xtermcontrol (http://www.thrysoee.dk/xtermcontrol/) and run it from your ~/.ssh/config file per-host:

     Host someproductionbox
          LocalCommand xtermcontrol --bg=red
     
     Host sometestbox
          LocalCommand xtermcontrol --bg=blue

shimon• 16 years ago

Great tip! Note that for this to work, you need to edit /etc/ssh/ssh_config and set PermitLocalCommand yes

There's no way to change profile from the command line using gnome-terminal, unfortunately, but there is "roxterm" which is very similar in functionality and lets you do the following to change the color scheme of the current terminal window:

    dbus-send --session /net/sf/roxterm/Options net.sf.roxterm.Options.SetColourScheme string:$ROXTERM_ID "string:NAME_OF_COLOR_SCHEME"

jim_h• 16 years ago

Edit your .bashrc in your home directory.

Uncomment 'force_color_prompt=yes' Edit the line following if color_prompt is yes. By default it's green (1;32m). Red is 0;31m.

Make sure to make a copy of the .bashrc file before starting.

jerf• 16 years ago

The way I prefer to do it in gnome-terminal and konsole (both can do it) is to set up sessions that have the color info in the session for the terminal, and the command to start the session is an ssh command. In konsole, theoretically, you can bind this to a keystroke but there is a long-standing issue with that where it can't seem to persist across restarts, and has weird problems sticking even within a session. But when it works it's convenient, especially when combined with SSH's ControlMaster.

lukeschlather• 16 years ago

I have this set in my .bashrc:

     function settitle {
         echo -en "\e]0; $* \a"
     }
     
     function ssh {
         settitle ssh $*
         echo     /usr/bin/ssh $*
         /usr/bin/ssh $*
     }
     function sftp {
         settitle sftp $*
         echo     /usr/bin/ssh $*
         /usr/bin/sftp $*
     }

No, it's not bright and colorful, but it does a good job of telling me where the gnome-terminal I'm using is connected to.

moe3• 16 years ago

Colorful shell prompts can be used for the same purpose.

there3• 16 years ago

except when you're doing something like editing a file, tailing a log, or doing anything other than staring at a command prompt.

moe3• 16 years ago

FWIW, my editor has its own background color (vim in 256 color mode), so I wouldn't see the terminal background either way.

However, I like the idea in general, just not the implementation. It would be nice if modern terminal emulators (hello iTerm!) could adopt new escape sequences to do things like set a background color on the tab (like ZOC and some others support by client-side configuration).

There is still lots of room for innovation in the terminal, it's a bit sad to see progress at such a glacial pace. I'd actually pay for a terminal emulator that's fast (first priority) and then also makes my life easier with innovative features like the above.

For some reason all innovation in the terminal space seems to have died when dialup BBS went out of fashion 10 years ago. Most terminal emulators have even moved backwards and don't support ZModem anymore, which could be very useful to provide adhoc drag'n'drop uploads instead of the scp/rsync limbo that is so common nowadays.

protomyth• 16 years ago

Did this at one place I worked for terminals and sql windows (red = prod, green = dev, yellow = test). It does tend to inform you coworkers if they should really be asking you stuff when you have a whole screen of red.

KrisJordan• 16 years ago

To get a red prompt drop this line in your ~/.bashrc file on your production server:

PS1='\[\e[1;31m\][\u@\h \W]\$\[\e[0m\] '

We use this in our production environments and the red prompt, though not as jarring as a red background, is still scary enough to serve its purpose.

One upside in setting this up on the server, as opposed to local like the OP, is that all connections in will get the red prompt.

noonespecial• 16 years ago

I do exactly this as well as add a little blurb in motd saysing that this machine is production, tread carefully. This seems to solve a great deal of mistaken identity problems.

jonhohle• 16 years ago

I do that in bash for root/non-root users (root is red, non-root is blue):

    if [[ ${EUID} == 0 ]] ; then
        PS1='\[\033[01m\][ \[\033[01;31m\]\u@\h \[\033[00m\]\[\033[01m\]] \[\033[01;32m\]\w\[\033[00m\]\n\[\033[01;31m\]\$\[\033[00m\]> '
    else
        PS1='\[\033[01m\][ \[\033[01;34m\]\u@\h \[\033[00m\]\[\033[01m\]] \[\033[01;32m\]\w\[\033[00m\]\n\[\033[01;34m\]\$\[\033[00m\]> '
    fi

Interesting to think about using it across servers, though.

s-phi-nl• 16 years ago

Konsole does this automatically, at least on openSuSE linux.

mgedmin• 16 years ago

I used to have a different prompt color when SSH_CONNECTION was in my environment, to distinguish local terminals from remote connections. And also root/non-root, although I didn't know about $EUID and used the less-effective $(id -u).

xtacy• 16 years ago

To avoid cryptic looking escape sequences, one could have the colour codes named in their .?shrc file [1]:

  txtblk='\e[0;30m' # Black - Regular
  txtred='\e[0;31m' # Red
  txtgrn='\e[0;32m' # Green
  txtylw='\e[0;33m' # Yellow
  txtblu='\e[0;34m' # Blue
  txtpur='\e[0;35m' # Purple
  txtcyn='\e[0;36m' # Cyan
  txtwht='\e[0;37m' # White
  bldblk='\e[1;30m' # Black - Bold
  bldred='\e[1;31m' # Red
  bldgrn='\e[1;32m' # Green
  bldylw='\e[1;33m' # Yellow
  bldblu='\e[1;34m' # Blue
  bldpur='\e[1;35m' # Purple
  bldcyn='\e[1;36m' # Cyan
  bldwht='\e[1;37m' # White
  unkblk='\e[4;30m' # Black - Underline
  undred='\e[4;31m' # Red
  undgrn='\e[4;32m' # Green
  undylw='\e[4;33m' # Yellow
  undblu='\e[4;34m' # Blue
  undpur='\e[4;35m' # Purple
  undcyn='\e[4;36m' # Cyan
  undwht='\e[4;37m' # White
  bakblk='\e[40m'   # Black - Background
  bakred='\e[41m'   # Red
  badgrn='\e[42m'   # Green
  bakylw='\e[43m'   # Yellow
  bakblu='\e[44m'   # Blue
  bakpur='\e[45m'   # Purple
  bakcyn='\e[46m'   # Cyan
  bakwht='\e[47m'   # White
  txtrst='\e[0m'    # Text Reset

[1] https://wiki.archlinux.org/index.php/Color_Bash_Prompt

1amzave2• 16 years ago

I have a similar section in my .bashrc via a somewhat hackish loop (or two):

  ESC=$'\x1b'

  # Terminal color escapes
  colornames=(BLACK RED GREEN YELLOW BLUE MAGENTA CYAN)
  for i in ${!colornames[@]}; do
  	eval "${colornames[$i]}=\"${ESC}[3${i}m\""
  	eval "BG${colornames[$i]}=\"${ESC}[4${i}m\""
  done

  # There are holes in this sequence, so it doesn't loop nicely
  BOLD="${ESC}[1m"
  DARK="${ESC}[2m"
  UNDERLINE="${ESC}[4m"
  BLINK="${ESC}[5m"
  INVERSE="${ESC}[7m"
  RST="${ESC}[m"

  styles=(BOLD DARK UNDERLINE BLINK INVERSE RST)

  # and the PS1-safe versions of the above
  for i in ${colornames[@]} ${colornames[@]/#/BG} ${styles[@]}; do
  	eval "PS$i=\"\\[\$$i\\]\""
  done

Having color escapes in shell variables comes in handy from time to time (like faking 'colordiff' with sed).

CWIZO• 16 years ago

Is there any way to set this on directory level? I do my development in my /home/XYZ folder, and production is in /usr/local/www/XYZ and it would be great if I could set the background to red in the production dir (if I happen to wander into it somehow (which I really almost never do)).

Toucan• 16 years ago

You could put a shell script around cd that checks the current working directory every time you cd and alerts you appropriately.

A little clunky, I'll admit. I'd like to hear any more graceful solutions.

swah• 16 years ago

Pro tip: In Terminal.app you need the checkbox "Display ANSI colors" checked.

nodata• 16 years ago

I prefer:

PS1="\[\e[1;31m\]$PS1\[\e[0m\]"

joshfinnie2• 16 years ago

I think it is time to add *.github.com to the filter list. I read through the whole post before I realized it was not from GitHub, but someone who hosts on github. We do it for blogger etc, can we get github added?

there3• 16 years ago

it should probably just try to strip ^www\d*?\. from the domain and leave everything else, rather than strip off the first component of the hostname regardless of what it is.

better to print too long a url for some than too short for things like example.github.com, code.google.com, etc.

igravious• 16 years ago

Oh please yes. + a bucket load for code.google.com which comes up a lot and would provide nice glanceable info.

corin_• 16 years ago

Agree with the request and hence upvoted, however not quite sure how you didn't realise it wasn't officially from GitHub as soon as you loaded the page.

joshfinnie2• 16 years ago

Let's just call it me being way over tired. Definitely not an easy mistake to make.

raganwald• 16 years ago

I agree. foo.github.com and github.com/foo are the important domain considerations.

wtracy• 16 years ago

I was thinking that maybe Github had established a new color-coding scheme for differentiating projects that are production-ready from ones that aren't. That would have been interesting.

jackowayed• 16 years ago

I posted this to the feature requests a long time ago. I don't know how much pg and the other maintainers actually look at the feature requests (especially given that the same request for google.com, which seems like a nobrainer, has been near the top for >a year), but it's worth a try: http://news.ycombinator.com/item?id=1239752

stephen• 16 years ago

Doing the same thing for the webapp is also useful--it serves as visual reminder to QA folk that the production box (white background) is /not/ someplace they should be running test scenarios (vs. the QA box with an orange/whatever background).

Also, you can use different colors for different QA boxes--"I need blue qa deployed" or "That fix is in black qa".

(Yes, this was an enterprise environment, why do you ask?)

Luyt• 16 years ago

I do this by setting the Window Background Color in saved sessions in PuTTY. Works great! (The different colors for different machines, I mean).

sghael• 16 years ago

We do this in a different context for our webapp work. We have three primary environments: development, staging and production. We code a contextual, 20px high, colored div at the top of our master template. It's red for development, yellow for staging, and doesn't exist in production (i know it seems backwards, but you can't really show an extra red bar in production :p ). It also somewhere we dump out some quick and dirty debug info.

I've been burned too many times when jumping back and forth between production and dev browser tabs. This simple hack saves me time, and possibly some headaches.

swombat• 16 years ago

Here's the same for those of us on Macs and who like transparent Terminals.

http://geek.swombat.com/setting-up-terminalapp-with-tr-0

Loic• 16 years ago

You should never ssh into a production system, everything should be going through automated scripts. Doing this will really save your life. For me this means:

  $ fab deploy
  ... oups errors on the website even if tested on stagging ...
  $ fab getdebuglog
  $ fab rollback
  ... fix test ...
  $ fab deploy

fab is fabric, a very very nice deployment tool in Python: http://www.fabfile.org

abstractbill• 16 years ago

Never say never. I've done development on production machines, sometimes even when logged in as root ;)

But I agree with the sentiment - think very hard before doing this, and don't make it a habit.

ynniv• 16 years ago

I make a lot of mistakes, but at least when I do them by hand I know who to blame. Saying that people "should never" log into a production system is a tad dogmatic.

pak2• 16 years ago

Or for those less python-happy: just use expect

http://en.wikipedia.org/wiki/Expect

Slightly weird syntax, but learnable in a few hours. You are likely to already have it on your machines.

alttab• 16 years ago

I've built *Nix testing frameworks using Expect. Would one use Expect/Fabric/etc. to manage deployments and development environments?

Having the ability to immediately stage an environment to reproduce an error without configuration issues would really take a lot of treachery out of trying to evolve larger systems.

pavel_lishin• 16 years ago

I just set up the command line colors to be different on production vs. development machines - I like my terminal backgrounds black, and regular text white.

gmac• 16 years ago

I now run Byobu on my servers -- it's made my sysadmin life substantially better -- and for each server I pick a different color for the status bar along the bottom.

Production is red for me too. Like this: http://img.ly/images/663862/full

reedlaw• 16 years ago

This doesn't work with GNU Screen.

morganpyne• 16 years ago

I like this idea, and used to have a whole spectrum of color-coded terminals when I looked after dozens of boxes years ago at a large company. It proved to be very useful because although we did automate most activity on the machines (using cfengine + other tools) I still found myself logging in regularly to various machines and could often have many terminals on screen.

However... the color coding can be a bit misleading sometimes, particularly if you are chaining SSH sessions and the colors are being set on terminal launch (not on shell login). I was using PuTTY config settings for color on my company-mandated Windows machine and soon found the limitations of this when I logged in to machine A (green), then from there to machine B (red). The terminal was still green and some time later I trusted the color and ran a (destructive) command in the wrong shell. This reinforced to me that while useful, color is no substitute for thinking before typing, and double checking everything before performing destructive operations :-)

comex• 16 years ago

Debugging is sweet,

And so are you.

Production is Red, Development is Blue

Related Stories