Simple Machines Community Forum

Hi,

Though it may not look like server issue but I think its server, issue , I recently got a server running CentOS 6.3 , everything is fine, few others are working fine on it. I transferred a SMF forum to it and installed a theme from admin panel, went good..

Today when I tried installing mod , I was able to upload it , then it showed me list of edits and asked me ftp permission, I gave FTP details and verified, it says working. Then I pressed "Proceed" and after that keeps on loading and in the end I get:

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request

I checked domain error log, found following:

Script timed out before returning headers: index.php, referer: http://domain.com/index.php?action=admin;area=packages;get;sa=upload

And when I try to see what files it is trying to modify : it shows:

QuoteSome of the files the package manager needs to modify are not writable. This needs to be changed by logging into FTP and using it to chmod or create the files and folders. Your FTP information may be temporarily cached for proper operation of the package manager. Note you can also do this manually using an FTP client - to view a list of the affected files please click here.
The following files need to made writable to continue installation: /home
/home
/home

So essentially it is trying to change permission of /home ....  :-\

Furthermore, this server has suPHP running, at some moment, /home/username permission was changed to group writable and got error , I have root access to this server hence fixed the permission..

So what I think, package manager is trying to change permission for wrong files..

How can I fix it, its driving me nuts .. !!!!


EDIT:
It looks like path issue but I have given full path, tried relative path but doesn't work..

Any mod?

You run cPanel right?

What's the TimeOut direct in Apache?
Apache Configuration > Global Configuration (in WHM..)

@ema
There is no mod, only a new theme is installed..

@Liroy
It is DA

Secondly, when I tried to upload extracted files, it straight away modified permisssion of /home/username and suPHP gave me error that /home/username is writable.

And as said earlier , it is looking over wrong file, it is trying to modify /home and where I think lies problem.

Oh yeah if you use SUPHP and ask SMF to change the permissions it really screws it up.

Quote from: Ricky. on March 03, 2013, 02:22:49 AM
@ema
There is no mod, only a new theme is installed..

Sorry, I was absolutely not clear...
I wanted to ask if you have this issue with any mod or one in particular.

Nope, mods are not installing, its with all.

Colin, I don't think suPHP is issue , smf simply check if its writable, and it is and then only changes permission but somehow it is looking for wrong folders and trying to change permission which never happens..

suphp is a pain in the ass when its not good configured... also make sure your folders are set with right permissions main folder httpdocs or public html 750 underneath you can use 755 for all files / folders.... check your php.ini / mysql.cnf and your other configuration files if they are set up right....

suPHP on itself is absolutely *not*  a pain in the ass and changing permissions through suPHP will work perfectly fine.
It's stuff like mod_security and suhosin that might if improperly configured give problems, but suPHP itself will work fine while you put chmod OK. The only reason when suPHP would screw up, if you put a wrong username:group in the apache VirtualHost...

Ricky, don't know where to find it in DirectAdmin, but do check the directive for apache's timeout still hehe :P

Not the case from my experimenting

QuotesuPHP on itself is absolutely *not*  a pain in the ass

Read the whole quote, Core - it's fine when it's properly configured. When it's not properly configured, it thoroughly is a PITA. ;)

But that's just it and what I meant :D The only thing you *really* have to configure (so what suPHP doesn't find out on it's own after compiling it, and next to that: most control panels do that only part for you!), is the user+group you want it to check the scripts running under for a virtualhost... Eg the line in httpd.conf that tells PHP which user:group the scripts *must* run under.
If you get that wrong... Yeah, well, perhaps shouldn't play with servers in the first place then and stay well away. :P Breaking suPHP on cPanel servers for example is almost beyond ridiculous to even achieve in the first place. :P

If you would say it for suhosin and/or mod_security: Agreed :) They can be a pile of sh** and annoying to configure it in such a way that nobody will ever encounter problems with it: but still offer security :P But suPHP? No wai. It's the one piece of software that in the years of being involved with backends: it never gave me any trouble and it's configuration is *so* easy that even with the slightest bit of knowledge it can be setup and configured. o0

