Topic: Internal Server Error via web and no Admin Console screen at Server

[pwgsc1]

Hi Folks,

Here's what I was doing :

- Upgrading Gallery 2.2.3 to Gallery 2.3
- That was successful
- After adding some pics I wanted to rebuild the thumbnails but it would hang a couple of minutes in
- Did some searching and I found that instead of "GD" image processor I should be using "ImageMagick"
- I did a Yum install ImageMagicK no problem it installed
- Could not get it to work in G2.  To activate it you are required to type in the PATH to the ImageMagicK binarys. 
- The path is /usr/bin
- G2 comes back and says that "path is invalid"

I check into this and it can be a couple of things.
- Permissions on the files
- PHP.ini setting
- something new in G2.3  Adding /usr/bin to open_basedir and restarting  apache


Well you know which one i did?  Yep, the first one.

- I chmod the files and /user/bin directory

Here's what some of the files in my /user/bin look like:

-rwxr-xr-x  3 root root       3156 Jul 14  2007 zegrep
-rwxr-xr-x  1 root root       7096 Jun  1  2009 zeisstopnm
-rwxr-xr-x  3 root root       3156 Jul 14  2007 zfgrep
-rwxr-xr-x  1 root root       1016 Jul 14  2007 zforce
-rwxr-xr-x  3 root root       3156 Jul 14  2007 zgrep
-rwxr-xr-x  1 root root      68748 Nov 26  2007 zip
-rwxr-xr-x  1 root root      28172 Nov 26  2007 zipcloak
-rwxr-xr-x  1 root root       1188 Jul 25  2008 zipgrep
-rwxr-xr-x  2 root root     110096 Jul 25  2008 zipinfo
-rwxr-xr-x  1 root root      24080 Nov 26  2007 zipnote
-rwxr-xr-x  1 root root      27316 Nov 26  2007 zipsplit
-rwxr-xr-x  1 root root         41 Jul 14  2007 zless
-rwxr-xr-x  1 root root       1878 Jul 14  2007 zmore

admin_error_log  looks like this:

[Sat Dec 12 17:03:11 2009] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
[Sat Dec 12 17:03:11 2009] [notice] Digest: generating secret for digest authentication ...
[Sat Dec 12 17:03:11 2009] [notice] Digest: done
[Sat Dec 12 17:03:11 2009] [notice] Apache configured -- resuming normal operations
[Sat Dec 12 17:14:28 2009] [error] [client 127.0.0.1] Can't do seteuid!
[Sat Dec 12 17:14:28 2009] [error] [client 127.0.0.1] Premature end of script headers: index.cgi
[Sat Dec 12 17:14:45 2009] [error] [client 127.0.0.1] Can't do seteuid!
[Sat Dec 12 17:14:45 2009] [error] [client 127.0.0.1] Premature end of script headers: index.cgi
[Sat Dec 12 17:14:51 2009] [error] [client 127.0.0.1] Can't do seteuid!
[Sat Dec 12 17:14:51 2009] [error] [client 127.0.0.1] Premature end of script headers: index.cgi
[Sat Dec 12 17:14:51 2009] [error] [client 127.0.0.1] Can't do seteuid!
[Sat Dec 12 17:14:51 2009] [error] [client 127.0.0.1] Premature end of script headers: index.cgi
[Sat Dec 12 17:14:51 2009] [error] [client 127.0.0.1] Can't do seteuid!
[Sat Dec 12 17:14:51 2009] [error] [client 127.0.0.1] Premature end of script headers: index.cgi
[Sat Dec 12 17:14:51 2009] [error] [client 127.0.0.1] Can't do seteuid!
[Sat Dec 12 17:14:51 2009] [error] [client 127.0.0.1] Premature end of script headers: index.cgi


- I've removed ImageMagicK and that did not fix the problem
- yes I've done my   signal-event post-upgrade; signal-event reboot

When I try to login as "admin" at the Server screen , it just loops back to the login

When I try ot login to Web Interface I get:

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, admin and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.

I'm pretty sure I've shagged the file / directory permissions on /user/bin but how do I fix them?

Thanks,

Craig


 

[cactus]

I check into this and it can be a couple of things.
- Permissions on the files
- PHP.ini setting
- something new in G2.3  Adding /usr/bin to open_basedir and restarting  apache

Well you know which one i did?  Yep, the first one.

- I chmod the files and /user/bin directory

