overwriting of php's default settings by Ossn not working on some servers

[githubertus]

The current handling is based on the assumption that PHP is running as an apache module which is not true in all cases.

In other words: all lines in the .htaccess section "" will be IGNORED, if php is NOT running as a module but CGI/Fast CGI mode

Or to put it this way: if(PHP_SAPI != 'apache2handler') { echo 'we cannot make use of current .htaccess php settings'; }

As a result users may run into problems when uploading larger images for example if the server's default php values are too small.

And that's why we need an additional way of setting up Ossn's php values reliably. One working way I tried yesterday could be to make the installer create a php.ini file in the root of Ossn, and add the lines

<IfModule mod_suphp.c> suPHP_ConfigPath /INSTALLATION_PATH_OF_OSSN <-- no trailing slash here! </IfModule> <Files php.ini> order allow,deny deny from all </Files>

at the bottom of .htaccess

[lianglee]

i agree, we need to generate php.ini as we generate .htaccess upon installation.

[jimmydmehta]

Could you please provide sample valid php.ini file and .htaccess file for OSSN

[githubertus]

I don't understand your intention, jimmydmehta. Each Ossn comes with a .htaccess file already, and the php.ini will be valid if it includes the same and syntactical correct instructions as the servers main php.ini file. Refer to https://www.opensource-socialnetwork.org/wiki/view/1974/how-to-increase-your-server039s-upload-file-size-limit for overwriting Ossn's default settings.

[jimmydmehta]

Thanks for the reply.
After I downloaded the zip of ossn version 4.2, its uploaded on my CentOS 6X web server having Apache (Apache/2.2.29), PHP 5.4 and MySQL 5.5. Now when I try to access, it gives me 2 errors on validate page,

(1) MOD_REWRITE REQUIRED Here, Please note, I have already added the below line in my httpd.conf, LoadModule rewrite_module modules/mod_rewrite.so Still I am getting the same error. Am I missing something?

(2) CONFIGURATION DIRECTORY IS NOT WRITEABLE I have already provided the path of data directory in the ossn.config.site.example.php file. This path is different from /var/www/.... And its as below, $Ossn->userdata = '/apps/ossn/';

I am installing and using the 1st time OSSN and PHP and struggling in completing the setup since 1 week to overcome above 2 errors. I think once these error gets resolved, the .htaccess file will be automatically generated.

please help

Just for the info., I have read almost all the related posts/articles for both the above issues but still facing the same issue.

[githubertus]

Yes, your missing something. Better said: your apache process is missing write permission for your Ossn directories. Most likely you installed the package as root and that's why all files and subdirectories are owned and writable by root, but not by apache. Run a ps axufrom your shell to find the owner of the apache process. Most of the times it's www-data. Then recursively change the owner of your Ossn files and folders accordingly.

And for future issues: Please start your own thread for your own issues and don't jump into an already existing thread created by someone else - even more if you have a completely different problem.

[sparrowme]

@jimmydmehta make sure your webserver can resolve whatever hostname you are accessing the installer from. The curl statement that tests the rewrite uses that hostname. I was forcing the hostname in my local hosts file to run the install on the server and getting the same error as you.

[githubertus]

Honestly, I'm not really happy with the change made to Ossn 5.1 because it'll prevent a lot of people from at least trying out Ossn. No question, that apachehandler is the more versatile way to configure php settings via .htaccess. But that doesn't mean that cgi-fcgi or fpm-fcgi won't work at all. The configuration is different, yes. And most of the times it would need consulting the provider and ask which way things can be accomplished. Some may have a cpanel configurator, others may allow to write your own php.ini file. Thus, instead of simply blocking all non apachehandler PHP variants, a warning of expected configuration issues would be more helpful to my opinion.