I am trying to install elgg version 1.12.2 according to documentation http://learn.elgg.org/en/1.x/intro/install.html
I have uploaded elgg on server, created MySql database and created data folder.
After that I open in thew latest chrome my website and process installation starts.
Immediately I have experienced warning:
I have tried to open "test" link(which points to rewrite.php page) but this page does not exists???
Here is list of all files in my root folder: http://i.imgur.com/kcQkeei.png
I have downloaded latest elgg from https://elgg.org/download.php
Mod Rewrite should be installed and enabled. If you have done this before it seems to be a permission problem.
Try running these commands:
chown apache: path_to_elgg_dir -R
chmod 644 path_to_elgg_dir -R
It might be selinux issue. You can check selinux status using sestatus -v.
In order to disable selinux follow this link.
rewrite.php does not exist indeed as it's special path that's supposed to be rewritten by mod_rewrite of equivalent (depending on type of web server you're using). If you get 404, that means you have not configured URL rewriting properly.
The link that you posted yourself contains "Troubleshooting" section. Additionally I'd recommend enabling curl in your PHP configuration to make sure that installer is able to reliably test URL rewriting (your error indicates that it's missing).
You did not mention any issues with following installation documentation? What server are you using? Did you have problems with any steps described in documentation?
Related
I have a centOS -based virtual machine on digital ocean.
It is running NGINX HTTP sever.
I configured it to use multi domains, and set up SSL.
One of my domains runs a Wordpress application.
I migrated the WordPress files from my godaddy hosting.
Everything works great except when I try to upgrade the wordpress core ( updating and installing plugins works just fine).
When I try to upgrade WordPress to version 5.4.2 I get a permissions error (as shown in attachment photo):
Permission denied in /var/www/mydomain.com/wordpress/wp-admin/includes/class-wp-filesystem-direct.php on line 281
wordpress core upgrade file permissions error display
I tried doing the following just to diagnose the issue... I have the directory full access to nginx user:
chmod -R 777 /var/www/
chown nginx:nginx /var/www/
This did not work
I made sure php user is nginx by outputting echo exec('whoami'); on the page.
I am completely dumbfounded.
Does anyone know what the problem may be?
As a last resort I manually upgraded my wordpress version using FTP, but I'm concerned that I never figured out the root cause of this issue and it will spring back up again opening up a can of worms.
CentOS includes a mandatory access control (MAC) security mechanism in its Linux kernel by the name of SELinux. According to a support forum thread on Wordpress.org, this mechanism sometimes can cause issues that manifest with this error.
SSH into your server and use the following command to change the SELinux "context" for the entire /var/www/mydomain.com folder:
chcon -R –-type httpd_sys_rw_content_t /var/www/mydomain.com/
The last post in the above-linked thread indicated that this change of context alleviated the errors you're seeing.
As an aside, for your system's security, ensure you change your file permissions back to their defaults.
A client informed me that any time he tries to update a plugin, he gets an error:
To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host.
I don't have FTPd setup on the server, but this seems like a basic permissions issue, right? I've never had to use FTP credentials to update any other WordPress installations.
Well, I did some reading and started messing with permissions and long story short, out of frustration, I eventually made everything writeable by everybody:
sudo chmod -R 777 src
But I'm still getting the same error. So it has to be some type of configuration issue, right?
I ran a few find . -exec grep commands to determine if there is a hard-coded document root (like in Joomla), but I came up empty handed.
Do I really have to install FTPd to be able to update WordPress from the admin interface?
Is there a config file somewhere that specifies the document root location?
Is there some other configuration option that I'm missing here?
Or maybe it's something in the database? The site was originally on a shared host but was moved to a DigitalOcean VPS a month or so ago.
I was able to force WordPress to use the filesystem instead of FTP by setting the FS_METHOD constant in wp-config.php:
define('FS_METHOD', 'direct');
More details can be found in the WordPress codex.
Try running chown -R apache:apache on the directory. I recall running in to an issue with ownership even when permissions were OK. You may have more success posting this on ServerFault as well.
Using MariaDB, Apache, PHP 5.4.x, RHEL 7
How do I allow configuration.php to be written to?
Installed Joomla several times, always ending up with the configuration.php file not writable. I proceeded, copied the config content and created a new php file, placed it where Joomla lives, opened up the permissions, changed to apache:apache, still nothing. I've referenced several articles, notably this one:
Installing Joomla 3 Error: Your configuration file or directory is not writable
I have also tried creating an empty configuration.php file and placing it in the joomla root, opening up permissions - didnt work.
My current state of installation is configuration.php file in place, but unable to remove the installation directory via the web installer (assuming because I shoehorned the config file into place and still not being writable).
I've tried several permissions setups then attempting to remove the install directory without success. Manually removing the install directory via rm -r only yields a totally inaccessible site forcing me to wipe my joomla files, databases, and install again. Thanks in advance.
The first thing I would do is check what user php runs at on your server, and compare this with ownership of your site files.
Create user.php file at the root of your domain with
<?php echo exec('whoami'); ?>
then open that file with your broser. This will give you the name of the user that php runs as on your server. It may be apache but it may not.
Compare this user with the ownership of config.php and your site installation as a whole.
If you upload a new Joomla site via SFTP and follow the standard browser instal steps, permissions shouldn't be a problem. If you are say uploading a zip file and using a terminal connection and SSH, make sure your SSH connection is the same user as the php user on your server.
Good luck!
Working with my server guy - found out that several sebool settings were keeping Apache from doing what it needed to do. Going one step further, we identified that sebool commands needed to be ran to allow httpd_can_sendmail in order to use the Sendmail feature. Hope this helps someone out there.
The command that seemed to do the trick was sudo chcon -R -t httpd_sys_rw_content_t /var/www/html
In our case, problem was with CentOS permissions. So if Joomla is installed on CentOS powered server, you need to change config file (/etc/selinux/config) to look like this:
[root#host2a ~]# cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=permissive
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted
# SETLOCALDEFS= Check local definition changes
SETLOCALDEFS=0
Actually, you only set SELINUX to permissive.
Hope this helps.
p.s. Solution works for RedHat too.
With the Apache and php pre-installed on OS X Mountain Lion, here are the steps I thought sufficient to run a server locally—without installing MAMP (which would install duplicates):
Uncomment the line LoadModule php5_module libexec/apache2/libphp5.so in /etc/apache2/httpd.conf.
Add the appropriate /etc/apache2/users/calaf.conf.
Save the php example above in ~/Sites/introductory-example.html (correction)
Restart Apache by running sudo apachectl start (or sudo apachectl restart).
Save a file containing <html><head><title>Example</title></head><body><php? echo "Hi"; ?></body></html> (or rather, be precise, this one) twice—first in /Library/WebServer/Documents/introductory-example.html and a duplicate in ~(whoami)/Sites/introductory-example.html).
I now expect that pointing to either http://localhost/introductory-example.html or to http://localhost/~calaf/introductory-example.html will give me a page with two features:
The title of the page is "Example".
The body of the page is "Hi."
Whether I am looking at the introductory-example.html in /Library/WebServer/Documents or in ~/Sites/ I get the first (the title is correct) but not the second (the body is empty)—why?
I ways symlink /Library/WebServer/Documents into my home folder, and change apache to run as my user instead of the default user. Also you need to enable htaccess for most PHP code (set AllowOverride to "All" I think) and probably install MySQL (the official pkg installation will work out of the box with apple's pre installed PHP).
If you aren't comfortable configuring apache, then MAMP is a good idea.
To my knowledge PHP is not activated system wide. It isn't in any system and/or combination I ever tried anyways. Apache is running PHP for files in a particular folder only (and its sub-folders). The standard apache folder should be in:
/Library/WebServer/Documents/
This guide should get you up and running although I haven't tried it myself.
EDIT:
You need to save a file which contain PHP code in .php, not .html. Rename or re-save the file to introductory-example.php
The following URL do not work since the path does not exist.
http://localhost/Users/calaf/Sites/introductory-example.html
Use the following URL (you maybe need to remove the tilde ~)
http://localhost/~calaf/introductory-example.php
Fresh install of a Debian server. Apache2, PHP5.
When I try to browse a PHP file I get 403 Forbidden. I am able to browse to html files.
I have tried the following:
Reinstalled Apache, PHP, libapache2-mod-php5
Restarted Apache
Checked the conf file thoroughly, copied from default, set the correct Directory path and allow from all
Checked permissions of directory, as a test have given full 777 permission to /var/www/site - still forbidden
Cant think of what else to try ?
Perform chmod 755 of the directory in which the PHP scripts reside.
After that restart the Apache/nginx server
or
if above method not work then contact your hosting provider to whitelist that url to phpscript because it can be issue with mod_security. Its the most annoying thing hostgator user are facing.
Check if the alow/deny pattern in your http.conf is set correctly.
What's written to the apache error log?