I just had to comment here because my experience has been completely
the opposite from Dean's.
A "Dev" system is one where development is done, and for me that means
a very specific environment - from kernel params being set right all
the way up to exactly which version & patch of all databases that are
installed. Everything is tightly controlled and keeping the systems
properly configured is essential. But we are a hard-core C++ shop,
across 5+ OSs.
We definitely do not use systems that are generic boxes. They aren't
usually backed up (only critical development data is) but how they are
configured is well understood and monitored automatically so they can
be rebuild if necessary.
I would absolutely not want a DBA to have full root on one of my
systems. I would be very afraid of one installing a required patch
that also effected a system library and therefor effected the product
in a subtle way. Our product beats the c*rp out of systems and we
care very much what the system setup is. We can't have all patches
applies to a system, to the point that we have not installed some that
we felt we should probably have (not security related) but didn't feel
the risk was worth it.
Dean's description might fit his environment, and I could see that a
DBA having root in that setting wouldn't be as much of an issue. But
in many places that I have worked keeping a tight control on dev boxes
is absolutely required.
I had sent a message directly to Sharon when she initially posted
this. I basically agreed with Jason's comments. IMO - If the DBAs
want full control over the system, then I think she should wash her
hands of those systems and be responsible for as little as possible on
them (like say backup and restore of the important bits.) If she
can't control that things are done reasonable, then she shouldn't be
responsible for fixing them (she should be available to *help* fix
them, but that is different than being responsible.) Politically this
might be impossible... but it is what I would push for.
Eric
On 8/21/06, Dean Anderson <[EMAIL PROTECTED]> wrote:
On Sun, 20 Aug 2006, Sharon Nagao wrote:
> I was informed last week by my manager that the DBAs is to have full root
> access to all Dev and Test servers in our environment.
This is a too-frequent reaction from admins in an engineering
environment. Admins are taught to establish backups, stability, and
security, without much reference to when these goals are unnecessary or
inappropriate.
The key term is here is "Dev and Test". In every development environment
I've worked in, the "Dev and Test" servers are generic boxes, whose up
or down time is entirely up to the engineering department. The
professional sys-admin's assist the engineers with know-how on things
like 'what has to be plugged where', or 'how do I get started with
installing a new OS' but don't have a lot of responsibility for the
uptime of the system. By definition, "dev and test" systems have a lot
of downtime as engineers reconfigure for different environments.
I wouldn't worry too much about 'dev and test' systems. Help the
engineers run them. But production level monitoring is not needed,
since the machines only exist for the purpose of installing and testing
new software. Backups aren't usually needed, and frequent
re-installation from scratch is a good thing for engineering.
DBA's probably wouldn't need root access to a production machine, but
root to devel is frequently essential. This is good advice to the
engineering staff--they need to remember that certain activities in
production environments won't be given to end users or even to DBAs.
But remember that you probably don't want to become a member of the QA
staff, either.
It's when the systems need to be backed up and kept stable and kept
secure that you need to get involved with production-type monitoring and
restrictions. Those are your "trigger words". If you don't need these
things, then you don't need restricted control either.
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
bblisa mailing list
[email protected]
http://www.bblisa.org/mailman/listinfo/bblisa
_______________________________________________
bblisa mailing list
[email protected]
http://www.bblisa.org/mailman/listinfo/bblisa
