Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Problems with sudo



On Mon, Nov 30, 2009 at 12:49 PM, Kevin D. Clark
<kevin_d_clark-Wuw85uim5zDR7s880joybQ at public.gmane.org>wrote:

>
> Dan Ritter writes:
>
> [in a hypothetical memo from senior_manager]
> >   Root or administrative privileges are available by default for
> >   your desktop (or laptop) systems. You must keep the existing
> >   /etc/sudoers file intact to allow sysadmin staff to assist
> >   you.
> >
> >   No one will directly use a root or administrative privileged
> >   account on any development or production system, except for
> >   authorized sysadmin staff. Privileges may be granted via
> >   'sudo' for specific users on specific machines.
>
> OK, I'll bite.
>
> Let me ask a not-very-hypothetical question.  Suppose I am an engineer
> who writes code all day long.  Suppose I have a Linux development
> machine [1], provided to me by ${the_company}.  Suppose that I am a big
> fan of "Meld", the graphical diff tool.  Suppose that, in order to get
> my work done, I want to install Meld onto my development machine.
>
> What is the right way for me to go here?
>
> 1:  for me to install this myself.
>
> 2:  for me to contact the sysadmin staff and have them
>    install this for me.
>
>
> Thanks.
>
> --kevin
>
>
> [1]  I am very specifically asking this question about
>     development machines and not production machines.
>
> --
> GnuPG ID: B280F24E                God, I loved that Pontiac.
> alumni.unh.edu!kdc                -- Tom Waits
> http://kdc-blog.blogspot.com/
> _______________________________________________
> Discuss mailing list
> Discuss-mNDKBlG2WHs at public.gmane.org
> http://lists.blu.org/mailman/listinfo/discuss
>

I should clarify a few things.  First, our company being a startup gives
each developer the freedom to use their own laptop for dev purposes however
they see fit.  They run whatever OS they want and maintain it themselves as
long as they don't say they can't do their job because a piece of software
doesn't run on their OS.  This isn't what I'm worried about.  In our
datacenters, we have Dev, QA, Staging and Production servers.  The dev
servers are more of an integration environment to test the dev code with
other projects' dev code before anything moves to QA.  For example if you
make changes to an API, does it break anything extremely obvious with other
systems so you don't have to waste QA's time.  I'm not even really concerned
at this point with the Dev, QA and Staging servers.  My main concern is the
Production servers, since those are the ones that keep us up at night when
things break.

Also this startup from day one only had 2 developers and 2 Ops/Sysadmin's.
The 2 dev's were extremely trustworthy and had pretty good Linux knowledge.
They were also extremely good when it came to letting Ops do their job but
lending a hand when asked, but keeping their fingers out of where they
shouldn't be.  It's only recently we've had issues with a few individuals
that feel they can't do their job without their fingers in every place.

Anyway, I've taken all the suggestions about the making it more of a policy
and after some incidents last week, I've had some positive feedback from my
VP about making our flimsy soft policy a more concrete one.  Thank you all
for the suggestions.

-matt
http://www.sysadminvalley.com
http://www.beantownhost.com
http://www.linkedin.com/in/mattboston
Marie von Ebner-Eschenbach<http://www.brainyquote.com/quotes/authors/m/marie_von_ebnereschenbac.html>
- "Even a stopped clock is right twice a day."






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org