Looking for help moving an SMF forum board to Dreamhost

We have/had our SMF forum hosted elsewhere and decided to move to DreamHost. I am running into some snags and was hoping for a pointer to a guide with some details on the process, particularly PHP settings. But, since I haven’t run across one yet (any links appreciated), I’ll post here.

  • I set up the MySQL database and imported our db data. After a couple of timeout issues, I think everything is there.
  • I copied over the SMF forum folders and files from a backup I have into a subfolder of our new web page folder.
  • I modified Settings.php to point to the new MySQL database on Dreamhost, with the username and password I set when setting up the db.
  • Also in Settings.php, I changed the $boarddir, $sourcedir, and $cachedir variables to point to the new paths. Then, from the site management page,
  • From the Dreamhost site management page, I set our php version to 7.3 FastCGI (the SMF install guide says 7.4 is not supported). I left the rest with the defaults (extra web security checked, passenger unchecked).

BTW, the static HTML SMF readme page from the forum folder appears where I expect it and displays fine from a web browser. So, I think the folder and file permissions are okay.

But, when I browse to any of the SMF PHP pages, nothing shows up and I think all of those pages are timing out. I created a simple PHP page that calls phpinfo() and that loads fine. Most notably, SMF’s index.php does not load and SMF’s repair_settings.php does not load.

I cannot tell if I have a PHP setting incorrect. I added some of the lines mentioned in the SMF doc to myusername/.php/7.3/phprc, beneath the default Dreamhost lines. Most of the settings mentioned in the SMF doc were correct by default, a couple were deprecated like magic_quotes_sybase, so I did not add them.

It’s also possible there are MySQL settings needing adjustment. But, the forum pages should be returning some HTML, even if there is a problem with the database.

If you haven’t already, you should check for PHP errors in Apache’s error log (~/logs/example.com/https/error.log [corrected]). By default, DH has PHP setup in “production mode”, so errors are not displayed on-page (only in logs). You can change the settings if you need on-page errors.

[Side note: DH has quixotically turned PHP error logging on/off over the years, but at least on my shared-host it is currently on.]

Hmm. I am having trouble finding that file. My main web folder doesn’t have an http folder in it. But, there was a ~/logs/mysite.com/http file (the only file of any sort in the ~/logs/ tree). But, that file was blank.

Is there a flag I can set in myusername/.php/7.3/phprc to enable logging?

Oops, sorry about the typo. Should have said ~/logs/example.com/https/error.log. The full path would be:

/home/username/logs/example.com/https/error.log

To turn on error display In the phprc, add:

display_errors = on

Here’s DH article about PHP error display, which goes into a lot of details:

That folder isn’t there for me. I can get as far as /home/username/logs/mysite.com/ and there is one empty file in it, http, and no subfolders.

I have added that line to my /home/username/.php/7.3/phprc and reloaded the non-loading index.php. But, so far no log file.

Thanks for that link. I will read through it.

Ah, are you using DH’s Web-SFTP from the Panel? If so, then it is more difficult to get to the logs (I wish they’d fix it). Other SFTP clients work better.

If you are using DH’s Web-SFTP, then the only workaround I know is to:

  • In the menu, click on the “Log into another server” icon (looks like rack of servers)
  • Enter the full path to the logs (i.e. /home/username/logs/example.com/http)
  • Press Connect button

Very good call on using a different SFTP client. I was able to find the error.log file. I cannot say that I know what it means. But, it is pretty much filled (just today’s log file contains a little under 13,000 lines) with lines like the following

[Sun Nov 22 20:27:20.879264 2020] [:error] [pid 25806:tid 134610497660672] [client 13.66.139.158:50816] [client 13.66.139.158] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/dh/apache2/template/etc/mod_sec3_CRS/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf"] [line "103"] [id "943120"] [msg "Possible Session Fixation Attack: SessionID Parameter Name with No Referer"] [data "Matched Data: phpsessid found within REQUEST_HEADERS: 0"] [severity "CRITICAL"] [ver "OWASP_CRS/3.2.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-fixation"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "OWASP_CRS/WEB_ATTACK/SESSION_FIXATION"] [tag "WASCTC/WASC-37"] [tag "CAPEC-61"] [hostname "www.mysite.net"] [uri "/forums/index.php"] [unique_id "X7s6KMh4p@PuhfiH4Gl43gAAAFY"]

Is there evidence of a PHP configuration issue there? The log seems to indicate it thinks those are some sort of fixation attack on the site. But, I wonder how many are our forum users checking whether we are back online.

The ModSecurity errors are due to the “Extra Web Security” setting for the domain. Usually, the errors report blocked attacks and can be ignored, but maybe these are false-positives. I.e. maybe there is some incompatibility between SMF and some ModSecurity rules. The example error is from a Microsoft BingBot IP, which is unlikely to be a real attacker.

You could try turning off “Extra Web Security” to see if that allows SMF to run. If so, I suggest researching the issue to see if SMF can be more securely configured, so it can coexist wth ModSecurity.

