<div dir="ltr"><div>Robert,</div><div>I will back up what Lachlan said.</div><div>I set up a new HPC facility for the University of Greenwich in the UK, which uses sssd to authenticate against a campus AD.</div><div>One thing to remember - campus wide you have everyone in the AD. SO do the following:</div><div><br></div><div>a) create a new group called 'HPC-users'and restrict the logins to HPC-users only (and maybe HPC-admins also!)</div><div><br></div><div>b) you can automate the creation of home directories using a PAM plugin on Redhat </div><div>See <a href="https://access.redhat.com/discussions/903523">https://access.redhat.com/discussions/903523</a></div><div>I recommend against the oddjob version of pam_mkhomedir - ti did nto behave too well, and the 'normal' version worked just fine.</div><div><br></div><div>Also you might want an /etc/profile.d script which wil create areas on your scratch/parallel storage for users when they first log in</div><div><br></div><div>Where I work as the moment we use nslcd rather than sssd. I Was told there was an issue with sssd, but I forget what it was exactly.</div><div><br></div><div>One tip with sssd, I found that when initially working with it I had to do a wipe of the cache and a forced reload.</div><div>The documentation is there on how to do that. Do not be afraid to do this - the procedure sounds scary but works perfectly well.</div><div>sssd caches things quite aggressively so you might have to restart it to get the 'ground truth' sometimes.</div><div><br></div><div>sssd also has a very odd behaviour when you have a very large number of groups (probably as MIT has)</div><div>It creates a huge sparse file for groups (or something similar). The file looks scarily big - but being sparse of course it is not really.</div><div>Just a quirk of how it works I gather, sont let my comment put you off.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 28 December 2017 at 08:40, Nick Evans <span dir="ltr"><<a href="mailto:nick.c.evans@gmail.com" target="_blank">nick.c.evans@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Robert,<div><br></div><div>We are currently running our HPC, servers and desktops with storage needs serviced by an Isilon. We have CIFS and NFS capabilities both of which use the AD for authentication.</div><div><br></div><div>Currently our cluster is Centos 6.8 NFS and SSH authenticating off of the AD using SSSD. We also have a number of Centos 7.4 machines that are mapping NFS with AD auth from SSSD.</div><div><br></div><div>The only thing to watch is the Isilon has the Lookup UID setting by default set to off so you can quite quickly run into the NFS 16 group limit but other than that ours has be rock solid.</div><div><br></div><div>Nick</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 28 December 2017 at 11:54, Lachlan Musicman <span dir="ltr"><<a href="mailto:datakid@gmail.com" target="_blank">datakid@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On 28 December 2017 at 13:41, Robert Taylor <span dir="ltr"><<a href="mailto:rgt@wi.mit.edu" target="_blank">rgt@wi.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi cluster gurus. I want to pick the your collective brains.<div>Right now, where I work, we have and isilon, and netapp, which we use for our small 250core compute cluster.</div><div><br></div><div>We have NIS for authentication and automount maps on the cluster side, and AD for authentication on the windows side, and LDAP for yet for other things to authenticate against. </div><div>The storage is connected to both nis and AD, and does it's best to match the two sides up. </div><div>We have had some odd issues with authentication as of late with sources getting out of sync, which has brought up the discussion for consolidating down to a single source of truth, which would be AD. RFC2307 talks about stuffing NIS data into LDAP/AD, and there are commercial products such as centrify that can do it. </div><div><br></div><div>Does anyone run an entirely AD authentication environment with their compute cluster</div><div>authenticating against it and using it for automount maps and such?</div><div>Can you tell me what were your reasons for going that way, and any snags that you hit on the way?</div></div></blockquote><div><br><br></div></span><div>Robert,<br><br></div><div>We were asked/tasked with this a couple of years ago.<br><br></div><div>It took almost two years of shaking out the issues, but FreeIPA/SSSD in a one-way trust with AD has worked excellently for 18 months. Our SLURM cluster is on CentOS 7.4, and we needed to use the COPR version of SSSD (1.16.x) rather than the version in the repos (1.15.x) but otherwise is fine. Would absolutely recommend.<br><br></div><div>Note that a lot of the issues we saw were directly related to our AD, rather than any problems with FreeIPA and SSSD. For example for a long time our AD login names had spaces in them (! would not recommend), and the age and size of the AD instance also lead to a few issues. Nothing that couldn't be worked around. The devs and community are excellent at responding to requests for help. It's a RedHat product. so if you have a subscription it would be even easier.<br></div><div><br><br></div><div>Cheers<br></div><div>L.<br></div><div><br>------<br>"The antidote to apocalypticism is
<b>apocalyptic civics</b>. Apocalyptic civics is the
insistence that we cannot ignore the truth, nor should we panic about
it. It is a shared consciousness that our institutions have failed and
our ecosystem is collapsing, yet we are still here — and we are creative
agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "<br><br><i>Greg Bloom</i> @greggish <a href="https://twitter.com/greggish/status/873177525903609857" target="_blank">https://twitter.com/greggish/s<wbr>tatus/873177525903609857</a> <br></div></div><br></div></div>
<br></div></div>______________________________<wbr>_________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">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" target="_blank" rel="noreferrer">http://www.beowulf.org/mailman<wbr>/listinfo/beowulf</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">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" target="_blank" rel="noreferrer">http://www.beowulf.org/<wbr>mailman/listinfo/beowulf</a><br>
<br></blockquote></div><br></div>