Page 1 of 1

Messenger v3 getting 500 internal server error, caused by no user or group set?

Posted: 02 Mar 2022, 06:28
by emerysteele
Trying to configure the messenger service so user's on my server can get an indication if their IP is being blocked.

Got so far as getting a response from apache when I browse to http://serveraddress.com from a blocked IP address (https is not responding unless I use port 8887, but I believe that is another matter.)

The response I'm getting is error 500, internal server error. I've managed to check the apache error logs, and the error it gives me is:

Code: Select all

[Tue Mar 01 22:55:42.055637 2022] [:error] [pid xxxxx:tid 139656967366400] [client xxx.xxx.xxx.xxx:xxxxx] No user or group set - set suPHP_UserGroup
[Tue Mar 01 22:55:42.554123 2022] [:error] [pid xxxxx:tid 139656950580992] [client xxx.xxx.xxx.xxx:xxxxx] No user or group set - set suPHP_UserGroup, referer: http://serveraddress.com/
I'm not sure where to go from here. I've verified the MESSENGER_USER is "csf". And set permissions for '/home/csf' to csf:csf 0711, and '/home/csf/public_html' to csf:nobody 0711

Re: Messenger v3 getting 500 internal server error, caused by no user or group set?

Posted: 03 Mar 2022, 01:55
by emerysteele
Managed to get it working! :) Figured I'd post what I did in case anyone else runs into the same issue.

So not sure if it's a bug with the version of apache or suphp version I have or what. Just running what CentOSWebPanel/ControlWebPanel builds on the default Apache 2.4 install.

But I found on another forum to put the 'suPHP_UserGroup user user' nested under <directory> in the web config file.

So I changed this:

Code: Select all

	<Directory "[DIRECTORY]">
		AllowOverride All
	</Directory>
to this:

Code: Select all

	<Directory "[DIRECTORY]">
		AllowOverride All
		suPHP_UserGroup [USER] [USER]
	</Directory>
in both the `apache.http.txt` + `apache.https.txt` in the csf template files (/usr/local/csf/tpl)

Restarted csf + lfd.

Still got the 500 internal server error afterwards, but the error logs showed something different this time. Something about a GID mismatch. Ended up having to use csf:csf for the perms in /home/csf/public_html as well, instead of csf:nobody.

Now it is working as expected.