%% jdmclemore@gmail.com writes:

j> The development group has a handful of Redhat servers (< 5
j> currently...might grow to 10 in a year or so) that are being installed
j> in the same location, and will be used by the same users as the prod
j> machines. The development servers, however, are owned/admin'd by a
j> different team with root access to those boxes - they don't and
j> shouldn't have root on production machines. They would like the
j> development servers to use NIS for all the current prod users, but
j> without giving up root access either way. Is this possible?

I guess I'm confused: what does using NIS have to do with root access?

Unless, you're planning on putting an R&D owned account with superuser
privileges (UID 0) into the NIS passwd database? Just don't do that.
Have the user accounts in NIS, and maybe a superuser account for the
admin team in NIS (if the development team is OK with the admin folks
having root on their boxes).

Let the development team have a superuser account they manage locally in
/etc/passwd on their systems.

Alternatively, if they're OK with it, you could just have them use sudo
(but, sometimes you just need the root password).

--
-------------------------------------------------------------------------------
Paul D. Smith HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions--Nortel takes no responsibility for them.

jdmclemore@gmail.com wrote:

>Wanted a little clarification on a situation currently happening
>here...
>
>At my company, there is a NIS enviroment controlled by Corp IT for
>production machines (Solaris/Redhat).
>The development group has a handful of Redhat servers (< 5
>currently...might grow to 10 in a year or so) that are being installed
>in the same location, and will be used by the same users as the prod
>machines. The development servers, however, are owned/admin'd by a
>different team with root access to those boxes - they don't and
>shouldn't have root on production machines. They would like the
>development servers to use NIS for all the current prod users, but
>without giving up root access either way. Is this possible?
>
>Local user mgmt is out of the question and a new NIS server just for
>development might be overkill....might be looking at rsync if the above
>won't work. And either of these two solutions still doesn;t allow users
>to use their prod accounts on develpmnt servers. Any ideas?
>
>
>
I don't recall the details, but it is possible to alter the files from
which the NIS master builds its database to omit root! Having done
that, each local machine must rely on its local /etc/passwd and
/etc/shadow for root.

jdmclemore@gmail.com wrote:
> Wanted a little clarification on a situation currently happening
> here...
>
> At my company, there is a NIS enviroment controlled by Corp IT for
> production machines (Solaris/Redhat).
> The development group has a handful of Redhat servers (< 5
> currently...might grow to 10 in a year or so) that are being installed
> in the same location, and will be used by the same users as the prod
> machines. The development servers, however, are owned/admin'd by a
> different team with root access to those boxes - they don't and
> shouldn't have root on production machines. They would like the
> development servers to use NIS for all the current prod users, but
> without giving up root access either way. Is this possible?
>
> Local user mgmt is out of the question and a new NIS server just for
> development might be overkill....might be looking at rsync if the above
> won't work. And either of these two solutions still doesn;t allow users
> to use their prod accounts on develpmnt servers. Any ideas?
>
If you're expecting server growth, I'd recommend looking into LDAP as an
alternative to NIS. LDAP allows for a high level of control over user
rights via group policy. In your case I'd recommend creating prod-root,
devel-root, prod-user, & devel-user groups and allocate users that way
(these are groups of machines which a user associated with that group
has access rights to). LDAP can easily be made secure via SSL, and it's
scales fairly well. The environment I previously implemented it on was
a mix of over 100 Solaris 8/10/RHEL3 machines.