Re: [Sheflug] AccessSpace NIS (lots of Q's)

[Matthew Palmer <nospam [at] ieee.uow.edu.au>]

On Wed, 4 Apr 2001, James Wallbank wrote:

> Here's my reactions and observations so far - and a stack of 
> what-does-this-actually mean-type dumb questions. Am I getting the 
> wrong end of the stick, or does our emerging proto-plan seem like it 
> might work?
> 
> NFS ====>
> We don't seem to have much trouble with NFS on its own. Maybe I'm 
> missing something, but NFS _seems_ entirely stable. It's the NIS 
> that's a pain in the r*ctum. Have we just been lucky with NFS?
> 
> What sorts of problems usually manifest themselves with NFS? Should 
> we stick with it, or bite the bullet and go for OpenAFS?

NFS tends to give a lot of bugs in the area of locking, file permissions,
and "unable to monitor" type log messages.  It's pretty tidy, though, and if
you're not having problems with it I'd stick with it for the low-security
environment you're using.  AFS is a system for those concerned about
security and scalability - If an NFS server goes down, then you lose access
to the data on there, and can't do anything with it.  It's possible, with
AFS, to configure it so that if one server goes down you've got a backup
copy ready to go which can be switched to seamlessly, or at the very least
you can work with cached files and save files to a temporary hold buffer
(handled by the OS) until the server reappears on the network, when
everything gets updated happily.  Access Control is also better in AFS.

As I said, though, if things are hunky dory with NFS, stick with it.  AFS
probably isn't worth the headache in your situation.

> NIS ====>
> Argh! I hate those binary config databases, and all of that remaking 
> of them every time you have to add a new user. Basically, I don't 
> like any config files that aren't plain text. (I don't trus what I 
> can't see!)
> 
> Does LDAP have plain text config files? If it does, hell, I'm in 
> favour, even if they are complex!

LDAP does not specify the format of it's files.  OpenLDAP, which is the
implementation of LDAP you'd be using, uses plaintext config files and a
binary data storage format.  Usually you'll use the available tools to
manipulate data in the database (there are command line tools, or you can
get several free GUI 'explorer' type tools to work with the database). 
Editing text files and remaking databases from them is something you should
never *have* to do, although backups of the data are typically made by
dumping all data to a text file and then saving the text file, which can be
read into a new database if the system goes ker-thunk.

> LDAP ====>
> We've just been given a load (16) of 166-200mhz Pentiums with 32mB 
> RAM. Do you reckon they'd be beefy enough to run LDAP without too 
> much logon lag?

They'll do the job quite nicely, especially if you take the 32MB of RAM in
one and stick it in another, and then use that heavily RAMed one as the
server.

While your at it, could you send one this way?  <g>

> PAM ====>
> I don't really understand the relationship between PAM and LDAP. (If 
> there is one...) What are "Pluggable Authentication Modules"? Are 
> they the bits of data served out by LDAP? I'm struggling. Please help!

PAM is a system for separating the function of authenticating users from the
application.  Rather than having to modify every program that needs to
authenticate a user whenever you change auth mechanisms (say going to LDAP,
or NIS, or Radius, or whatever) you can just make all programs call a PAM
module, which takes the user's credentials (usually username and password)
and then makes a decision about whether the user is OK or not, and tells the
application.  The application is told which module to use by a config file
(in /etc/pam.d/<appname> usually) but knows nothing about what the module
does to authenticate the user - it just knows that if the module returns
'yep, they're good' that they can let the user do whatever they were going
to do.

That's simplified, but it's all that's needed for now.

> SMB ====>
> We have a Samba print server running which we (sort of) understand. 
> Hell, it works! It's clearly within our powers to learn this sort of 
> thing, but I don't want to flail around researching stuff when its 
> inappropriate for our purposes. (That's why I'm asking all of these 
> dumb questions).
> 
> What advantages might there be of running Samba over NFS in 
> preference to just plain NFS for remote directory mounting? Could we 
> run Samba over OpenAFS? Why?

One doesn't run Samba 'over' AFS or NFS.  AFS, NFS, and the file bits of SMB
are all doing the same thing - sharing files.  Therefore, Samba is an
alternative to AFS or NFS.  It's possible to run the two systems in parallel
(Samba serves files to Windows boxes, NFS or AFS serves files to Unix boxes)
but you don't have Samba layered on top of NFS.

> What about print servers? Which is best, Samba, plain remote 
> printers, or some other system? (Remember, think "lightweight"!).

If you're not running anything windows, I'd recommend dumping Samba.  It
requires a second password database, and it's a pain.

I'd use lprNG for printing, since it's open, free, and works like a charm
here.  You could have a look at CUPS, but I don't think it's perfectly
'free', so YMMV.

> OpenAFS ====>
> Does this work as a pretty-much direct alternative to NFS? (i.e. 
> Server daemon with permissions set in a config file, Client daemon 
> readily available and lightweight, so it's pretty much fire & forget?)
> 
> If yes and yes, and there are significant advantages over NFS, then 
> where do I get it? Now, now, now! ;-)

No, no, no.  It serves files, yes, but it's config, layout, and overall
operation are *very* different to NFS.  I'd steer clear unless you've got
much time and penchance for torture.

> Kerberos =====>
> What is it?
> 
> I think I get that (in layman's terms) LDAP is a "permissions 
> server", but what is Kerberos? A secure protocol for communicating to 
> an LDAP server? Will we need this if we're only logging on to 
> accounts from machines inside the space? Why? (Please let your 
> paranoia run wild if you're so inclined).

Kerberos is a system for authenticating users and services to each other. 
They don't have to trust each other, just a third party which is (it is
assumed) guaranteed to be secure.

LDAP is a data server, in the sense that you get information from it from
which you can make decisions.  Kerberos is an orthogonal technology - it
says that "this person knows their secret" and "this service knows it's
secret" without letting the other party in the communication know what the
secrets are.  You can use this to make sure that users are who they say they
are, without the chance of a password being sniffed on the wire.  Everything
is well encrypted, and everything's timestamped to prevent replay attacks.

All in all, unless you're planning on heading for AFS I'd not bother about
it.  LDAP can store passwords and pam_ldap can check them - I use kerberos
because it's a bit more secure, can help with a 'single token' policy, and
it's needed for AFS support.

> Not very clever, but robust.

Robust is the key to everything.  The system here isn't really robust at the
moment, and I spend too much time every day fixing things.  Argh.


-- 
-----------------------------------------------------------------------
#include <disclaimer.h>
Matthew Palmer
mjp16@ieee.uow.edu.au

---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.