Hence, I really am with Ricky on this one: I doubt, very much, it's suPHP causing the problem.
(Notteeeee: Unless he put the vh-path to be "/home", but if that were the case the site as a whole wouldn't normally be loading up.)

anything in /var/log/syslog ?

What virtual path are you trying? It sounds like it should be /domainname.com/public_html/. I've never used DA though so I don't know entirely how it sets things up. It sounds like it's similar to cPanel except that each domain gets its own directory and public_html (in cPanel, everything is in /public_html for the main domain, and you specify the directory for each subdomain or addon domain when you add them in the control panel).

This issue is getting complicated . ..

Here are the latest observations:
@Liroy
DA maintains general config of httpd at : /etc/httpd/conf/extra/httpd-default.conf
Timeout was 60,
I tried 240 and instead of timeout, I get :

QuoteYou cannot download or install new packages because the Packages directory or one of the files in it are not writable!

However, /var/log/messages is logging this error continuously multiple times when I try to install mod :

Quotekernel:[1016560.129073] nf_ct_ftp: dropping packetIN= OUT=lo SRC=0000:0000:0000:0000:0000:0000:0000:0001 DST=0000:0000:0000:0000:0000:0000:0000:0001 LEN=436 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=TCP SPT=21 DPT=40186 SEQ=1845996668 ACK=1022066861 WINDOW=265 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A3C92E6213C92816C)

Btw, I thought its firewall issue, but I  disabled firewall completely, flushed Iptables rules but It is ipv6 request which is not enabled on this system.

Now so we have two problems:
1. FTP packet being dropped (for localhost and most probably as there in IPV6  on this ssystem) however I can make ftp connection using ftp client to this system normally.
2. It is looking over wrong directory

I checked file permission form Admin-->Packages --> File permission
IT is showing all to Writable (chmod 705)

I am naive in IPv6 and don't want to mess it on live server, however on similar server running cPanel things are fine..
I can think of following solutions:...
Direct SMF to not to make IPV6 FTP connection.. but how ?
and after that look into directory location issue ..

I guess you are telling FTP to connect to localhost, tell it to connect to 127.0.0.1 instead?

Well,  I already tried that after making that post and infact used full domain and it was able to connect but this time it modified permission of
/home/UserName folder and resulted in suPHP error..

So, now it is that package manager is looking over wrong directory .

Quote from: Ricky. on March 05, 2013, 08:16:06 AM
Well,  I already tried that after making that post and infact used full domain and it was able to connect but this time it modified permission of
/home/UserName folder and resulted in suPHP error..

So, now it is that package manager is looking over wrong directory .

Exact same symptom I had if I remember correctly.

So you mean it is because of suPHP and not because the way package manager decide for  chmod ?

Quote from: Ricky. on March 05, 2013, 10:24:26 AM
So you mean it is because of suPHP and not because the way package manager decide for  chmod ?

Precisely.

i encountered the same kind of errors a while back using plesk on a server and fixed it using relative path in SMF rather than the proposed (and wrong) absolute one.

This seems related.
http://www.simplemachines.org/community/index.php?topic=372905.0

AB was on a server running php in CGI mode. Illori most likely in mod_php (DSO).
I wonder what your full chown and chmod settings are.

check for SElinux

Quote
kernel:[1016560.129073] nf_ct_ftp: dropping packetIN= OUT=lo SRC=0000:0000:0000:0000:0000:0000:0000:0001 DST=0000:0000:0000:0000:0000:0000:0000:0001 LEN=436 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=TCP SPT=21 DPT=40186 SEQ=1845996668 ACK=1022066861 WINDOW=265 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A3C92E6213C92816C)

as tis looks like it...

Actually that would be related to iptables. He probably has CSF running. ;)
SELinux is something different.

Alright..  this is insane.. I was avoiding to work on SMF install on this server  as I had plan to look into this issue again , so finally I decided to work on it and actually took backup of things, even took server snapshot as had decided to go liberal to fix it.
But..
It just installed easily and without any problem..
That is making crazy.. its my server, had not done anything apart of reboot 2 days back when stupid datacenter guy thought I need it in single user mod for some diagnose..

I think something is changed, gonna check it now.. first logs ;)

Did your /tmp get cleared upon reboot? *curious*

Nothing in logs, and at once I thought SuPHP is not working but it is  !

Is that on reboot , /tmp get cleared.. but hows that effect things ?

Of course suPHP works. :)

Hmm... I never asked; what caching do you have compiled to Apache?
And before the errors started occuring, had you just recompiled Apache/PHP?

