I was made aware that the previous OS on our production server had reach EOL in June '24. I am migrating all virtual servers over to the new server. All appeared to work as designed and seemed to function well.
Went on to test and this is where the issues began. Started with 500 errors. Clean them, all up. I then went on to find that sessions were not being created (written to Dir) due to permission issues. I seemed to get them to work by setting the owner:group as apache:apache - which i had not done on the previous server.
Now I’ve gone on to further test further and now I’m seeing Perl isn’t able to read and or write to files on the server say /home/user/public_html/some_dir/some_file.txt. Im figuring this is a permissions issue to winch im not 100% sure im understanding how it works (as now the public_html folder and on are under user:user)
Im not sure how to proceed. Ive tried to search several different places including trying to use AI to help diag.
Can you provide us relevant excerpts from the error logs regarding the 500 errors. You should not have to set ownership to “apache:apache” for websites if things are setup correctly.
This is one error im currently getting with a php script. Ive had this error with our perl code but typically there is not 500 error, it just simply doesnt die with any errors the script continues. On this PHP script it’s trying to take an HTML file open it up and create a PDF file of it. I used domPDF on our production server thats been running for roughly 10 years. It was throwing errors on the new server so i removed the old domPDF and started with a fresh new updated version. Still same error.
[Wed Jan 29 12:46:53.826890 2025] [fcgid:warn] [pid 2033811:tid 2033837] [remote 173.170.160.226:59283] mod_fcgid: stderr: thrown in /home/mga/public_html/modules/inv/dompdfNEW/invoice_print.php on line 6 [Wed Jan 29 12:46:53.826887 2025] [fcgid:warn] [pid 2033811:tid 2033837] [remote 173.170.160.226:59283] mod_fcgid: stderr: #0 {main} [Wed Jan 29 12:46:53.826884 2025] [fcgid:warn] [pid 2033811:tid 2033837] [remote 173.170.160.226:59283] mod_fcgid: stderr: Stack trace: [Wed Jan 29 12:46:53.826879 2025] [fcgid:warn] [pid 2033811:tid 2033837] [remote 173.170.160.226:59283] mod_fcgid: stderr: PHP Fatal error: Uncaught Error: Failed opening required '/home/mga/public_html/modules/dompdfNEW/autoload.inc.php' (include_path='.:/usr/share/pear:/usr/share/php') in /home/mga/public_html/modules/inv/dompdfNEW/invoice_print.php:6 [Wed Jan 29 12:46:53.826836 2025] [fcgid:warn] [pid 2033811:tid 2033837] [remote 173.170.160.226:59283] mod_fcgid: stderr: PHP Warning: require_once(/home/mga/public_html/modules/dompdfNEW/autoload.inc.php): Failed to open stream: No such file or directory in /home/mga/public_html/modules/inv/dompdfNEW/invoice_print.php on line 6
I’m seeing an error of “no such file or directory”. Are you sure the required file exists? Because they’ll produce a 500 error since it’s “required” by your script.
That means Perl isn’t being run as the domain owner user. Are these CGI files or do you have an application server?
If CGI, you can no longer use suexec on RPM-based distros, because EL distros do not provide a suexec-custom package. I thought fcgiwrap was used in this case, though, to provide an FCGI wrapped interface to CGI scripts running as the domain owner user. So, I guess there’s something fidgety about a migrated site that was using suexec.
So, clarify how you’re running your Perl application(s) and we can go from there. Though I don’t actually know how fcgiwrap gets configured/setup in cases like this, as I can’t seem to find UI for it. I know it’s in there, somehow.
@Jamie how does a user enable fcgiwrap for CGI scripts if they’re bringing the application over from an older system that was using suexec? Should that be automatic or is there something they need to poke at? (When I search I see that there’s a help file about running CGI scripts with fcgiwrap, but it doesn’t link anywhere, and I can’t find it poking around in the UI.)
You absolutely should not solve this by making everything owned by Apache.