The small installations network filesystem and users.

Daniel Eischen deischen at freebsd.org
Tue Jun 21 02:11:17 UTC 2016


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


More information about the freebsd-hackers mailing list