That was a new DA server, initially hardened and running DirectAdmin. Everything was find unless I made first SMF installation and rest  you know. And NOPE I am not able to recall that I did anything on this server apart of tweaking firewall as per complaints of few clients this server (CSF firewall).


And interestingly this time it had not even asked for ftp login and and username.

Btw, what do you mean by caching.. Apache handler ?
Its fastCGI ..

Alrighty. :)

Nope I mean something like eAccellerator or XCache or APC.

You mean PHP accelerator..

Nope , none so far, and I forgot that ;) 
Will do APC though ..

No, caching.

SMF doesn't know or care about opcode caches but eAccelerator, XCache and APC all have data storage APIs.

That said, the out of the box configuration will cache opcode caches to be largely pointless.

Indeed ^  Caching. :)

Either way, reason I ask is because I've seen this type of behavior (spitting out strange errors while no misconfiguration exists, no matter which PHP mode (DSO/mod_php, suPHP, (F)CGID and no matter which MPM either.)) with 2 types of caching that make use of /tmp where after a httpd restart or PHP recompile (which also invokes a reload, lol.) the errors started occurring.
Doing mysql shutdown, destroy everything in /tmp, restart httpd and bring mySQL back up fixed those problems. (The mySQL shutdown because of it's socket ex.)
Problems varied from ridicilous permission errors to attachments being unable to save because it had problems with /tmp.
Till today, i'm still not entirely sure why it showed that behavior. I haven't seen it ever since PHP 5.3.22. I have theories but because the issues don't occur anymore it's hard to check, lol.

To note: I'm not sure if the caching had anything to do with it, the servers so happened to have it. And one server that didn't have it didn't show issues; but that isn't conclusive.


On a sidenote by the way... You said "suPHP works" but later on mention "Handler is FCGI". That means it's not suPHP, but FCGI. suPHP is a handler, just like FCGI is a handler. The two don't run simultaneously, or at least: not that I have ever seen, heard or read about nor been prompted the option :P
You could be running SuHosin with FCGI perhaps? :)
It doesn't really matter, FCGI acts quite similar in quite some cases, but suPHP is just so slightly more secure (and resource intensive..) where as FCGI requires moar extra security.

Imo ensure php.ini settings are properly configured.
(ie. if using apache location is:  /etc/php5/apache2/php.ini)

• Configure temp upload directory
• Change (increase) upload max limit, memory limit and related time intervals if necessary
• Set permissions for that temp folder to 0755 and ownership to www-data:www-data

Quote from: CoreISP on March 29, 2013, 01:36:58 AM
Indeed ^  Caching. :)

Either way, reason I ask is because I've seen this type of behavior (spitting out strange errors while no misconfiguration exists, no matter which PHP mode (DSO/mod_php, suPHP, (F)CGID and no matter which MPM either.)) with 2 types of caching that make use of /tmp where after a httpd restart or PHP recompile (which also invokes a reload, lol.) the errors started occurring.
Doing mysql shutdown, destroy everything in /tmp, restart httpd and bring mySQL back up fixed those problems. (The mySQL shutdown because of it's socket ex.)
Problems varied from ridicilous permission errors to attachments being unable to save because it had problems with /tmp.
Till today, i'm still not entirely sure why it showed that behavior. I haven't seen it ever since PHP 5.3.22. I have theories but because the issues don't occur anymore it's hard to check, lol.

One more mysterious case added, may be full system restart did the trick as I avoid server restart ,.. you see those shiny uptime things ;)

Quote from: CoreISP on March 29, 2013, 01:36:58 AM
In a sidenote by the way... You said "suPHP works" but later on mention "Handler is FCGI". That means it's not suPHP, but FCGI. suPHP is a handler, just like FCGI is a handler. The two don't run simultaneously, or at least: not that I have ever seen, heard or read about nor been prompted the option :P
You could be running SuHosin with FCGI perhaps? :)
It doesn't really matter, FCGI acts quite similar in quite some cases, but suPHP is just so slightly more secure (and resource intensive..) where as FCGI requires moar extra security.

My bad.. all the time I was typing suPHP but I was actually referring to suhosin .

Uptime counters I abandoned for a while haha, figured kernel updates are slightly more important than a shiny counter, plus... I had a server up for 700+ days or something and then there was a power outage in the datacenter. *RAGE* ;) It's no use! :P