[slurm-users] Problem with permisions. CentOS 7.8

[Ferran Planas Padros]

Hello everyone,


Here it comes everything I've done.


- About Ole's answer:

Yes, we have slurm as the user to control munge. Following your comment, I have changed the ownership of the munge files and tried to start munge as munge user. However, it also failed.

Also, I first installed munge from a repository. I've seen your suggestion of installing from EPEL. So I uninstalled and installed again. Same result

- About SELinux: It is disables

- The output of ps -ef | grep munge is:


root      5340  5153  0 10:18 pts/0    00:00:00 grep --color=auto munge


- The outputs of munge -n is:


Failed to access "/var/run/munge/munge.socket.2": No such file or directory


- Same for unmunge


- Output for sudo systemctl status --full munge


● munge.service - MUNGE authentication service

   Loaded: loaded (/usr/lib/systemd/system/munge.service; enabled; vendor preset: disabled)

   Active: failed (Result: exit-code) since Fri 2020-05-29 10:15:52 CEST; 4min 18s ago

     Docs: man:munged(8)

  Process: 5333 ExecStart=/usr/sbin/munged (code=exited, status=1/FAILURE)


May 29 10:15:52 roos21.organ.su.se systemd[1]: Starting MUNGE authentication service...

May 29 10:15:52 roos21.organ.su.se systemd[1]: munge.service: control process exited, code=exited status=1

May 29 10:15:52 roos21.organ.su.se systemd[1]: Failed to start MUNGE authentication service.

May 29 10:15:52 roos21.organ.su.se systemd[1]: Unit munge.service entered failed state.

May 29 10:15:52 roos21.organ.su.se systemd[1]: munge.service failed.


- Regarding NTP, I get this message:


Unable to talk to NTP daemon. Is it running?


It is the same message I get in the nodes that DO work. All nodes are sync in time and date with the central node


________________________________
From: slurm-users <slurm-users-bounces at lists.schedmd.com> on behalf of Ole Holm Nielsen <Ole.H.Nielsen at fysik.dtu.dk>
Sent: Friday, May 29, 2020 9:56:10 AM
To: slurm-users at lists.schedmd.com
Subject: Re: [slurm-users] Problem with permisions. CentOS 7.8

On 29-05-2020 08:46, Sudeep Narayan Banerjee wrote:
> also check:
> a) whether NTP has been setup and communicating with master node
> b) iptables may be flushed (iptables -L)
> c) SeLinux to disabled, to check :
> getenforce
> vim /etc/sysconfig/selinux
> (change SELINUX=enforcing to SELINUX=disabled and save the file and reboot)

There is no reason to disable SELinux for running the Munge service.
It's a pretty bad idea to lower the security just for the sake of
convenience!

/Ole


> On Fri, May 29, 2020 at 12:08 PM Sudeep Narayan Banerjee
> <snbanerjee at iitgn.ac.in <mailto:snbanerjee at iitgn.ac.in>> wrote:
>
>     I have not checked on the CentOS7.8
>     a) if /var/run/munge folder does not exist then please double check
>     whether munge has been installed or not
>     b) user root or sudo user to do
>     ps -ef | grep munge
>     kill -9 <PID> //where PID is the Process ID for munge (if the
>     process is running at all); else
>
>     which munged
>     /etc/init.d/munge start
>
>     please let me know the the output of:
>
>     |$ munge -n|
>
>     |$ munge -n | unmunge|
>
>     |$ sudo systemctl status --full munge
>
>     |
>
>     Thanks & Regards,
>     Sudeep Narayan Banerjee
>     System Analyst | Scientist B
>     Indian Institute of Technology Gandhinagar
>     Gujarat, INDIA
>
>
>     On Fri, May 29, 2020 at 11:55 AM Bjørn-Helge Mevik
>     <b.h.mevik at usit.uio.no <mailto:b.h.mevik at usit.uio.no>> wrote:
>
>         Ferran Planas Padros <ferran.padros at su.se
>         <mailto:ferran.padros at su.se>> writes:
>
>          > I run the command as slurm user, and the /var/log/munge
>         folder does belong to slurm.
>
>         For security reasons, I strongly advise that you run munged as a
>         separate user, which is unprivileged and not used for anything else.
>
>         --
>         Regards,
>         Bjørn-Helge Mevik, dr. scient,
>         Department for Research Computing, University of Oslo
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schedmd.com/pipermail/slurm-users/attachments/20200529/c68e098b/attachment-0001.htm>