Matt Garman wrote:
> Our environment has several "classes" of servers, such as
> "development", "production", "qa", "utility", etc. Then we have all
> our users. There's no obvious mapping between users and server class.
> Some users may have access to only one class, some may span multiple
> classes, etc. And for maximum complexity, some classes of machines
> use local (i.e. /etc/passwd, /etc/shadow) authentication, others use
> Kerberos.
>
> With enough users and enough classes, it gets to be more than one can
> easily manage with a simple spreadsheet or other crude mechanism.
> Plus the ever-growing risk of giving a user access to a class he
> shouldn't have.
>
> Is there a simple centralized solution that can simplify the
> management of this? One caveat though is that our "production" class
> machines should not have any external dependencies. These are
> business-critical, so we try to minimize any single point of failure
> (e.g. a central server). Plus the production class machines are
> distributed in multiple remote locations.
>
> Any thoughts?
I agree completely with your manager: nobody but the production admins,
and the "system owners", should be allowed on the machine, unless you want
to allow selected sr. people to be able to get on in the event that
something that's just gone into production has just broken, to see if it
can be a quick fix, or whether you need to roll it back.
Likewise, neither developers nor "ordinary users" should be allowed on the
q/a systems, which ought to be clones of production, with the exceptions
of the new releases.
I'm not sure whether "ordinary users" should be allowed on dev systems,
unless they need to look in on what's going on.
In a true professional environment, only the admins get to move things to
prod; dev can promote in the VCS, and the testers can bring that in, then
promote so that the admins can roll that out during a prearranged
maintenance window.
All of this is easily done. We have the organization-wide AD (sigh), which
authenticates, and allows single sign-on, single password. Then there's
authorization.... We have a large /etc/password, but if you're not allowed
on, your shell is /bin/noLogin. <g>
mark
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