Here's what some of the files in my /user/bin look like:

Code: [Select]

-rwxr-xr-x  3 root root       3156 Jul 14  2007 zegrep
-rwxr-xr-x  1 root root       7096 Jun  1  2009 zeisstopnm
-rwxr-xr-x  3 root root       3156 Jul 14  2007 zfgrep
-rwxr-xr-x  1 root root       1016 Jul 14  2007 zforce
-rwxr-xr-x  3 root root       3156 Jul 14  2007 zgrep
-rwxr-xr-x  1 root root      68748 Nov 26  2007 zip
-rwxr-xr-x  1 root root      28172 Nov 26  2007 zipcloak
-rwxr-xr-x  1 root root       1188 Jul 25  2008 zipgrep
-rwxr-xr-x  2 root root     110096 Jul 25  2008 zipinfo
-rwxr-xr-x  1 root root      24080 Nov 26  2007 zipnote
-rwxr-xr-x  1 root root      27316 Nov 26  2007 zipsplit
-rwxr-xr-x  1 root root         41 Jul 14  2007 zless
-rwxr-xr-x  1 root root       1878 Jul 14  2007 zmore

I am sorry that you had to find this out the hard way, but next time come and ask here first. The issue you have created might be a hard one to solve. You might be lucky using this option, but it might not work for you as well. If it does not I think you are back to either manually setting permissions or reinstalling your server again.

Try this first:

If you boot single user, there is a small chance that you could repair things by doing:

Code: [Select]

rpm --setugids $(rpm -qa)
rpm --setperms $(rpm -qa)
signal-event post-upgrade ; signal-event reboot

[CharlieBrady]

- Upgrading Gallery 2.2.3 to Gallery 2.3

Therfore, off topic for this particular forum, which concerns only software included in the SME server CDROM.

[cactus]

Therfore, off topic for this particular forum, which concerns only software included in the SME server CDROM.

Moving to SME 7.x Contribs where it is more appropriate.

[pwgsc1]

Sorry about the mis-posting,  I'll be more carefully in the future.  I posted in SME Server because I thought the 'base" files where affected.

Besides all that......thank you Catcus. Your suggestion appears to have solved my problem. I can now login to the console at the Server and Web interface from a browser.

Back to my Gallery issue.

Thanks,

Craig

[electroman00]

Adding /usr/bin to open_basedir and restarting  apache

Absolutely no reason to do that, plenty of reason not to.

ls  /usr/bin

Those are all the files apache can run.
Do you really want a web user to run those.
It's akin to giving someone a machine gun to rob you.

This is all you need...

Code: [Select]

php_admin_value open_basedir /opt/gallery:\n";
Also this is wrong...
php_admin_value open_basedir /opt/gallery:/tmp\n";

BTW Gallery all versions, don't use/need to run any of those files.

[cactus]

BTW Gallery all versions, don't use/need to run any of those files.

That is not true, when you use IMagick and/or NetPBM you might need access to them (at least in earlier Gallery 2 versions).

[electroman00]

That is not true, when you use IMagick and/or NetPBM you might need access to them (at least in earlier Gallery 2 versions).

Well based on my statement your right, sorry for that, I'll correct my statement.

BTW Gallery all versions, doesn't need to run any of the files in /usr/bin.

Still not a true statement??
So your limited to...

Code: [Select]

php_admin_value open_basedir /opt/gallery:\n";
With that as the directive, howto overcome that limitation and still have eveything work??

IOW what are the other options.
I'll rule out one option right off the bat "simlink".

Also this is absolutly not an option nor is it needed...
php_admin_value open_basedir /opt/gallery:/tmp\n";

For one thing, 'open_basedir /tmp' does absolutely nothing, well except for creating  a system vulerabilty.
Secondly no web app needs access to /tmp for any reason, there's nothing in /tmp and the web app
doesn't need to use a tmp space outside it's restricted base.
Third, if the web app needs a temp write directory then simply create it within the restricted base with proper perms
and check the perms of other dir's within the base restriction to ensure their not a+w also.
That is..... simply common sense.

The /usr/bin issue is a bit more difficult if you want to consider a global solution for the masses.
An individual admin solution is to copy the needed executables to within the restricted base and set the correct perms.
Problem with that is, when the sys is updated those executables will not be updated.
So that solution isn't exactly optimal for the masses.

