<div dir="ltr"><div>Yar, not AT ALL to pick holes in what you have done, please please.</div><div>The way to configure PAM modules these days should be    pam-auth-config <a href="http://manpages.ubuntu.com/manpages/artful/man8/pam-auth-update.8.html">http://manpages.ubuntu.com/manpages/artful/man8/pam-auth-update.8.html</a></div><div><br></div><div>The directory /usr/share/pam-configs contains files supplied by a package when it is installed.</div><div>The you run pam-auth-config to configure /etc/pam.d/ files</div><div><br></div><div>Seems to me like we should work on a pam-auth-config file for Slurm.  If one exists alsready then I hang my head further in shame.<br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 June 2018 at 16:53, Yair Yarom <span dir="ltr"><<a href="mailto:irush@cs.huji.ac.il" target="_blank">irush@cs.huji.ac.il</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
We encountered this issue some time ago (see:<br>
<a href="https://www.mail-archive.com/slurm-dev@schedmd.com/msg06628.html" rel="noreferrer" target="_blank">https://www.mail-archive.com/<wbr>slurm-dev@schedmd.com/<wbr>msg06628.html</a>). You<br>
need to add pam_systemd to the slurm pam file, but pam_systemd will<br>
try to take over the slurm's cgroups. Our current solution is to add<br>
pam_systemd to the slurm pam file, but in addition to save/restore the<br>
slurm cgroup locations. It's not pretty, but for now it works...<br>
<br>
If you don't constrain the devices (i.e. don't have GPUs), you<br>
probably can do without the pam_exec script and use the pam_systemd<br>
normally.<br>
<br>
We're using debian, but the basics should be the same. I've placed the<br>
script in github, if you want to try it:<br>
<a href="https://github.com/irush-cs/slurm-scripts" rel="noreferrer" target="_blank">https://github.com/irush-cs/<wbr>slurm-scripts</a><br>
<span class="HOEnZb"><font color="#888888"><br>
    Yair.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Mon, Jun 18, 2018 at 3:33 PM, John Hearns <<a href="mailto:hearnsj@googlemail.com">hearnsj@googlemail.com</a>> wrote:<br>
> Your problem is that you are listening to Lennart Poettering...<br>
> I cannot answer your question directly. However I am doing work at the<br>
> moment with PAM and sssd.<br>
> Have a look at the directory which contains the unit files. Go on<br>
> /lib/systemd/sysem<br>
> See that nice file named -.slice    Yes that file is absolutely needed, it<br>
> is not line noise.<br>
> Now try to grep on the files in that directory, since you might want to<br>
> create a new systemd unit file based on an existing one.<br>
><br>
> Yes, a regexp guru will point out that this is trivial. But to me creating<br>
> files that look like -.slice is putting your head in the lion's mouth.<br>
><br>
><br>
><br>
><br>
><br>
> On 18 June 2018 at 14:15, Maik Schmidt <<a href="mailto:maik.schmidt@tu-dresden.de">maik.schmidt@tu-dresden.de</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> we're currently in the process of migrating from RHEL6 to 7, which also<br>
>> brings us the benefit of having systemd. However, we are observing problems<br>
>> with user applications that use e.g. XDG_RUNTIME_DIR, because SLURM<br>
>> apparently does not really run the user application through the PAM stack.<br>
>> The consequence is that SLURM jobs inherit the XDG_* environment variables<br>
>> from the login nodes (where sshd properly sets it up), but on the compute<br>
>> nodes, /run/user/$uid does not exist, leading to errors whenever a user<br>
>> application tries to access it.<br>
>><br>
>> We have tried setting UsePam=1, but that did not help.<br>
>><br>
>> I have found the following issue on the systemd project regarding exactly<br>
>> this problem: <a href="https://github.com/systemd/systemd/issues/3355" rel="noreferrer" target="_blank">https://github.com/systemd/<wbr>systemd/issues/3355</a><br>
>><br>
>> There, Lennart Poettering argues that it should be the responsibility of<br>
>> the scheduler software (i.e. SLURM) to run user code only within a proper<br>
>> PAM session.<br>
>><br>
>> My question: does SLURM support this? If yes, how?<br>
>><br>
>> If not, what are best practices to circumvent this problem on<br>
>> RHEL7/systemd installations? Surely other clusters must have already had the<br>
>> same issue...<br>
>><br>
>> Thanks in advance.<br>
>><br>
>> --<br>
>> Maik Schmidt<br>
>> HPC Services<br>
>><br>
>> Technische Universität Dresden<br>
>> Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH)<br>
>> Willers-Bau A116<br>
>> D-01062 Dresden<br>
>> Telefon: +49 351 463-32836<br>
>><br>
>><br>
><br>
<br>
</div></div></blockquote></div><br></div>