I am trying to install typo3 as per the instructions but I have a bit of a puzzle to solve.
It seems apache denies access to any files I try to access via any symbolic link in the site root directory. I have changed permissions from SymLinksIfOwnerMatch to FollowSymLinks and no joy.
I'm working on mac OSX (SL) and installing in my user's "Sites" directory. I can access any files in this CMS directory via the web browser just not anything through symbolic links.
I hope konsolenfreddy's comment was helpful already. I am trying to round things up here:
First check if the symlinks work from terminal and/or the filesystem in general.
Also, if you use absolute paths, the whole path from root to the file in question must be readable by the Apache user. *
If yes, check if the AllowOverride option is set for your webserver (or if applyable for the virtual host) For debugging you can set AllowOverride All in either apache2.conf, httpd.conf or in sites-available/default
If yes, check if FollowSymlinks is aktivated in any of the files responsible for your webroot, starting with apache2 working yourself down to the .htaccess files.
Try changing file permissions on the symlink file and the target directory (or files)
Try creating your own symlink and see what happens when you call it in the browser.
* Check this answer at askubuntu.com for more hints.
Ok I eventually solved it. In OSX the final file that governs access of sites installed in user directories is the last Include line in the apache2/conf/extra/httpd-userdir.conffile. Once I changed that my problems went away.
Thanks to all the people that replied my questions.
Related
I have what is almost certainly a newbie question. I expected to find the issue while writing this question, but I am still stuck.
I want to change the DocumentRoot for apache, but I keep getting the error message "DocumentRoot must be a directory".
Situation:
The code is running in a virtual VMWare machine 4.0.4 build-744019
The version of linux is Scientific Linux release 6.4 (Carbon)
The version of apache is Apache/2.2.15 (Unix) (this is a yum install with nothing
special)
In the httpd.conf
DocumentRoot "/home/stave/www"
When I restart, I get the message
Starting httpd: Syntax error on line 292 of /etc/httpd/conf/httpd.conf:
DocumentRoot must be a directory
Steps taken so far:
I ensured that the directory exists:
ls -asl /home/stave
4 drwxrwxrwx. 2 stave stave 4096 Feb 9 09:08 www
It even has a file in it "index.html", so I am very sure that the directory exists
I considered that it might be a priviledges issue so (this is a virtual development machine isolated from the internet, and I am troubleshooting so I am not too worried about security) as you can see I set the priviledges to 777.
I even changed the user that apache is running as (and confirmed that the change worked with ps) to stave to ensure that priviledges just shouldn't be an issue.
Stackoverflow
There are a few stack overflow answers, but most of them say "read the error message. It is saying that the directory doesn't actually exist". Others implied that there might a trailing slash at the end which would be bad.
Other websites
The most useful I found was this that advised
You probably got "DocumentRoot must be a directory" error even it is really a directory because of SELinux extensions. Run system-config-securitylevel (or redhat-config-securitylevel) to disable SELinux for httpd or give SELinux permissions to that
directory:
chcon -R -h -t httpd_sys_content_t /path/to/directory*
My version of linux isn't Security Enhanced Linux, so without understanding I tried it anyway: no effect.
Current situation
I have run out of ideas to try, so any diagnostic questions or advice would be greatly appreciated
The link you posted under "Other websites" highlights the root cause of your problem, which is Selinux.
Unless the server is part of a super secure environment, I would simply disable Selinux.
On RedHat / CentOS / Scientific Linux this can easily be done by editing /etc/sysconfig/selinux - find the parameter "selinux" and change the option "enforcing" to "disabled" as per the extract below:
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=disabled
It is probably wise to reboot the server after making this change.
You shouldn't just disable SELinux.
You need to set httpd_enable_homedirs to on.
yum -y install policycoreutils-python
setsebool -P httpd_enable_homedirs on
I ran into this problem today as well and it was because I moved my DocumentRoot from /var/www/html to /srv/www/html. As part of our security policies, we do not have the option to just Disable SELinux.
SO my fix, as I discovered was to change the SELinux file context for /srv to match /var. A compromise yes, but still better than disabling it altogether. Other than that... I made sure /srv/www and all subfolders had the httpd_sys_content_t to match the folders under /var/www and all is well now.
This is basically the same answer as David's, but just a little clearer, http serving directory has wrong SELinux security context set.
The full explanation to fix this is here, http://mybroadband.co.za/vb/showthread.php/588183-Fix-403-Forbidden-on-newly-configured-CentOS-6-5-httpd-server-(or-13-10-Ubuntu-LAMP)
My issue was that I was housing my websites inside a different directory than the documentroot path of /var/www/, so I had to follow the 3rd option in the link above to correct. I set the same file context of my /websites/ directory to match that of the /var/www/. What was odd is earlier versions of CentOS 5.5 must not have had the SELinux installed/enabled, because my other servers had no issue with this and when running the ls -Z at the command prompt displayed those folders as 'unlabeled'.
I'm running CentOS 6.5 on AWS from the official marketplace minimal install. So when I ran the ls -Z command on my folders I saw exactly what the link above shows as a possible issue.
Running the chcon command fixed my issue!
Just replace html/ with the directory you want to use!
chcon -Rv --type=httpd_sys_content_t html/
chcon -Rv --user=system_u html/
On a side note I also had to disable iptables to get the routing working, the defaults were serving up blank pages.
service iptables stop
Hope that helps anyone with the same issue.
Envirnoment:
Linux - root file system on a SSD
DocumentRoot on a HDD and mounted via fstab
Restarting apache2 after boot - no problem
Seems to be a timing problem that apache is started before the fstab mounts are completed.
Workaround:
Define the DocumentRoot directory on the root file system with the correct owner, group and permissions. The directory may be empty.
Firstly, there is no reason at all to turn off selinux to fix this issue, just change the selinux file context.
Secondly, when changing selinux file context, you should to set up a permanent rule for that path, such that when new files are copied in and/or replace existing files, restorecon actually fixes the problem, instead of breaking it, as is the case when you only use chcon.
Thus, for a symlink'ed DocumentRoot (let's give the actual full path to the directory as '/media/myDoc' for this example), run these two commands:
semanage fcontext -a -t httpd_sys_content_t "/media/myDoc(/.*)?"
restorecon -R /media/myDoc
Note, the full path is required when using semanage this way. You will not only fix the problem, but it won't break again when you run restorecon (or auto-relabel) in the future.
When using the Views admin panel, it appears completely mispresented. Looking at the files being accessed, it turns out that the needed css files are not loaded. My Drupal installation is within a /drupal/ subfolder, and when the module is trying to access domain.com/sites/all/modules/views/css/views.css a 404 is received.
I tried browsing manually to domain.com/drupal/sites/all/modules/views/css/views.css and it works, therefore the file is there and can be accessed from the web.
The strange thing is that for other folders there is no problem, for example both domain.com/modules/user/user.css and domain.com/drupal/modules/user/user.css work. It seems like a problem with sites/ only...
I do not have CSS optimization enabled, and all folders within sites/ have a 755 permission. Is there some configuration setting I'm missing?
Apparently, the domain I'm concerned about is a parked domain (or whatever this is called) for another one, and contained in a subfolder of public_html. Drupal installation, thus, is a subfolder of that subfolder (say, /home/user/public_html/my_domain/drupal) and all requests for my domain are redirected via an .htaccess and MOD_REWRITE, to the Drupal subfolder. For some reason, it didn't have the sites/ in its regexp (modules/ and themes/ were...).
You may have incorrect vhost configuration. In order to check if this is the reason, try accessing the site without the vhost i.e. localhost/drupal and see if this works.
If it loads correctly, then you need to set up the correct document root:
<VirtualHost *:80>
DocumentRoot /www/drupal
ServerName domain.com
</VirtualHost>
Then restart apache.
For more information about how to set up vhost, visit http://httpd.apache.org/docs/2.2/vhosts/examples.html
I am trying to get my OSX MacPorts install of Apache to NOT show directory listings. I have tried various configurations of the "options" directive in the httpd.conf file with no luck. When I go to the site, it still lists the root directory (there is no index file at the moment.)
Apache has been restarted after each change.
There is no .htaccess file in the / directory, so there shouldn't be anything overriding.
This is driving me crazy!
So basically something is overriding your config. From the documentation of apache we can read that Options is can be placed in various context: server config, virtual host, directory, .htaccess.
httpd.conf is read first, so if You provided the configuration properly there, it means that it is overridden somewhere else
How did You do enter the options in the config ? In the most basic variant it should be.
<Directory /path>
Options -Indexes
</Directory>
Here what you should do:
check module configurations in modules for Options Indexes
check the main virtualhost definition, probably called default or 000-default
If it still does not help, add Options -Indexes to your virtualhost directly (provided you have not done it already). Or add it to the .htaccess file in your directory (allowing Options in .htaccess needs to be switched on)[as suggested in comments]
I have been trying to install Ushahidi platform for weeks but without any luck. I recently started over using Ushahidi latest release ushahidi-Ushahidi_Web-2.0.1-140-g0991172.zip and extracted it to folder ushahidi under my root.
I am using godaddy Linux server. I have tried both the manual and wizard to setup Ushahidi. In all cases, after installation, I get the same error when I try to access admin page. The error reads:
No input file specified.
I have tried tried installing using the wizard and the manual process. My PHP version is as required.
Any help will be appreciated. I need it to work so I can move on and customize it. Very disappointing such a good open source tool has poor installation guides!
Thanks.
Sting
there are a few things that can trip up following the installation.
Make sure that:
mod_rewrite is turned on in apache "a2enmod rewrite"
AllowOverride All is set in your apache config for your site (/etc/apache2/sites-available/default)
your .htaccess file points to the correct webroot
I have been trying to setup cakephp on an Amazon EC2 (Ubuntu) instance ..
however when i try running the code .. it shows no color, no
styles, no layout etc.
I have updated the httpd.conf with the following content ..
Options Indexes FollowSymLinks
AllowOverride All
It still doesnt seem to work.
What is it that am doing wrong ???
Regards
Abhishek Jain
I had the same problem. Found out that my .htaccess files didn't have the permission to override anything, because AllowOverride was set to none.
I looked for the value in my httpd.conf file under /etc/httpd/conf/ and changed it to All
<Directory "/var/www/html">
AllowOverride All
</Directory>
Not EC2 related but I had a simmilar issue on the Mac when installing CakePHP on Mamp. A complete delete of all the CakePHP files and a re-install solved the issue for me.
I don't have much too much experience installing Cake, but you should probably check the following anyway:
a) Do you have the correct .htaccess files in the correct directories? Linux treats anything that starts with '.' as a system file, so you have to do
ls -a
to check if they are present. If you moved the files into the directories manually, instead of unpacking the Cake download in the location you wanted it, the .htaccess files may not have been moved.
b) Check your Apache error logs (I assume you're using apache) for errors, especially errors loading mod_rewrite. Make sure LoadModule rewrite_module libexec/httpd/mod_rewrite.so and AddModule mod_rewrite.c are specified in httpd.conf.
c) Where did you put this?
Options Indexes FollowSymLinks AllowOverride All
Without seeing more of your httpd.conf, there's no way of telling whether the Cake document root is inheriting these settings correctly.