On PHP errors, I’d suggest searching the error log for “PHP”. Also, its a good idea to test error display/logging with a scratch PHP file containing syntax and/or runtime warnings/errors (i.e. try calling foobar(), which should produce a PHP warning).

1 Like

If you think it’s PHP causing issues, add the following to your phprc

log_errors = on
error_log = /home/[user]/php_errors

NOTE:

As you’re using FastCGI you’ll need to kill all currently running php processes so changes are loaded on respawn. If you’re not familiar with shell this can be accomplished by setting a different PHP version in Panel, loading a PHP file for the site, then switching back to v7.3

Once you have everything fixed undo the changes to avoid logging unnecessarily.

1 Like

@habilus As best I can tell, all of the error lines mention PHP, as the [data "Matched Data: phpsessid found within REQUEST_HEADERS: 0"] part of the lines. But, I am not seeing any other PHP error references.
BTW, I noticed one other type of error line in the /home/_domain_logs/myuserid/mysite.net/http.42089133 file. Now there a handful that say

Blockquote
[Mon Nov 23 12:03:43.641364 2020] [:error] [pid 23661:tid 134610605831936] [client 13.66.139.68:9922] [client 13.66.139.68] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/dh/apache2/template/etc/mod_sec3_CRS/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf"] [line "103"] [id "943120"] [msg "Possible Session Fixation Attack: SessionID Parameter Name with No Referer"] [data "Matched Data: phpsessid found within REQUEST_HEADERS: 0"] [severity "CRITICAL"] [ver "OWASP_CRS/3.2.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-fixation"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "OWASP_CRS/WEB_ATTACK/SESSION_FIXATION"] [tag "WASCTC/WASC-37"] [tag "CAPEC-61"] [hostname "www.mysite.net"] [uri "/archive/index.php"] [unique_id "X7wVn@dH28OZiZrtN7acDwAAAJI"]

I don’t know what that means, either, though.

@xXi I think that I have set things up so that an error log is written. The lines from my 7.3 phprc are

; turn on some logging, at least until things are running
display_errors = on
log_errors = 1
error_log = /home/myuserid/php.log

But, I cannot find the /home/myuserid/php.log file. So, I must not have this set up correctly.

It might be that the original FastCGI is still running or something is “up” with your phprc file itself.

While troubleshooting:

  1. Remove all edits you’ve made to the original phprc

  2. Create a file in the /home/[user]/domain.tld directory named
    .user.ininote the preceding dot
    with the contents
    error_log=/home/[user]/php.log

  3. Switch the domain in Panel to regular CGI mode.

After troubleshooting delete .user.ini and switch back to FastCGI

1 Like

@sXi, I reverted my phprc to the original DH default. There was no folder domain.tld in my user folder. I created it. I created .user.ini in it. Then, in the Web Options panel for the account, I switched PHP mode to PHP 7.3 CGI and saved.

Then, I reloaded one of the PHP pages (the forum’s index,php) in a browser. But, I am not seeing php.log in my user folder, which I assume should be there, right?

Just to clarify, when @sXi says domain.tld or I say example.com, we don’t mean them literally, the names are stand-ins for the real name of the site, or in this case the name of the site’s web-directory. So the full path to the user-ini file would be /home/myusername/mysite.net/.user.ini (using @frstumpy’s stand-ins and assuming standard web-directory setup).

2 Likes

Oops. I mis-parsed that, thinking the string interpolation was designated by brackets, as the [user] variable was. I should have realized .tld meant ‘top-level domain’. Anyway, I have fixed that bit.

But, after swapping to PHP 7.2 and back to PHP 7.3, then reloading the non-responsive index.php page, I am still seeing no php.log in my user directory.

Any luck debugging your site? To test whether you’re getting errors on-page or in logs, I’d suggest modifying your phpinfo test page with an error/warning:

<?php

nosuchfunction();
phpinfo();

That should produce a undefined function error/warnings on-page or in-log, depending on how error handling is setup.

We were able to get the logging working. But, I am getting an error that I think is related to an older PHP call
PHP Fatal error: Uncaught Error: Call to undefined function mysql_connect()
I am not sure how exactly to deal with this. SMF says it works with PHP 7.3. But, my online searches are implying that mysql_connect() is a deprecated function.

[ Hi @frstumpy, only just seeing your messages – didn’t get an email alert when you posted 4 days ago ]

the mysql_connect() function was removed after PHP 5. Is it possible you are using an older version of SMF that requires PHP 5?

At the moment, DH still has PHP 5.6, but it is not accessible from the panel: https://help.dreamhost.com/hc/en-us/articles/215082337-What-versions-of-PHP-are-available-at-DreamHost-

I gather you can force PHP 5.6 in the site’s .htaccess file: https://help.dreamhost.com/hc/en-us/articles/214895317-How-do-I-change-the-PHP-version-of-my-site-

1 Like

Thank you! I added the proper .htaccess file to get PHP 5.6 running. Now, my forum shows up. Now I just need to apply all the updates. Hopefully, at the end of that process, I will have a version of SMF that will run on a newer version of PHP and I can remove .htaccess.