To get a red prompt drop this line in your ~/.bashrc file on your production server:<p>PS1='\[\e[1;31m\][\u@\h \W]\$\[\e[0m\] '<p>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.<p>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.
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?
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:<p><pre><code> $ fab deploy
... oups errors on the website even if tested on stagging ...
$ fab getdebuglog
$ fab rollback
... fix test ...
$ fab deploy
</code></pre>
fab is fabric, a very very nice deployment tool in Python: <a href="http://www.fabfile.org" rel="nofollow">http://www.fabfile.org</a>
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.<p>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.
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.
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).<p>Also, you can use different colors for different QA boxes--"I need blue qa deployed" or "That fix is in black qa".<p>(Yes, this was an enterprise environment, why do you ask?)
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.<p>Production is red for me too. Like this: <a href="http://img.ly/images/663862/full" rel="nofollow">http://img.ly/images/663862/full</a>
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.<p>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 :-)
Here's the same for those of us on Macs and who like transparent Terminals.<p><a href="http://geek.swombat.com/setting-up-terminalapp-with-tr-0" rel="nofollow">http://geek.swombat.com/setting-up-terminalapp-with-tr-0</a>
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.