Koozali.org: home of the SME Server
Legacy Forums => General Discussion (Legacy) => Topic started by: jc021179 on April 03, 2004, 08:01:56 PM
-
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
-
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
-
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.
-
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?
-
Like all (?) the other files in the /bin directory. Group and others need Read and Execute rights.
Regards,
Michael Doerner
-
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.....
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
I'm glad someone finally answered my earlier question about the proper persmission for /bin/bash. Thanks.
-
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.
-
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
-
Nope. It's not caused by another cron job, neither it's due to old/slow machine.
Just run /etc/clamscan manually and you will see the permission changed.
Interesting thing is I have another test server which has the same rpms installed and do not encounter the problem.
-
I understand my total breakdown last week a little better now, I think.
After my restore to a separate library on a fresh install, I find numerous files (mostly from ibays) with changed permissions and ownerships, all totally out of sync with what they should have been.
Symptomatic, if Clamscan really operates the way indicated in this thread.
Regarding the countless hours I spent rebuilding a working server I shall NOT be installing clam again until this issue is resolved one way or the other!
-
I really feel sorry that you were finally able to break something, wyron. Rebuilding a server is not that much fun.
-
I really feel sorry that you were finally able to break something, wyron. Rebuilding a server is not that much fun.
Not just something - everything at once. But thanks for your sympathy, mb !
And no, it's not much fun, but you learn new things along the way. Without the abundant supply of howtos and pointers in bugthreads and other (sometimes obscure) places, I don't know if I'd ever have gotten it off the ground again, though.
As of now, the only things I haven't succeded in getting back to order, are the user address databases in the horde/imp infrastructure.
Perhaps you have a hint for me there ?
Funny (peculiar, not ha-ha) that it's so easy to build a new server, and so difficult to restore one.
But that's SME for you !
-
Unfortunately no hint in in rebuilding user adresses.
What happend? All CLAM AV's fault by changing permissions?
Useful command would have been: restore default permissions which is present on Windows Servers.
-
What happend? All CLAM AV's fault by changing permissions?
I simply don't know, but the info in this thread, combined with what I find in ibays of files having ownerships relating to other ibays and not their own,
etc., etc., I suspect it rather strongly !
Useful command would have been: restore default permissions which is present on Windows Servers.
Yeah, I know what you mean, but thats not our world.
-
This problem (clamav changing permissions) seems to be sporadic and cannot duplicated on all installations.
Example: I have multiple SME servers (both 5.6 & 6.0.1-01) all running clamav (from pagefault (http://www.pagefault.org/)). All of then use cron to run clamscan daily. None of them exhibit this changing of permissions problem.
I suggest that everyone having this problem start looking at what other contribs they have installed and a possible conflict. I do not use Spamassassin but it seems like most people having the problem do. So Spamassassin might be a good place to start looking.
-
Ray might have a point. Try reading the last part of this thread:
http://forums.contribs.org/index.php?topic=21802.0
How about it ?
Is our hardware really overmatched?
I should like everybody with these or related malfunctions to compare hardware setup.
As for me, I'm running an Asus P2B-ls board with a 400Mhz PII and 512 Mb RAM.
I seldom see the processor charged above 25% of its potential, but on the other hand I see my RAM being utilized to the hilt, especially at backup-time, when somebody is downloading from my contribs 'mirror' simultaneously.
And for reasons explained I am running only core applications just now.
-
I disagree about older PC. I have two PIII - 1Ghz w/ 512MB RAM, dual 40GB harddrives PCs. One is working fine and the other is having the same problem. I think the program sequence of the install is the issue. I tried to remmeber the squence for the second PC, but next week will be my 7th install of it.