<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <pre class="moz-signature" cols="72">
</pre>
    <div class="moz-cite-prefix">On 10/27/2018 03:08 AM, John Hearns via
      Beowulf wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPqNE2WjiRCMxdVG0FD-EasqfYcW8ibDgw5+Srp+=PQMyuphyg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      <div dir="ltr">
        <div dir="ltr">
          <div>To be clear I am talking about the Name Service Cacheing
            Daemon</div>
          <div>I have always found this to be more trouble than it is
            worth  - it holds on to out of date information,</div>
          <div>and needs to be restarted when you are debugging things
            like batch systems etc.</div>
        </div>
      </div>
    </blockquote>
    <br>
    My favorite feature of nscd was the paranoid option: <br>
    <br>
    <blockquote type="cite">
      <p>
        <b>paranoia</b>
        <i><yes|no></i>
      </p>
      <dl compact="compact">
        <dt><br>
        </dt>
        <dd>
          Enabling paranoia mode causes nscd to restart itself
          periodically.
          The default is no.
        </dd>
      </dl>
    </blockquote>
    <br>
    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. <br>
    <blockquote type="cite"
cite="mid:CAPqNE2WjiRCMxdVG0FD-EasqfYcW8ibDgw5+Srp+=PQMyuphyg@mail.gmail.com">
      <div dir="ltr">
        <div dir="ltr">
          <div><br>
          </div>
          <div>nslcd is something completely different (*)   and whoever
            chose similar names should be forced to watch endless
            re-runs of the Parrot Sketch.</div>
          <div><a href="https://wiki.samba.org/index.php/Nslcd"
              moz-do-not-send="true">https://wiki.samba.org/index.php/Nslcd</a></div>
          <div><br>
          </div>
          <div>(*) obligatory Python reference</div>
        </div>
      </div>
    </blockquote>
    <br>
    Well, that corrects my statement in my last e-mail. nslcd always
    looked just like nscd to me. <br>
    <br>
    Prentice<br>
    <blockquote type="cite"
