I've been happy with ispconfig3 - and have got owncloud installed properly. but there is a php bug in uploading files > 2gb (it fails). much has been written about fixing it - but none of it works - EXCEPT setting upload_max_filesize and post_max_size to ZERO. setting it to 0 clearly has ownload functioning properly! however - needless to say other things (like wordpress) start to fail (it is immediately unable to log anyone in! I looked into having a custom php.ini just for owncloud but I ran into various issues when I suddenly realized that owncloud is running under fastcgi so that the various PHPINIDir and the like are ignored. (those are only for mod-php) but when I set owncloud to run under mod-php instead of FastCGI - it fails from what are clearly permission issues (it complains it cannot write to the config directory. I 777'ed it then that problem went away and another took its place... is there a clean explanation somewhere of what happens when ISPCONFIG changes from FastCGI to Mod-php? and is it easier to try and get mod-php to work? as setting up a custom php.ini under FastCGI seems pretty involved. any suggestions?? thanks and keep up the good work!
Its really easy to use a custom php.ini with ispconfig in fastcgi mode. All you have to do is to put the php.ini directives that you want to alter into the custom php.ini field of the website, everything else is handeld automatically by ispconfig. Use the same syntax as if you want to add them in a php.ini file e.g.: upload_max_filesize = 0 and not the apache syntax with PHP_ADMIN_VALUE! This opened up your files to all other sites on your server and never use mod_php for any application that handles sensitive data like files. PLease reset the permission of the web dir to 710 like they wre before.
wowsa! what a wonderful solution. dont know how I missed it. so of course apache directives with <IfModule mod_php5.c> php_value upload_max_filesize 0 .. and the like can be removed since we arent involing mod_php. apparently this is fundamentally a bug in php 5.3 because putting upload_max_filesize = 8000M does NOT make owncloud able to upload >2g files. but setting them to 0 does! thanks cdb.
Alas spoke too soon the custom php.ini section in ispconfig3 works great - you have the proper values as showed by phpinfo. however - though I could upload large files - the login is broken (like wordpress was when I changed these in the global php.ini). user account and login simply never recognizes the account information. when I change the custom php section values (upload_max_filesize and post_max_size) back to 8000M (which is what they were back in the original php.ini file - now I can login just fine! but I'm back to no >2gb uploads. when I look at error_log (when php values are 0) I see lines like: [Thu Feb 13 13:00:26 2014] [warn] [client 192.168.2.1] mod_fcgid: stderr: PHP Warning: Unknown: POST Content-Length of 18 bytes exceeds the limit of 0 bytes in Unknown on line 0, referer: http://owncloud.cdbsystems.com/ [Thu Feb 13 13:00:26 2014] [warn] [client 192.168.2.1] mod_fcgid: stderr: PHP Warning: Unknown: POST Content-Length of 13 bytes exceeds the limit of 0 bytes in Unknown on line 0, referer: http://owncloud.cdbsystems.com/ [Thu Feb 13 13:00:27 2014] [warn] [client 192.168.2.1] mod_fcgid: stderr: PHP Warning: Unknown: POST Content-Length of 9 bytes exceeds the limit of 0 bytes in Unknown on line 0, referer: http://owncloud.cdbsystems.com/ [Thu Feb 13 13:00:46 2014] [warn] [client 192.168.2.1] mod_fcgid: stderr: PHP Warning: Unknown: POST Content-Length of 64 bytes exceeds the limit of 0 bytes in Unknown on line 0, referer: http://owncloud.cdbsystems.com/ [Thu Feb 13 13:00:55 2014] [warn] [client 192.168.2.1] mod_fcgid: stderr: PHP Warning: Unknown: POST Content-Length of 64 bytes exceeds the limit of 0 bytes in Unknown on line 0, referer: http://owncloud.cdbsystems.com/ sigh.
Try to use a newer php version, e.g. php 5.4 or 5.5. ISPConfig allows you to have multiple php versions on your server and use them for your sites without the need to exchange the system php. e.g.: http://www.howtoforge.com/how-to-us...pm-and-fastcgi-with-ispconfig-3-debian-wheezy there are guides for other distributions available here on howtoforge as well, if you dont use debian.
fastcgi? and a quick spamassassin question I'm using Centos 6.4 - got a guide for installing php5.5 as an option? I'd like to try that to fix my fastcgi issue. also - a quickie I installed spamassassin as per perfect setup all works fine, but I'm satisfied that ***SPAM*** messages are REALLY ***SPAM*** - how can I simply delete them rather than rewrite the headers? I've seen some answers but they conflict...
we have a guide for php 5.4 for centos 6.3, which sould work most likely for centos 6.5 as well. a guide for php 5.5 is not available. Set spam kill level of the spamfilter policy that you use to the same number that is the spam tag 2 level now.
5.3.3 may be causing problems I'm running centos 6.4 (or 5 by this point) x64 - and have php 5.3.3 installed. I akeevabackuped a joomla site that is not quite working and I'm suspicious that the original site was running under php 5.3.10 and this might be the issue. credible? if so, is it 'safe' to upgrade the whole centos to 5.3.10? if so any quick pointers? and if not, I looked at your wheezy guide for multiple phps - any chance of a centos translation? thanks
Dont touch the system php. I would update the system php only in case that the update is provided with the normal "yum update" process. if you need a different php version then the one of the system php, then install it as additional php version for ispconfig: http://www.howtoforge.com/how-to-us...p-fpm-and-fastcgi-with-ispconfig-3-centos-6.3 This guide uses php 5.3.22. the current version of the 5.3 series is 5.3.28, so better use 5.3.28 instaed. the steps are the same, just repkace the version number in all commands.
THATS what I'm talking about missed the 6.3 instructions. most excellent. I was leary of system php update, but if 5.3.10 might have been close enough! will embark on this little adventure and report results!
minor note I note that --enable-cgi apparently was ignored as of 5.3.28 (there is no such listed, and there IS a -disable-cgi option so I guess fastcgi is the default now?) also with-fpm-user and with-fpm-group were also ignored. one more note memcacheD would not install apparently needs a new configure command to disable a sasl test... so far all looks good.
more entertainment - and couple more questions I'm digging into my joomla back end problem and I notice that the joomla was built with mysqli as the database type now when I created the database it needs under ispconfig3 - the only database type available to me was MySQL. this ok? its obviously connecting just fine - when I change the joomla database password now front end gets 'cannot connect to mysql'. all content LOOKS ok.. but any implications by joomla wanting mysqli as the databasetype? (when I tried putting mysql it tells me some extensions REQUIRE mysqli)
Thats ok. mysqli refers to the internal php mysql driver type and not the type of the database. Its fine to use mysqli, ispconfig uses internally mysqli as well as mysqli is the sucessor of the older mysql php driver.
