Aw: Re: Protecting production from "us"
From: Ingrid Voigt <giantpanda_at_gmx.net>
Date: Thu, 3 Dec 2015 20:44:09 +0100
Message-ID: <trinity-b30e2ae2-f4b1-47df-9140-2025c2117d7b-1449171848959_at_3capp-gmx-bs48>
--
http://www.freelists.org/webpage/oracle-l
Received on Thu Dec 03 2015 - 20:44:09 CET
Date: Thu, 3 Dec 2015 20:44:09 +0100
Message-ID: <trinity-b30e2ae2-f4b1-47df-9140-2025c2117d7b-1449171848959_at_3capp-gmx-bs48>
I rarely use putty (we are a Windows shop), but in similar situations:
For SQL Plus Sessions: Set the prompt to username_at_dbname. In addition always manually
query "select host_name, instance_name, status from v$instance;" before doing anything critical.
Train yourself to actually read the output.
For Windows RDP Sessions: Always have a tool display host information on the desktop background
(sysinternals bginfo does this)
For the DBAs: We can always say "I am too tired / unable to focus and shouldn't touch a database
today. Let me clean up my emails for a while / read oracle-l / ... and go home early."
As long as this only happens once in a while nobody will mind.
Regards
Ingrid
Gesendet: Donnerstag, 03. Dezember 2015 um 20:05 Uhr
Von: "Jeremy Schneider" <jeremy.schneider_at_ardentperf.com>
An: HerringD_at_dnb.com, Oracle-L <oracle-l_at_freelists.org>
Betreff: Re: Protecting production from "us"
Von: "Jeremy Schneider" <jeremy.schneider_at_ardentperf.com>
An: HerringD_at_dnb.com, Oracle-L <oracle-l_at_freelists.org>
Betreff: Re: Protecting production from "us"
On Thu, Dec 3, 2015 at 11:45 AM, Herring, David <HerringD_at_dnb.com> wrote:
> · Should we look into some kind of additional controls where
> commands like "srvctl stop…" cannot be run under our own accounts using
> "sudo -u oracle" but instead need a different account on production? For
> example, normally our unfortunate DBA would use his "scapebob" Linux account
> but perhaps to perform a production shutdown he'd need to connect as
> "scapebob-rw", a new, special account just for dangerous production
> activities.
I think that I'd be hesitant to introduce too much variation between
production and test environments when it comes to processes. It's a
major advantage if you can test your processes in the test tier, then
run those same processes verbatim (key-for-key) in production
afterwards.
> · The problem in our situation was over confusion with multiple
> windows. Do people set a Linux TMOUT to something short like 10 or 15
> minutes, to hopefully avoid accidentally leaving production putty sessions
> open?
I feel like a short timeout is likely to cause more frustration in the
trenches than what it's worth, for anyone who spends any significant
amount of time troubleshooting production systems. Often you have
multiple windows open and switch between them... an aggressive timeout
really makes that much more difficult.
> · Beyond changing the linux prompt and text colors (we set $PS1 with
> escape sequences and various key, env-specific values) do you do anything
> else for protection of production?
Personally, I think background color is your best bet. Only difference
from Alfredo's suggestion would be that I'd prefer having it be
controlled server-side rather than relying on each engineer to setup
all their terminal connections correctly. Not to mention that you
could get the *wrong* bg color if it's client-side and somehow
somebody ssh's between tiers.
--
http://about.me/jeremy_schneider
--
http://www.freelists.org/webpage/oracle-l
> · Should we look into some kind of additional controls where
> commands like "srvctl stop…" cannot be run under our own accounts using
> "sudo -u oracle" but instead need a different account on production? For
> example, normally our unfortunate DBA would use his "scapebob" Linux account
> but perhaps to perform a production shutdown he'd need to connect as
> "scapebob-rw", a new, special account just for dangerous production
> activities.
I think that I'd be hesitant to introduce too much variation between
production and test environments when it comes to processes. It's a
major advantage if you can test your processes in the test tier, then
run those same processes verbatim (key-for-key) in production
afterwards.
> · The problem in our situation was over confusion with multiple
> windows. Do people set a Linux TMOUT to something short like 10 or 15
> minutes, to hopefully avoid accidentally leaving production putty sessions
> open?
I feel like a short timeout is likely to cause more frustration in the
trenches than what it's worth, for anyone who spends any significant
amount of time troubleshooting production systems. Often you have
multiple windows open and switch between them... an aggressive timeout
really makes that much more difficult.
> · Beyond changing the linux prompt and text colors (we set $PS1 with
> escape sequences and various key, env-specific values) do you do anything
> else for protection of production?
Personally, I think background color is your best bet. Only difference
from Alfredo's suggestion would be that I'd prefer having it be
controlled server-side rather than relying on each engineer to setup
all their terminal connections correctly. Not to mention that you
could get the *wrong* bg color if it's client-side and somehow
somebody ssh's between tiers.
--
http://about.me/jeremy_schneider
--
http://www.freelists.org/webpage/oracle-l