
Production is Red, Development is Blue - jeffmiller
http://jeffmiller.github.com/2011/01/10/ssh-host-color
======
KrisJordan
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.

~~~
jonhohle
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
Konsole does this automatically, at least on openSuSE linux.

~~~
pmjordan
It's actually just the default bash config on openSUSE, nothing to do with
Konsole. It works on text-mode VTs, via ssh, etc.

------
joshfinnie
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?

~~~
there
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
Oh please yes. + a bucket load for code.google.com which comes up a lot and
would provide nice glanceable info.

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

~~~
pak
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
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.

~~~
pak
I've seen it used to manage deployments, and it's not perfect, but it's a lot
better than expecting a whole team of engineers to muck about on the
production servers and remember to get everything just right.

In fact, an expect script [can be] nicely self-documenting, because somebody
can look at it and see "oh these are the steps to deploy X" because the
scripts basically read as "at the foo prompt, enter bar" over and over again,
with some branching to handle varying responses (missing prereq, error
messages).

The "ultimate" in building environments would probably have to be something
more comprehensive and declarative like bcfg
(<http://trac.mcs.anl.gov/projects/bcfg2>) which I have seen in action and it
works but is very XML-heavy.

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

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

------
stephen
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?)

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

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

------
morganpyne
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 :-)

------
moe
Colorful shell prompts can be used for the same purpose.

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

~~~
moe
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.

~~~
po
One of the developers of iTerm2 also liked the idea responded to my tweet by
opening an issue request for it:

<http://code.google.com/p/iterm2/issues/detail?id=454>

~~~
moe
Wow, pretty cool! As an iTerm user I'll be looking forward to that.

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

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

------
olalonde
Any chance it is possible to accomplish on Ubuntu?

~~~
there
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
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"

------
reedlaw
This doesn't work with GNU Screen.

------
comex
Debugging is sweet,

And so are you.

