[Beowulf] Poll - Directory implementation

Prentice Bisbal pbisbal at pppl.gov
Mon Oct 29 08:11:25 PDT 2018


On 10/27/2018 03:08 AM, John Hearns via Beowulf wrote:
> To be clear I am talking about the Name Service Cacheing Daemon
> I have always found this to be more trouble than it is worth  - it 
> holds on to out of date information,
> and needs to be restarted when you are debugging things like batch 
> systems etc.

My favorite feature of nscd was the paranoid option:

> *paranoia* /<yes|no>/
>
>
>     Enabling paranoia mode causes nscd to restart itself periodically.
>     The default is no. 
>

In practice, you need this. Otherwise, nscd will eventually hang, 
requiring you to login as root and manually restart nscd. When you see 
software with a feature like this, you know it's unreliable.
>
> nslcd is something completely different (*)   and whoever chose 
> similar names should be forced to watch endless re-runs of the Parrot 
> Sketch.
> https://wiki.samba.org/index.php/Nslcd
>
> (*) obligatory Python reference

Well, that corrects my statement in my last e-mail. nslcd always looked 
just like nscd to me.

Prentice
>
>
>
>
>
> On Sat, 27 Oct 2018 at 04:12, Skylar Thompson 
> <skylar.thompson at gmail.com <mailto:skylar.thompson at gmail.com>> wrote:
>
>     Good to know - we're still nslcd users so have yet to run into
>     that, though
>     are about to make the leap to CentOS 7 where I think we will have
>     to use
>     it.
>
>     On Sat, Oct 27, 2018 at 03:13:47AM +0100, John Hearns via Beowulf
>     wrote:
>     >    Skylar, I believe that nscd does not work well with sssd and
>     I disabled
>     >    it.
>     >    See
>     [1]https://access.redhat.com/documentation/en-us/red_hat_enterprise
>     >    _linux/6/html/deployment_guide/usingnscd-sssd
>     >    I believe that nscd is the work of Auld Nick himself and
>     causes more
>     >    problems than it is worth on HPC nodes.
>     >    If you want to speed up cacheing with sssd itself you can put
>     its local
>     >    caches on a RAMdisk. This has the cost of no persistence of
>     course and
>     >    uses up RAM which you may prefer to put to better use.
>     >
>     >    On Sat, 27 Oct 2018 at 00:59, Skylar Thompson
>     >    <[2]skylar.thompson at gmail.com
>     <mailto:skylar.thompson at gmail.com>> wrote:
>     >
>     >      On Fri, Oct 26, 2018 at 08:44:28PM +0000, Ryan Novosielski
>     wrote:
>     >      > Our LDAP is very small, compared to the sorts of things some
>     >      people run.
>     >      >
>     >      > We added indexes today on uid, uidNumber, and gidNumber
>     and the
>     >      problem went away. Didn’t try it earlier as it had virtually no
>     >      impact on our testing system for whatever reason, but on a
>     different
>     >      testing system and on production, it dropped “ls -al
>     /home/“ from
>     >      ~90s to ~5s. I’m not sure if all three were necessary, but
>     I’ll look
>     >      back at that later.
>     >      >
>     >      > We’ve run SSSD from day one, so that eliminates the nscld
>     >      question. We also moved CentOS 5.x to SSSD, FYI (I believe
>     there was
>     >      someone else with some old systems around). Was pretty
>     painless, and
>     >      SSSD eliminates a lot of problems that exist with the older
>     stuff
>     >      (including some really boneheaded very large LDAP queries
>     that were
>     >      happening routinely with the older nss-ldap software if I’m
>     >      remembering its name correctly).
>     >      Have you experimented with client-side caching services
>     like nscd?
>     >      nscd has
>     >      its quirks (in particular, it does very poorly with caching
>     spurious
>     >      negative
>     >      results from transient network failures), but it also is a big
>     >      performance
>     >      improvement since you don't even have to hit the network or the
>     >      directory
>     >      services.
>     >      --
>     >      Skylar
>     >      _______________________________________________
>     >      Beowulf mailing list, [3]Beowulf at beowulf.org
>     <mailto:Beowulf at beowulf.org> sponsored by Penguin
>     >      Computing
>     >      To change your subscription (digest mode or unsubscribe) visit
>     >      [4]http://www.beowulf.org/mailman/listinfo/beowulf
>     >
>     > References
>     >
>     >    1.
>     https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/usingnscd-sssd
>     >    2. mailto:skylar.thompson at gmail.com
>     <mailto:skylar.thompson at gmail.com>
>     >    3. mailto:Beowulf at beowulf.org <mailto:Beowulf at beowulf.org>
>     >    4. http://www.beowulf.org/mailman/listinfo/beowulf
>
>     > _______________________________________________
>     > Beowulf mailing list, Beowulf at beowulf.org
>     <mailto:Beowulf at beowulf.org> sponsored by Penguin Computing
>     > To change your subscription (digest mode or unsubscribe) visit
>     http://www.beowulf.org/mailman/listinfo/beowulf
>
>
>     -- 
>     Skylar
>     _______________________________________________
>     Beowulf mailing list, Beowulf at beowulf.org
>     <mailto:Beowulf at beowulf.org> sponsored by Penguin Computing
>     To change your subscription (digest mode or unsubscribe) visit
>     http://www.beowulf.org/mailman/listinfo/beowulf
>
>
>
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin Computing
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20181029/faf33c2b/attachment.html>


More information about the Beowulf mailing list