New systemd FYI & Question

Post Reply
mosera
Posts: 11
Joined: Tue Aug 03, 2021 11:12 pm
Full Name: Adam Moser
Organization: Loras College

New systemd FYI & Question

Post by mosera »

I'm using WebMO version 20.0.012p with Gaussian16. I've been running Fedora as my OS for about 12 years. Because of cybersecurity issues and insurance, I have to keep the OS updated pretty much non-stop now, which hasn't been an issue for many upgrades until Fedora 40.

After the upgrade, couldn't get to the login screen because parse.cgi was failing when it tried to open for writing the errors file in its home directory. Tried many things, including a full removal and re-install of WebMO. After a while of digging (https://serverfault.com/questions/11602 ... checked-se), I found they updated systemd such that cgi couldn't write to files . This can be fixed by changing 'ProtectHome=no' in the httpd settings. Not sure how many linux OSs will take up this change, but thought it was worth a report so others don't spend the time I did fishing out the problem.

This got me to log in as admin and make users. Users can log into WebMO, make jobs, and submit jobs, but jobs fail without any raw output written. As a test I logged into the webmo user on the server directly, and can run Gaussian16 jobs no problems. Any thoughts on why I can run a Gaussian16 job from the command line but can't through the WebMO interface? Things I should try to diagnose?
schmidt
Posts: 93
Joined: Sat May 30, 2020 3:00 pm
Full Name: JR Schmidt
Organization: WebMO, LLC

Re: New systemd FYI & Question

Post by schmidt »

Thank you for brining this to our attention. It looks like this may be the default for Fedora 40+. I'll look into this some more so we can update the instructions accordingly.
mosera
Posts: 11
Joined: Tue Aug 03, 2021 11:12 pm
Full Name: Adam Moser
Organization: Loras College

Re: New systemd FYI & Question

Post by mosera »

Still can't get jobs to run after trying a handful amateur attempts. The 'errors' file in the main directory is being written out ok now and is empty. The output.log file is empty though for every job I try. run_gaussian.cgi is making all the files in the webmo folder (charges, connections, input.com, run_log, etc) and just as a dummy check I had it write out its username in the run_log file to make sure it is running as the webmo user ...

USER: webmo
Executing script: /home/webmo/public_html/cgi-bin/webmo/run_gaussian.cgi
Creating working directory: /scratch/webmo-16043/11
Script execution node: [redacted, but correct server name]
Job execution node(s): [same as above]
Executing command: /usr/local/g16/g16

I don't see anything in /scratch/, but since nothing ran that makes sense. I did go into that /scratch directory as webmo user and make files and directories with no problem, so I don't think its a user permission issue there. Maybe a cgi permission issue?

If I command line on the server to run g16 < input.com > output.log as the webmo user it works just fine though and I see files appear then get removed from /scratch/. I'm stumped.
mosera
Posts: 11
Joined: Tue Aug 03, 2021 11:12 pm
Full Name: Adam Moser
Organization: Loras College

Re: New systemd FYI & Question

Post by mosera »

Classes are approaching and I'm still stuck. Was checking all the /var/log files to find cgi errors. I saw this in audit.log ...
type=AVC msg=audit(1723489784.820:255122): avc: denied { read write } for pid=833135 comm="jobmgr.cgi" name="groups.db" dev="sda2" ino=905750 scontext=system_u:system_r:httpd_user_script_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1

type=AVC msg=audit(1723489784.820:255123): avc: denied { lock } for pid=833135 comm="jobmgr.cgi" path="/home/webmo/webmo/.groups.index" dev="sda2" ino=905751 scontext=system_u:system_r:httpd_user_script_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
That doesn't seem like an issue given all the html stuff is fine, but made me think selinux might be blocking something else. I 'Disabled' it (normally on permissive), but doesn't change empty output files. So selinux is likely not the culprit.

Any suggestions of what to try next?
Post Reply