7 ms·

Production is Red, Development is Blue

173 points by jeffmiller 16y ago

olalonde 16y ago
Any chance it is possible to accomplish on Ubuntu?
- there 16y ago
  you could use something like xtermcontrol (http://www.thrysoee.dk/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 16y 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 16y 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 16y 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 16y 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.
moe 16y ago
Colorful shell prompts can be used for the same purpose.
- there 16y ago
  except when you're doing something like editing a file, tailing a log, or doing anything other than staring at a command prompt.
  - moe 16y 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.
    - po 16y ago
      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 http://code.google.com/p/iterm2/issues/detail?id=454
      - moe 16y ago
        Wow, pretty cool! As an iTerm user I'll be looking forward to that.
protomyth 16y 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 16y 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 16y 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 16y 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 16y ago
    Konsole does this automatically, at least on openSuSE linux.
    - pmjordan 16y ago
      It's actually just the default bash config on openSUSE, nothing to do with Konsole. It works on text-mode VTs, via ssh, etc.
  - mgedmin 16y 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).
joshfinnie 16y 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?
- there 16y 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 16y ago
    Oh please yes. + a bucket load for code.google.com which comes up a lot and would provide nice glanceable info.
- corin_ 16y 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.
  - joshfinnie 16y ago
    Let's just call it me being way over tired. Definitely not an easy mistake to make.
- raganwald 16y ago
  I agree. foo.github.com and github.com/foo are the important domain considerations.
- wtracy 16y 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.
stephen 16y 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 16y 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 16y 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 16y 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 http://geek.swombat.com/setting-up-terminalapp-with-tr-0
Loic 16y 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 http://www.fabfile.org
- abstractbill 16y 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 16y 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.
- pak 16y ago
  Or for those less python-happy: just use expect http://en.wikipedia.org/wiki/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 16y 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.
    - pak 16y ago
      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 http://trac.mcs.anl.gov/projects/bcfg2) which I have seen in action and it works but is very XML-heavy.
pavel_lishin 16y 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 16y 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 http://img.ly/images/663862/full
reedlaw 16y ago
This doesn't work with GNU Screen.
morganpyne 16y 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 16y ago
Debugging is sweet, And so are you.
torpor 16y ago
Welcome to the 80's, sheesh. Doesn't anyone realize that this is exactly what TERM, BGCOLOR, and PROMPT have been being used for, for years?

173 points by jeffmiller 16y ago

olalonde 16y ago

Any chance it is possible to accomplish on Ubuntu?

there 16y ago
you could use something like xtermcontrol (http://www.thrysoee.dk/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 16y 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 16y 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 16y 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 16y 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.

moe 16y ago

Colorful shell prompts can be used for the same purpose.

there 16y ago
except when you're doing something like editing a file, tailing a log, or doing anything other than staring at a command prompt.
- moe 16y 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.
  - po 16y ago
    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 http://code.google.com/p/iterm2/issues/detail?id=454
    - moe 16y ago
      Wow, pretty cool! As an iTerm user I'll be looking forward to that.

protomyth 16y 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 16y 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 16y 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 16y 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 16y ago
  Konsole does this automatically, at least on openSuSE linux.
  - pmjordan 16y ago
    It's actually just the default bash config on openSUSE, nothing to do with Konsole. It works on text-mode VTs, via ssh, etc.
- mgedmin 16y 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).

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

there 16y 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 16y ago
  Oh please yes. + a bucket load for code.google.com which comes up a lot and would provide nice glanceable info.
corin_ 16y 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.
- joshfinnie 16y ago
  Let's just call it me being way over tired. Definitely not an easy mistake to make.
raganwald 16y ago
I agree. foo.github.com and github.com/foo are the important domain considerations.
wtracy 16y 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.

stephen 16y 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 16y 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 16y 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 16y 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 http://geek.swombat.com/setting-up-terminalapp-with-tr-0

Loic 16y 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 http://www.fabfile.org

abstractbill 16y 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 16y 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.
pak 16y ago
Or for those less python-happy: just use expect http://en.wikipedia.org/wiki/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 16y 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.
  - pak 16y ago
    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 http://trac.mcs.anl.gov/projects/bcfg2) which I have seen in action and it works but is very XML-heavy.

pavel_lishin 16y 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 16y 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 http://img.ly/images/663862/full

reedlaw 16y ago

This doesn't work with GNU Screen.

morganpyne 16y 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 16y ago

Debugging is sweet, And so are you.

torpor 16y ago

Welcome to the 80's, sheesh. Doesn't anyone realize that this is exactly what TERM, BGCOLOR, and PROMPT have been being used for, for years?