An NFS and NIS Crash Course Primer

Jon Kuroda

CUSG

What is NIS? What is NFS? How do they interact?

• NFS is the Network File System
  • Allows remote filesystems to be accessed as if on the local system
  • Permits many systems to access the files without copying between systems
  • Examples: /usr/sww, /home/{cs,eecs,ee}/, /project/{cs,eecs}/


• NIS is the Network Information System, aka Yellow Pages
  • Network access to information normally stored in local text files
  • Permits many systems to access the same information store
  • Examples: /etc/{passwd,group,networks,hosts,services,rpc,bootparams,ethers,...}
  • Think simple online database, called 'maps'.
    It's like LDAP, only simpler and it doesn't use WeightGain 4000

NIS can be used to control access to NFS 'shares' as well to control login access to systems that support it. They can be used separately or in conjunction to varying degrees. NIS can also make it easier to manage where remote NFS shares show up in the local filesystem.

NIS

NIS helps to centralize the management and distribution of data that would normally be kept in various text files replicated on multiple systems. What does this mean?

Lets look at /etc/passwd as an example:

root:*:0:0:Root,,,:/root:/usr/local/bin/tcsh
www:*:33:33:www-data:/var/www:/bin/sh
backup:*:34:34:backup:/var/backups:/bin/sh
list:*:38:38:Mailing List Manager:/var/list:/bin/sh
gnats:*:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:*:65534:65534:nobody:/nonexistent
smmta:*:102:104:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false
smmsp:*:103:111:Mail Submission Program,,,:/var/lib/sendmail:/bin/false
www:*:124:65533:WWW proto account:/nonexistent:/nonexistent
braino:*:1001:100:Branislav P:/home/sgi/braino:/bin/tcsh
marvin:*:1002:100:Marvin C:/home/sgi/marvin:/bin/tcsh
steve:*:1044:100:Steve C:/home/sgi/steve:/bin/tcsh
dk:*:1083:100:Donald K:/home/sequent/dk:/bin/tcsh
kj:*:1094:100:Kevin J:/home/apollo/kj:/bin/tcsh
helper:*:1123:100:Unix Help Sessions:/home/sgi/helper:/bin/tcsh
mogul:*:1214:100:Bret Mogilefsky:/home/digital/mogul:/bin/tcsh
celina:*:1270:100:Celina Salazar:/home/digital/celina:/bin/tcsh
chen:*:1281:100:Thomas S.T. Chen:/home/digital/chen:/bin/tcsh
stephanb:*:1364:100:Stephan B:/home/sgi/stephanb:/bin/tcsh
andrewo:*:1390:100:Andrew O:/home/digital/andrewo:/bin/tcsh
brianl:*:1446:100:Brian L:/home/digital/brianl:/bin/tcsh
david:*:1449:100:David B:/home/sequent/david:/bin/tcsh
...

NIS intro example

Say we had the same users on a dozen systems. Keeping all those passwd files in sync would suck. What if we could maintain all that in one place and say "get all these users' information from the central source"? Well NIS lets us do that.

Now let's look at /etc/passwd:

root:*:0:0:Root,,,:/root:/usr/local/bin/tcsh
www:*:33:33:www-data:/var/www:/bin/sh
backup:*:34:34:backup:/var/backups:/bin/sh
list:*:38:38:Mailing List Manager:/var/list:/bin/sh
gnats:*:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:*:65534:65534:nobody:/nonexistent
smmta:*:102:104:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false
smmsp:*:103:111:Mail Submission Program,,,:/var/lib/sendmail:/bin/false
www:*:124:65533:WWW proto account:/nonexistent:/nonexistent
+@users::::::
+::::::/bin/nopayment

Much better shorter. The line with '+@users' at the front means "replace this with the entries from the passwd 'map' for all the people in the 'users' netgroup." What's a netgroup? That is another slide coming up. What about the line at the end? That says that anyone else who might be in the passwd map but not in the 'users' netgroup will get '/bin/nopayment' as their shell -- on login, they will be told "you didn't pay your bill, pay your bill to be let back in."

NIS example

What else can we do with this? We can also allow entry for individual logins:

root:*:0:0:Root,,,:/root:/usr/local/bin/tcsh
www:*:33:33:www-data:/var/www:/bin/sh
backup:*:34:34:backup:/var/backups:/bin/sh
list:*:38:38:Mailing List Manager:/var/list:/bin/sh
gnats:*:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:*:65534:65534:nobody:/nonexistent
smmta:*:102:104:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false
smmsp:*:103:111:Mail Submission Program,,,:/var/lib/sendmail:/bin/false
www:*:124:65533:WWW proto account:/nonexistent:/nonexistent
+jon::::::
+lars::::::/bin/nethask
+bira::::::/bin/notallowed
+@users::::::
+::::::/bin/nopayment

So, I can login without having to be in a special netgroup, and Lars gets to login, but only to play nethack. Bira paid his bill, but did something bad, so even though he might be in the 'users' netgroup (because billing said he paid his bill), he's told that his account is inactive for doing something bad.

NIS Utilities

Can we see what is in the passwd and other maps? Yes we can!