An associated issue/problem of vulnerability is already in the tracker #139 and that one is exculsive to SME.
And it has a simple solution, I know because, I've had the solution in place since bug 139.

Thus the signature 139.
When you figure that one out, it's likely 'true' will become 'false' above.
Well maybe not, however there will be a better understanding of all the issues presented here.
BTW 139 is considered a system vulerabilty.
Guess we'll need to wait for a compromise to agree on the concept of "system vulerabilty".

BTW if 139 does ever get fixed, then there might be a consideration to return RKHunter to the base.
RKHunter did report the /tmp problem, as well as other problems.
IOW the concept is, don't fix the RKHunter reported problems, just eliminate the reporter.

So much for "kill the mesenger".

hth

[Stefano]

For one thing, 'open_basedir /tmp' does absolutely nothing, well except for creating  a system vulerabilty.
Secondly no web app needs access to /tmp for any reason, there's nothing in /tmp and the web app
doesn't need to use a tmp space outside it's restricted base.
Third, if the web app needs a temp write directory then simply create it within the restricted base with proper perms
and check the perms of other dir's within the base restriction to ensure their not a+w also.
That is..... simply common sense.

The /usr/bin issue is a bit more difficult if you want to consider a global solution for the masses.
An individual admin solution is to copy the needed executables to within the restricted base and set the correct perms.
Problem with that is, when the sys is updated those executables will not be updated.
So that solution isn't exactly optimal for the masses.

An associated issue/problem of vulnerability is already in the tracker #139 and that one is exculsive to SME.
And it has a simple solution, I know because, I've had the solution in place since bug 139.

Thus the signature 139.
When you figure that one out, it's likely 'true' will become 'false' above.
Well maybe not, however there will be a better understanding of all the issues presented here.
BTW 139 is considered a system vulerabilty.
Guess we'll need to wait for a compromise to agree on the concept of "system vulerabilty".

BTW if 139 does ever get fixed, then there might be a consideration to return RKHunter to the base.
RKHunter did report the /tmp problem, as well as other problems.
IOW the concept is, don't fix the RKHunter reported problems, just eliminate the reporter.

So much for "kill the mesenger".

hth

electroman00, here we go again..

Can I ask you why you have such an attitude?
you say you have the solution for bug #139, but I can't find anything from you in bugzilla.. why don't you share it? why don't you work WITH the devs (and the community) FOR the community?

[cactus]

An associated issue/problem of vulnerability is already in the tracker #139 and that one is exculsive to SME.
And it has a simple solution, I know because, I've had the solution in place since bug 139.

Thus the signature 139.
When you figure that one out, it's likely 'true' will become 'false' above.
Well maybe not, however there will be a better understanding of all the issues presented here.
BTW 139 is considered a system vulerabilty.
Guess we'll need to wait for a compromise to agree on the concept of "system vulerabilty".

BTW if 139 does ever get fixed, then there might be a consideration to return RKHunter to the base.
RKHunter did report the /tmp problem, as well as other problems.
IOW the concept is, don't fix the RKHunter reported problems, just eliminate the reporter.

So much for "kill the mesenger".

As rkhunter was causing more issues (like false positives, causing more harm then good) and causing a lot of questions to be raised in the forums, it was decided that due to limited developer resources it should be removes from the core. Users can still install it from the smecontribs repository IIRC.

Apart from that as Stefano already said. If you have solutions to known problems (or for new problems as well), please help the community by adding the to bugzilla. This way all of the community will benefit from your knowledge and solutions in stead of splitting hairs and causing frustration in the community.

[electroman00]

you say you have the solution for bug #139, but I can't find anything from you in bugzilla..

Surprisingly that's due to the fact that the solution is contained within bug 139.
Surprisingly in fact the very first post in 139, a bug I did not create, but did adopt the understanding solution 4 years ago.
Therefore it becomes obvious some didn't read the very first post in 139 and understand bug 139.!

The same "some" that profess "Read ALL the Documentation" maybe.?!?!

Should I create another duplicate bug, there's already 2 other dupe bugs for your reading pleasure?
I'm not sure I understand your emotional point of view, that's why I ask...

Possibly you could consider an intellectual / technical point of view.
3 bug reports, at least 1 forum advertisement (now 2) and 1 signature, +4 years.
Not exactly optimal bug statistics, something that may not be agreeable to all or for that matter anyone.
Certainly deserves an intellectual investigation and understanding to ensure that it doesn't re-occur repeatedly.
One might/could/should assume that....to be a real point to understand.

