Topic: Server Manager - Internal server error

[jc021179]

Hi guys,

I have just done a clean install of sme 5.6. Everything went on fine server manager was working fine but now a few days later i get "internal server error" messages from every manager module.

I have had a look at the admin_error_log file and it reads the following.

[Thu Apr  1 01:12:17 2004] [notice] Apache configured -- resuming normal operations
[Thu Apr  1 01:12:17 2004] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Thu Apr  1 01:12:17 2004] [notice] Accept mutex: sysvsem (Default: sysvsem)
/etc/e-smith/web/panels/manager/cgi-bin/pleasewait: cannot create temp file for here document: Permission denied
[Thu Apr  1 07:22:18 2004] [error] [client 127.0.0.1] Premature end of script headers: /etc/e-smith/web/panels/manager/cgi-bin/pleasewait
/etc/e-smith/web/panels/manager/cgi-bin/pleasewait: cannot create temp file for here document: Permission denied
[Thu Apr  1 07:22:22 2004] [error] [client 127.0.0.1] Premature end of script headers: /etc/e-smith/web/panels/manager/cgi-bin/pleasewait
[Thu Apr  1 12:54:56 2004] [error] access to /etc/e-smith/web/panels/manager/html failed for 127.0.0.1, reason: AuthExtern pwauth [/usr/lib/apache/pwauth]: Failed (1) for user admin
/etc/e-smith/web/panels/manager/cgi-bin/pleasewait: cannot create temp file for here document: Permission denied
[Thu Apr  1 12:55:10 2004] [error] [client 127.0.0.1] Premature end of script headers: /etc/e-smith/web/panels/manager/cgi-bin/pleasewait
/etc/e-smith/web/panels/manager/cgi-bin/pleasewait: cannot create temp file for here document: Permission denied
[Thu Apr  1 12:55:12 2004] [error] [client 127.0.0.1] Premature end of script headers: /etc/e-smith/web/panels/manager/cgi-bin/pleasewait
/etc/e-smith/web/panels/manager/cgi-bin/pleasewait: cannot create temp file for here document: Permission denied
[Thu Apr  1 12:55:14 2004] [error] [client 127.0.0.1] Premature end of script headers: /etc/e-smith/web/panels/manager/cgi-bin/pleasewait
/etc/e-smith/web/panels/manager/cgi-bin/pleasewait: cannot create temp file for here document: Permission denied
[Thu Apr  1 12:55:15 2004] [error] [client 127.0.0.1] Premature end of script headers: /etc/e-smith/web/panels/manager/cgi-bin/pleasewait
/etc/e-smith/web/panels/manager/cgi-bin/pleasewait: cannot create temp file for here document: Permission denied
[Thu Apr  1 12:55:16 2004] [error] [client 127.0.0.1] Premature end of script headers: /etc/e-smith/web/panels/manager/cgi-bin/pleasewait
/etc/e-smith/web/panels/manager/cgi-bin/pleasewait: cannot create temp file for here document: Permission denied
[Thu Apr  1 12:55:17 2004] [error] [client 127.0.0.1] Premature end of script headers: /etc/e-smith/web/panels/manager/cgi-bin/pleasewait
/etc/e-smith/web/panels/manager/cgi-bin/pleasewait: cannot create temp file for here document: Permission denied
[Thu Apr  1 13:49:31 2004] [error] [client 127.0.0.1] Premature end of script headers: /etc/e-smith/web/panels/manager/cgi-bin/pleasewait
/etc/e-smith/web/panels/manager/cgi-bin/pleasewait: cannot create temp file for here document: Permission denied
[Sat Apr  3 10:44:11 2004] [error] [client 127.0.0.1] Premature end of script headers: /etc/e-smith/web/panels/manager/cgi-bin/pleasewait
/etc/e-smith/web/panels/manager/cgi-bin/pleasewait: cannot create temp file for here document: Permission denied
[Sat Apr  3 12:12:57 2004] [error] [client 127.0.0.1] Premature end of script headers: /etc/e-smith/web/panels/manager/cgi-bin/pleasewait

any help with this would be great.

Thanks,

JC

[mdo]

I have seen the same (?) problem with slightly different error messages in the httpd/ logfiles on a SMEserver 6.01. It turned out to be a permission problem for /bin/bash, goup and others had no access rights any longer. Something changes the file permissions (the weekly logrotate?).
Compare and change it to the same as the other files in /bin are.
Regards,
Michael