cite="mid:CAPqNE2WjiRCMxdVG0FD-EasqfYcW8ibDgw5+Srp+=PQMyuphyg@mail.gmail.com">
      <div dir="ltr">
        <div dir="ltr">
          <div><br>
          </div>
          <div><br>
          </div>
          <div><br>
          </div>
          <div><br>
          </div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr">On Sat, 27 Oct 2018 at 04:12, Skylar Thompson
          <<a href="mailto:skylar.thompson@gmail.com"
            moz-do-not-send="true">skylar.thompson@gmail.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">Good to know
          - we're still nslcd users so have yet to run into that, though<br>
          are about to make the leap to CentOS 7 where I think we will
          have to use<br>
          it.<br>
          <br>
          On Sat, Oct 27, 2018 at 03:13:47AM +0100, John Hearns via
          Beowulf wrote:<br>
          >    Skylar, I believe that nscd does not work well with
          sssd and I disabled<br>
          >    it.<br>
          >    See [1]<a
            href="https://access.redhat.com/documentation/en-us/red_hat_enterprise"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://access.redhat.com/documentation/en-us/red_hat_enterprise</a><br>
          >    _linux/6/html/deployment_guide/usingnscd-sssd<br>
          >    I believe that nscd is the work of Auld Nick himself
          and causes more<br>
          >    problems than it is worth on HPC nodes.<br>
          >    If you want to speed up cacheing with sssd itself you
          can put its local<br>
          >    caches on a RAMdisk. This has the cost of no
          persistence of course and<br>
          >    uses up RAM which you may prefer to put to better use.<br>
          > <br>
          >    On Sat, 27 Oct 2018 at 00:59, Skylar Thompson<br>
          >    <[2]<a href="mailto:skylar.thompson@gmail.com"
            target="_blank" moz-do-not-send="true">skylar.thompson@gmail.com</a>>
          wrote:<br>
          > <br>
          >      On Fri, Oct 26, 2018 at 08:44:28PM +0000, Ryan
          Novosielski wrote:<br>
          >      > Our LDAP is very small, compared to the sorts
          of things some<br>
          >      people run.<br>
          >      ><br>
          >      > We added indexes today on uid, uidNumber, and
          gidNumber and the<br>
          >      problem went away. Didn’t try it earlier as it had
          virtually no<br>
          >      impact on our testing system for whatever reason,
          but on a different<br>
          >      testing system and on production, it dropped “ls -al
          /home/“ from<br>
          >      ~90s to ~5s. I’m not sure if all three were
          necessary, but I’ll look<br>
          >      back at that later.<br>
          >      ><br>
          >      > We’ve run SSSD from day one, so that eliminates
          the nscld<br>
          >      question. We also moved CentOS 5.x to SSSD, FYI (I
          believe there was<br>
          >      someone else with some old systems around). Was
          pretty painless, and<br>
          >      SSSD eliminates a lot of problems that exist with
          the older stuff<br>
          >      (including some really boneheaded very large LDAP
          queries that were<br>
          >      happening routinely with the older nss-ldap software
          if I’m<br>
          >      remembering its name correctly).<br>
          >      Have you experimented with client-side caching
          services like nscd?<br>
          >      nscd has<br>
          >      its quirks (in particular, it does very poorly with
          caching spurious<br>
          >      negative<br>
          >      results from transient network failures), but it
          also is a big<br>
          >      performance<br>
          >      improvement since you don't even have to hit the
          network or the<br>
          >      directory<br>
          >      services.<br>
          >      --<br>
          >      Skylar<br>
          >      _______________________________________________<br>
          >      Beowulf mailing list, [3]<a
            href="mailto:Beowulf@beowulf.org" target="_blank"
            moz-do-not-send="true">Beowulf@beowulf.org</a> sponsored by
          Penguin<br>
          >      Computing<br>
          >      To change your subscription (digest mode or
          unsubscribe) visit<br>
          >      [4]<a
            href="http://www.beowulf.org/mailman/listinfo/beowulf"
            rel="noreferrer" target="_blank" moz-do-not-send="true">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
          > <br>
          > References<br>
          > <br>
          >    1. <a
href="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/usingnscd-sssd"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/usingnscd-sssd</a><br>
          >    2. mailto:<a href="mailto:skylar.thompson@gmail.com"
            target="_blank" moz-do-not-send="true">skylar.thompson@gmail.com</a><br>
          >    3. mailto:<a href="mailto:Beowulf@beowulf.org"
            target="_blank" moz-do-not-send="true">Beowulf@beowulf.org</a><br>
          >    4. <a
            href="http://www.beowulf.org/mailman/listinfo/beowulf"
            rel="noreferrer" target="_blank" moz-do-not-send="true">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
          <br>
          > _______________________________________________<br>
          > Beowulf mailing list, <a
            href="mailto:Beowulf@beowulf.org" target="_blank"
            moz-do-not-send="true">Beowulf@beowulf.org</a> sponsored by
          Penguin Computing<br>
          > To change your subscription (digest mode or unsubscribe)
          visit <a
            href="http://www.beowulf.org/mailman/listinfo/beowulf"
            rel="noreferrer" target="_blank" moz-do-not-send="true">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
          <br>
          <br>
          -- <br>
          Skylar<br>
          _______________________________________________<br>
          Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org"
            target="_blank" moz-do-not-send="true">Beowulf@beowulf.org</a>
          sponsored by Penguin Computing<br>
          To change your subscription (digest mode or unsubscribe) visit
          <a href="http://www.beowulf.org/mailman/listinfo/beowulf"
            rel="noreferrer" target="_blank" moz-do-not-send="true">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
        </blockquote>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Beowulf mailing list, <a class="moz-txt-link-abbreviated" href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a> sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit <a class="moz-txt-link-freetext" href="http://www.beowulf.org/mailman/listinfo/beowulf">http://www.beowulf.org/mailman/listinfo/beowulf</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>