Certainly a more valuable point, then the emotional fantasy of going somewhere.

electroman00, here we go again..

Since you didn't specify where we are going again, I'll just forgo the invitation, thanks anyway though.

More interesting point, is to consider the disadvantage to the "emotional posting approach" applied to issue/problem resolution in a public forum.
Thus a possible causation for unsuccessful resolution, which isn't....of any value or help to anyone.

Keep in mind, everyone who post's an issue/problem/suggestion in a public forum, is a messenger.
Don't "shoot the mesenger" just because you don't emotionally understand or like the message.
Sometimes it's prudent to investigate and understand the message/s.

Who knows, one may even avail one's self of clues, ideas, theories, concepts embbeded within the message and learn something....
For example the solution to a problem/s.

A spoonfull...

RKH is a messager that sends information reguarding events on the system.
In particular, to make the administrator & developers aware of possibly undesireable events/issues/problems.

They could be....
false positives

or

They could be....
true positives 

Code: [Select]

As rkhunter was causing more issues (like false positives, causing more harm then good)
Those issues (RKH report messages) indicate one of four possible things....

1. Sombody inside is doing something that isn't kosher.
2. Sombody outside is doing something that isn't kosher.
3. The system is doing something that isn't kosher.
4. False positive indication.

If one deseminates 1-4 incorrectly, the advantages that RKH has to offer may not be realized.

For example, RKH reported the #139 issue (see dupe bugs).
One could look at the RKH message report and all bugs of concern from all 4 perspectives.

#3 in this case would ended up being the winner in reality, at least that's what investigative experiance would prove.

Fact...system isn't configured correctly by the developers.
Upon investigation, ultimately that becomes the underlying fact.
Developers aren't perfect as we all know, there is a bug tracker, a testiment to that FACT.
Ultimately that's what RKH provides to the developers and certainly needs to be considered as some value to them.
A tool to help them as well as administrators.

Again consider...
Don't "shoot the mesenger" just because you don't understand or like the message.
Sometimes it's prudent to investigate and understand the message.

Granted RKH doesn't tell you exactly who......exactly what, yes.
RKH doesn't resolve anything, RKH simply reports for desemination.

If the choice is to deseminate and remediate, then the advantages of RKH may be realized.

RKH works fine on the SME system.
That is, once the sme bug's are remediated.

139 is one of those bug's and with a simple remediation as indicated in 139, as well as all the other
bugs that need to be remediated, RKH will provide a excellent system monitor tool if your concern
is to know if someone/something is effecting the system.

A watch dog so to speak!!
Ruff... Ruff...

Certainly there maybe issues particular to SME, RKH allows system admin's/dev's to facilitate those issue's.
However I haven't run accross those types of issues as of yet.

Code: [Select]

As rkhunter was causing more issues (like false positives, causing more harm then good)
In my case it was...
As rkhunter was causing more awareness (like true positives, causing more good then harm) as I used RKH.
That's due to an understand of those issues RKH the messager, was reporting.

IOW Understanding bug 139 and remediating the issue....as indicated in the bug, RKH then stopped reporting the TRUE postive.

Surely RKH was creating some additional awareness to issues/problems.
Removing RKH doesn't remove/resolve those issues/problems.

Beleive it or not, those issues/problems still exist, 4 years later in fact.

RKH removal, simply removes the awareness creation afforded by RKH.
One could consider the awareness creation of (extreme) value to the system administrator as well as to the developers.
Bug 139 undoubtedly appears to substantiate that premise.

If you don't care if someone/something is effecting the systems vulnerabilty, then RKH is of no value.

IMO In fact, RKH is the finest tool for the job (system monitor, Ruff, Ruff), none better to be found to date.
Not sure the viability to remove it from the base was prudent.

A hammer is a real fine tool, if your skilled and understand how to use it.
Likewise for RKH.

hth

[cactus]

Electroman00, as I stated earlier you are free to install RKHunter, but due to the limited amount of resources the development team feels it is better to not support RKHunter in the base. You are free to disagree, but this is the current situation.
To prevent unneeded alarming of system administrators who are unfamiliar with the internals of a linux server I personally do not think RKHunter would add much as in all my years administrating SME Servers, reading the forums and being active in bugzilla I have not seen many issues concerning rootkits or security breaches in a default SME Server.