[kangkc]

I encountered the same problem on 6.0.1 when it switch over to a new week. The /bin/bash permission was set to rwx------.

This was resolved after reseting the permission.

I'm going to remove the logrotate from contab for the time being as it resulted in all mails cannot be received through POP/IMAP.

[stancol]

Just had the same thing happen on a upgrade from 5.6 to 6.01. Worked great for several days and then I ran into the Internal Server Error. By the way you all say reset the premissions back but back to what?

[mdo]

Like all (?) the other files in the /bin directory. Group and others need Read and Execute rights.

Regards,
Michael Doerner

[Anonymous]

Anyone knows the cause for the permission 'bash' being changed?
We had another hit over the weekend. Apparently it's not caused by the logrotate as I have disable that in crontab.
Help.....

[kangkc]

OK. I think I found the cause. It's caused by the scheduled weekly ClamAV scan. I just verirified by running the clamscan and that actually changes the permission of bash.

[stancol]

I didn't get the same results. I tried clamscan -v at the root prompt and it didn't change /sbin/bash permissions.

I solved the problem by writing a cron job to make sure it's changed each hour.

#!/bin/sh

chmod 777 /bin/bash

Call the file anything you want, make sure you have enough permissions for root to run the job. Then place the file above into /etc/cron.hourly/. The longest you can have a problem is 59 minutes 59 seconds.

At least it's a temporary fix.

[jc021179]

I dont think in my case it is actually a permission problem.

Links from the server-manager point to say:
http://server/server-manager/cgi-bin/pleasewait?/server-manager/cgi-bin/useraccounts

from this i get an internal server error.

but if i go to:
http://server/server-manager/cgi-bin/useraccounts

the module page loads fine.

[stancol]

The problem you discribe is the exact same problem I was having. You could short cut if you by passed the directly to the cgi bin just like you discribed. http://server/server-manager/cgi-bin/useraccounts. Where it hangs is on the cig-bin/pleasewhat? file. when that file doesn't fun neither does /cgi-bin/useraccounts. But if you bypass it just like you noted it works.

Actually I found the answer some where else in the boards. It is a permission problem. If you change /sbin/bash to chmod 777 it goes away. I wish I could remember who posted it but it is elswhere on these boards.

[Anonymous]

When you set the weekly/daily ClamAV scan on, it will add a cron jon in crontab which executes a shell script /etc/clamscan.

Run this shell script and test it, it changed my bash permission; never fail.

I have ran this a few times to make sure this is the cause.

I suspect it's due to some options in Clamscan which sre set in the sheel script that trigger off this permission problem, have yet to isolate which parameters. Perhaps some ClamAV expert can help on this.

[bobk]

Firstly, the correct permissions for /bin/bash are 755 NOT 777. 777 grants write permission to everyone (something you should not be doing).

Secondly, I have been running ClamAv on my 6.0.1-01 machines for months. The /etc/clamscan script runs daily and logrotate runs weekly. These two events have never changed the /bin/bash permissions on any of my 6.0.1-01 machines.

[stancol]

I'm glad someone finally answered my earlier question about the proper persmission for /bin/bash. Thanks.

[kangkc]

I went on to verify a few times. The tests again showed that running /etc/clamscan changed 'bash' permission.

I'm currently using www.pagefault.org contrib to install ClamAV on 6.0.1-01.

rpm log shows:
amavis-ng-0.1.6.4-03dc.noarch.rpm
clamav-es-0.68p1-es01.i386.rpm
clamav-es-libs-0.68p1-es01.i386.rpm

I've since remove the crontab entry for the clamscan.

[mdo]

Exactly the same issue here on a test system...
When clamscan is scheduled for weekly runs, the permissions for /bin/bash will be wrong on Monday morning.
I changed the schedule for the clamscan job to daily (after resetting the permissions) and the problem will be back every morning....
I do not blame clamscan, I suspect it might happen only on (old) slower systems where clamscan runs that long that it might interfere with another regular cron job???? Clamscan runs 1,5h on this old test server.
I manually changed the clamscan starting time from 0:00 to 2:00 to see whether there might be a specific other job running at that time but the result after 2:00 is as bad as at midnight. For the moment I have disabled the clamscan and all is fine....
Regards,
Michael