Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Jun 2016 22:00:31 -0400 (EDT)
From:      Daniel Eischen <deischen@freebsd.org>
To:        Zaphod Beeblebrox <zbeeble@gmail.com>
Cc:        Chris Watson <bsdunix44@gmail.com>, freebsd-fs <freebsd-fs@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject:   Re: The small installations network filesystem and users.
Message-ID:  <Pine.GSO.4.64.1606202130170.10181@sea.ntplx.net>
In-Reply-To: <CACpH0MfYAe4JG5r3QmZ7B9jZWR3DTf-Hfb8Xrq1JiKdGpG5i0Q@mail.gmail.com>
References:  <CACpH0MdJ0YjtB-H5h-7u%2BdC%2BbbjVhN-Y7ejM7u7W-SL01qC3aA@mail.gmail.com> <9BB7E8B3-EC0E-457E-B2B2-FB80B1CF02B0@gmail.com> <CACpH0MfYAe4JG5r3QmZ7B9jZWR3DTf-Hfb8Xrq1JiKdGpG5i0Q@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Jun 2016, Zaphod Beeblebrox wrote:

>
> That-all-said, authentication is a possible huge win.  I was recently
> involved in a deployment of ubuntu that included LDAP and even though it
> was a mess, it eventually was hammered into working.  Ubuntu and the
> implementation were not my choice, but you do-what-you're-told when someone
> else is paying the bill.  Honestly, I don't know how I would have pitched
> FreeBSD there.  Not even ubuntu itself had LDAP right.  It was a
> combination of third parties.  Even with that gigantic head start, LDAP was
> a bear --- but AFAICT, LDAP is _required_ for NFSv4 deployments.  Now, LDAP
> without Winblows is slightly less of a bear, _but_
>
> Maybe this dovetails with a subtext at BSDCan's keysigning BOF: that many
> projects risk irrelevance with their complexity.  It's not that I believe
> complex setups are bad.  But simple things need be simple.  I have 3
> machines at home (for instance) and a cluster of 8 machines in colo (run
> the ISP).  On my 3 machines at home, I run NFSv3 because it works and I can
> get it setup. I'd like to run NFSv4 because then my windows machines would
> look at it, but I run SMB instead (v3, no less) because it roughly works.
> So at home... I have three machines and a fairly liberal hacking time
> budget.  I have failed at LDAP several times.  I'm back to copying the
> master.password file around because that works.  I don't like it, but it
> works.  It seems like the breakeven for LDAP effort vs. scp master.password
> is somewhere around 50 machines.  -ish.
>
> I realize the real problem is that authentication has become more complex
> in the world since networks can't be trusted.  I have to wonder if we're
> getting back closer to that now with all the tunneling on wifi and campus
> networks.  Sigh.  I'm starting to feel like this whole post has no purpose.

We should support LDAP client out of the box, in base.  What
sucks now is that we need 3 packages (plus their dependencies)
and multiple config files for ldap:

   pam_ldap
   nss_ldap
   openldap-client

And modify/tailor 3 config files in ${LOCALBASE}, all similarly:

   ldap.conf
   nss_ldap.conf
   openldap/ldap.conf

Then the secret files also in ${LOCALBASE}, again with the same
info:

   etc/ldap.secret
   etc/nss_ldap.secret

Then you have to deal with the certificates, and more than one is a
pain.

Then in ${BASE} you have to add an ldap file in /etc/pam.d/.  And
modify /etc/nsswitch.conf.

It seems easier, with less config duplication, in Solaris (11):

   # Initialize the NSS database.
   $ certutil -N -d /var/ldap
   $ chmod 444 /var/ldap/*.db

   # Add your certificate(s).
   $ certutil -A -n <certname> -i /tmp/certfile.pem -t CT -d /var/ldap

   # Setup the system as an LDAP client.
   $ ldapclient init <various ldap config options>

Modifying /etc/nsswitch.conf on FreeBSD is easier than Solaris, still
haven't gotten use to the many keystrokes needed for svc mods:

   $ svccfg
   svc:/system/name-service/switch> setprop config/host = astring: "files dns"
   svc:/system/name-service/switch> setprop config/password = astring: "files [NOTFOUND=continue] ldap"
   svc:/system/name-service/switch> setprop config/group = astring: "files [NOTFOUND=continue] ldap"
   svc:/system/name-service/switch> select system/name-service/switch:default
   svc:/system/name-service/switch:default> refresh
   svc:/system/name-service/switch:default> validate
   svc:/system/name-service/switch:default> quit
   $ svcadm refresh name-service/switch

-- 
DE



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1606202130170.10181>