• ypwhich
  • shows you which ypserver you are using - 'bind to a server'
  • with the -m flag, shows you available maps - 'ypwhich -m'
  • with the -x flag, shows you nicknames for some maps - 'ypwhich -x'
• ypcat
  • show the 'value' stored in a a map
  • the "-k" flag will also show the 'key'
  • can combine with other shell tools (grep, perl, ...)
• ypmatch
  • find the value for a particular key in a map

That netgroup map - What is it? What does it do? Can it make coffee?

The netgroup map consists of named groups (called netgroups) of machines and/or users. Netgroup entries look like this:

cusg-l (,allai,) (,ann,) (,ardeshir,)   (,bira,) (,cspeerca,) (,diulama,) (,jkuroda,) ...
cusg-c avner.eecs babushka.eecs bahia bokeh.eecs cusg-solaris zim.eecs ...
zim.eecs (zim.EECS.Berkeley.EDU,-,)
cusg-solaris mahler.eecs milhaud.eecs

There are four netgroups there - cusg-l, cusg-c, zim.eecs and cusg-solaris - each with multiple members. The most basic form of a netgroup member is:

(host, user, domain)

In fact, you can have something like this: (zim.eecs.berkeley.edu, jkuroda, -) and depending on what is looking at that netgroup member, it may only care about the host part or the user part. But for general sanity, in EECS, netgroups are either all users or all hosts. Also, netgroups can be nested -- that is, they can have other netgroups as members.

About that domain part, that's never used around here since we only have one NIS domain - the 'mammoth' domain - but it can be used to refer to users and hosts from other NIS domains. More info

So, what good are they to us in EECS?

Well for one thing, we can use netgroups to control who has access to a system

Remember those +lines in /etc/passwd?

+@yelick-logins:x:::::
+@jwd-l:x:::::
+@cusg-l:x:::::
+@manager-logins:x::::/home:
+:x:::::/usr/sww/share/etc/nologin

If a user's login is in the yelick-logins, jwd-l, cusg-l, or manager-logins netgroups, then they may login to that system. Everyone else gets the "nologin" shell. Notice how for people in manager-logins, they don't get their normal homedirectory.

argus% ypmatch yelick-logins netgroup
manager-logins (,ankit,) (,arnold,) (,asolar,)  (,bonachea,) (,chsuc,) (,csbell,) ...

NFS exports and netgroups

NFS shares can be exported to a list of systems, and our NFS servers can use netgroups in these lists.

% showmount -e coeus | grep -i jkuroda
/vol/vol0/eecs/jkuroda  all-c,cusg-c,iram-c,mill-c

My homedirectory is exported to the all-c, cusg-c, iram-c, and mill-c netgroups So, as far as the NFS server is concerned, I can access my homedirectory on every system in those netgroups

Putting it all together, the user request

A grad student walks in (or sends email) asking to be able to login into a system, say comix.CS.Berkeley.EDU. What are the steps involved in getting this grad student access to login into comix.CS.Berkeley.EDU?

Here is the most general list of steps:

1. Get permission from the owner of comix.CS for Joe Grad to login
2. Get permission from Joe Grad to export his homedir to comix.CS.Berkeley.EDU
3. Send appropriate requests to IDSG to modify netgroups and export lists

Step 1, Get permission from the owner of the system

Well, first, who owns the system? We can use the IRIS Network Query Forms which should tell us which research group is associated with the system, but sometimes that may not get us a useful answer. If not, we can use the netgroup map and take an educated guess:

% ypcat -k netgroup | grep -i comix
cusg-clients-2 cad.eecs chebar.eecs     citrissrv1.eecs citrissrv2.eecs         citrissrv3.eecs columbia.eecs comix ...
...
yelick-c all-c aquarium brawnix camaro comix    fa hemlock i    lotus   plane redwood ribbit saab si sophia 
comix (comix.CS.Berkeley.EDU,-,)

We can guess that Professor Yelick owns the system, so we can ask her:

Professor Yelick, 

Joe Grad has requested access to login to the systems in your group, is this okay?  

--Bob Helpful
  EECS Helpdesk

Now, when might we be able to assume that this is okay with Professor Yelick?

Getting permission to export a user's homedir

We don't need to do this here. By asking for access, Joe Grad has implicitly given that permission. Is there ever a case where we would have to explicitly ask for it?

Asking IDSG to modify netgroups and export homedirs

We know comix is in the yelick-c netgroup, so we can ask IDSG to export Joe Grad's homedir to the yelick-c netgroup. But what about getting him login access?

As it turns out, by unwritten convention, for every "-c" netgroup there is a corresponding "-l" or "-login" netgroup. So for Professor Yelick's group, there is a yelick-c netgroup consisting of the systems her group has, and a yelick-logins netgroup consisting of the people in her group. So we also ask IDSG to add Joe Grad to the yelick-logins netgroup.

NFS Basics

• Server
  • Makes available or 'exports(v)' a number of filesystems, called 'shares' or(confusingly) 'exports(n)' to other systems
  • Controls which systems can have access and, to a certain extent, what sort of access to shares
• Client
  • Attaches or 'mounts' shares from one or more servers to the local filesystem at various 'mountpoints'
  • May have further control over how local users access files located within a filesystem mounted from a remote NFS server