cgi permissions/ suexec

[Qtheomnipotent]

I don't really know if this is a script problem, so much as a permissions problem, or what the heck it is, but here it is.

My server, a rented server hosted by a major hosting company, is running Fedora Core 1. The host installed Plesk as my server administration program, and I've installed Webmin to take care of most everything else. On my primary website, which I'll refer to as site1, I run a forum, powered by Discus Pro, version 4.00.7. Now, my directory structure is /home/httpd/vhosts/sitename/ and my httpdocs and cgi-bin directories are both on that level, rather than having cgi-bin inside httpdocs. In order for my forum to operate correctly, in /home/httpd/vhosts/sitename/conf/httpd.include, I've had to '#' out the suEXEC line in order for my cgi scripts to be publicly executable. In that same file, my document root is set to httpdocs, in each site's httpd.include file. I'm not exactly sure why, but it seems that Plesk sets permissions and file ownership in an odd way, and invokes suEXEC, rendering my scripts unusable by forum users. I don't fully understand it myself, but this is what I believe is happening, based on what I've seen, and what someone else has told me.

Ok, that's the background. Here's the problem. I have 2 other sites on that server, and both of their httpd.include files have been set up the same way. I want to install a Discus forum on one of those sites, to use as a test bed for my modifications. Discus provides a diagnostic tool, ftpdiag.cgi, and what it does is detect your directory structure, in order to provide you with a download tailored to your needs, and tell you which directories to create, and where, and what to set permissions to. Basically, you download the ftpdiag.cgi script from Discus, upload it to your cgi-bin, and run it in a browser window, and it tells you your information. So, I uploaded the script to site2/cgi-bin, and tried to run it. I immediately got a 500 Internal Server error. So, I went to /var/log/httpd/suexec.log, and in there it said 'command not in docroot (/home/httpd/vhosts/site2/cgi-bin/ftpdiag.cgi)'. If I upload the script to httpdocs instead, which is docroot, I can read it, but it's in plain HTML format, which it is not supposed to be, and shows an error saying that the folder it is in must not have cgi permission, which is true. The folder httpdocs does not have, or need cgi permission. But at least it shows that the script is fine, and the problem is in my server.

In /var/log/httpd/error_log, I'm getting several errors that I don't know how to correct. RSA server certificate CommonName (CN) 'plesk' does NOT match server name!? Also, several child processes are not exiting: 30434;30435;30436;30437;30438;30439;30440;30441. These errors have been around for quite some time, and they don't seem to be affecting my main site, but I don't know if they're affecting my ability to install the forum on another site.

Long read, I know, but can anyone help with this?

[bwkaz]

I don't know about the rest of it, but:

Originally posted by Qtheomnipotent
RSA server certificate CommonName (CN) 'plesk' does NOT match server name!? This is related to your SSL certificate. The CommonName on the certificate has to match the DNS name that users get to the server with, otherwise the users' browsers will warn them. This is used to help prevent some kind of attack on SSL, but I'm not sure what attack or how it helps prevent it.

Also, several child processes are not exiting: 30434;30435;30436;30437;30438;30439;30440;30441. I think that's normal. My Apache server has at least five or six httpd processes running at all times. The reason is that it uses the "prefork" MPM, which means it creates a pool of processes to handle requests. One process handles each request, and if none are available, a new process is started, up until the process limit is hit.

In other words, I think these processes that aren't exiting are only there to handle future requests from other users.

[Qtheomnipotent]

Thanks. I kinda figured that the processes not exiting was kinda normal, since it hasn't caused a problem, that I'm aware of.

As for the SSL certificate, where do I go and what do I do to fix it? I've ordered a fedora dummies manual, but it won't be in for about a week or so. I've been a Linux user for a couple of years now, but mostly with the GUIs. I'm still not too well versed in command line. I have Xandros 2.0, and Slackware 10 installed on my home system, and I've just installed Core 1, so that I can get more used to using it, but as yet, I'm not that great with commands or programming.

BTW, I like your sig line. I always wondered what they were saying at the beginning of the meeting, but had never bothered to look it up. Hehe.

[bwkaz]

For SSL, don't bother unless you plan on using an https:// URL.

If you do, you may want to get a certificate from a real certificate authority anyway, otherwise your users will still see warnings when they try to connect to your site via https:// URLs. In that case, you'll want to make sure to have your ServerName in httpd.conf set to whatever your users will be connecting to, and you'll also want to make sure you put that server name in your certificate request.

After you get a real certificate and reconfigure Apache to look at the signed certificate file (and corresponding key), that warning will go away.

[Qtheomnipotent]

That's what I thought. I had been researching that error before, and from what I understood, I only needed it for an https url, which I have no desire to use.

So, basically, neither of these errors is anything to worry about?

Hopefully, someone else will read this, and might have some idea about the rest of it.

[Qtheomnipotent]

Just bumping this. Hopefully someone who might have an answer will see it.

[bwkaz]

Hang on a minute -- what is your DocumentRoot set to? Would it work to put /cgi-bin/ somewhere under that?