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).

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.

@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.