Good lesson on making command prompts on machines always tell you exactly what machine you're working on.
Here's a generator for Bash: http://bashrcgenerator.com/, the prompt's format string is stored in the $PS1 variable.
RED=$(tput setaf 1)
NORMAL=$(tput sgr0)
PS1="\[${RED}\]PROD \[${NORMAL}\]\W\$ "
PROD ~$ <-- prod in red, directory ~
I run it on any dev environment since then.
i2-badge ()
{
printf "\e]1337;SetBadgeFormat=%s\a" $(echo -n "$1" | base64)
}
Recovery item 3f currently says:
> Create issue to change terminal PS1 format/colours to make it clear whether you’re using production or staging (red production, yellow staging)
I should probably make the PRODUCTION flash just in case.
And then, once you've started naming things as $ENV-$TYPE, someone will want to cram in the location, and the OS, and the team which maintains it, and the customer, and and and. Then someone will reduce all of those identifiers into single characters … and you'll be in the situation I mentioned. Clearly clpudb1 is CharlesCorp's first London production database system!
Here's how I view it:
The distinction between prod and dev is pretty clear cut. The words "dev" and "prod" have significantly different shapes and are immediately unambiguous. There's no need to remember a superhero vs astronomical object distinction.
As the number of database server instances grows, you've got another level of naming issues that arises when needing to distinguish between hosts and db server instances—and perhaps even database/schema independence if necessary. Staying consistent and easy-to-use with an arbitrary naming scheme becomes increasingly unwieldy, in my opinion.
I daresay - having hostname as part of prompt saves lot of trouble.
I work at a company where we have hundreds of database machines. Running this kind of command _anywhere_ without some kind of plan would be foolish. (It's one of the reasons why we have a datastore team that handles database administration.)
But the same lesson applies to application servers as well. Don't run deleterious commands out of curiosity. Have a peer-reviewed roll plan to act on when doing things like this. A role plan would have called for verifying the host before running the command.
But even before that, the issue should have been investigated more!
All of these things contributed to the failure. There should ideally be better ownership through dedicated roles, peer-reviewed processes for dangerous activities, and a better process for investigation that does not involve deleting things haphazardly.
uname -n
Takes seconds.