NIS provides a central location at which you can store certain important
configuration files. Almost every NIS server is used to serve 'passwd'
among the machines on a network, and sometimes it's used for 'shadow'.
Other things you can share include 'group,' 'hosts' and 'netgroup.'

These files, when shared using NIS, do the exact same job that locally
stored versions in /etc do. A NIS server makes, for example, 'passwd'
available to any machine that is set up to connect to the NIS server
(the connecting machine is called a 'client'). You can then configure
any of the client machines to include the NIS version of the file in
their normal lookup process, and you can configure the order in which
they use them - that's what '/etc/nsswitch.conf' does.

It is also often useful to share the hosts file between machines, so
that they all have the same hosts information without you having to
synchronise the hosts files.

Because NIS shares files in this way, it is only usable for Unix and
Linux authentication; to authenticate windows, you most likely need to
use samba on the auth server. I vaguely remember hearing that you can
get samba to take it's auth info from the NIS, but I have never tried to
do that. 

Basic NIS 101:

Let me try and explain NIS with an example:

Let's say you have a NIS server called "penguin" and two client machines
called "snowman" and "polarbear". You want to set it up so that you can
log in to any of the machines with the same password. You also want to
allow your friend Sarah to log in to snowman only.

What you could do is set up penguin's shared passwd file with an entry
for you ("paul:gjz*Z<G;kgwer:600:600:Paul, Systems mgr:/bin/bash") and
then run the NIS server software to make that available to clients.
Then, you create an entry in the passwd file on snowman for Sarah
("sarah:asF£$f:601:601:Sarah, Friend:/bin/bash") - Important to remember
that she has to have a different UID number to any user on the NIS.

Finally, you tell the clients during authentication to check for NIS
users, then if there aren't any matches to check for local users. (The
line in nsswitch.conf might look like: "passwd:   nis, files")

Now, when you go to snowman, and log in, it sends a request to penguin
for the NIS copy of the passwd file, which it then checks to see if your
username exists in the NIS. In your case it does, so it allows you to
log in as normal - even although you don't actually have an account on
snowman. Similarly, you can log into polarbear in the same way.

When Sarah logs in on snowman, it asks penguin for the passwd file, then
checks for Sarah in that file. She's not there, so it then looks in
/etc/passwd to see if Sarah exists. It finds that she does and login
proceeds as normal.

If Sarah tries to log in on polarbear, it will refuse, because she
doesn't have an account on polarbear.


On balance, NIS isn't really worth it if you have less than 3 machines
with less than 5 users and not very tight security requirements. for the
example I gave, NIS is overkill. However, if you then wanted to add more
machines to the network, with the minimum of set up, you only need to
connect them to NIS and they have access to all the shared information.


Paul.

On Wed, 2002-10-30 at 19:26, Paul Kraus wrote:
> I am reading the NIS how-to and am a little unclear as to what NIS is
> capable of. If I understand this right then I can store usernames and
> password on the NIS server. Then whenever someone try's to login to a
> machine (windows, UNIX, or Linux) it will poll the database for
> authentication? For instance I try and telnet to my Linux box when I log
> in rather then the Linux machine checking its local user account info it
> would turn to the database? Sorry but this is kind of confusing me.
> 
> Paul Kraus
> Network Administrator
> PEL Supply Company
> 216.267.5775 Voice
> 216-267-6176 Fax
> www.pelsupply.com
-- 
Paul Furness

Systems Manager

Steepness is an illusion caused by flat things leaning over.

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Reply via email to