I have recently finished a website for a customer, the site works great locally. Currently only the homepage is working. However all links return a 500 server error.
This is 1and1, and I haven't heard many good things about it.
Currently I have the laravel folders for my app within a folder called webapp.
the domain name points to webapp/public.
I have also added the following line to my htaccess to get it to work
RewriteRule ^ /home.php [L]
which works for the homepage. I don't know much about the htaccess file, so I've messed around with a few other options such as
RewriteRule ^ /folios.php [L]
as well which is one of the links in my site, however this doesn't work.
My routes currently work like this
Route::get('/folios', 'AlbumsController#index');
However they return 500 server error
Change the line in the ".htaccess" file in the root folder from RewriteRule ^ index.php [L] to
RewriteRule ^ /index.php [L]
My suspicion is that you need to update the paths contained within public/index.php
Check out this article for instructions: https://medium.com/#Bohr/deploy-laravel-application-on-shared-hosting-godaddy-953758dc57ac
Did you run composer install on the server or copy out the vendor directory? You may also want to check that your htaccess file in the public directory contains the directives that are required (https://github.com/laravel/laravel/blob/master/public/.htaccess).
I did not realize that the server generated a new .htaccess file within the /webapp/ folder where I pointed the domain; I was editing the wrong .htaccess file
I have an index.html file in my Apache DocumentRoot directory but when I go to my URL, I am still getting a directory listing of my DocumentRoot directory instead of the index.html file being displayed. The apache access_log shows 200's when I reload the page. Any suggestions?
Use
DirectoryIndex index.html
It tells apache what document to show for a directory request.
update
You should specify just the filename that apache will look for in the folder requested.
Not saying this will fix it for you, but for me when first getting started with Apache2 it was file permissions that would get forgotten when moving or writing new file under the web root directory
ls -hal /var/www/host_one/index.html
If above doesn't have read (r) permissions for the same user:group or if the ownership doesn't include the user/group of the web server, then try the following for allowing group reads
# Modify ownership, change 'www_host' to Apache2 group
chown ${USER}:www_host /var/www/host_one/index.html
# give read+write (6) to user and read (4) to group owners
chmod 640 /var/www/host_one/index.html
Try refreshing the website and see if permissions where the issue. Note most web documents only require read permissions and ownership to be correct for browsers to be allowed to pick them up for rendering, on rare occasions you may need executable (1 or x) permissions for server scripts (be cautious of ownership in such cases) and last write permissions (2 or w) should likely never be seen without good reasons on files within your web root.
Second thing to try, use the index.html within your browsers URL bar
# by IP
http://192.168.0.100/index.html
# by domain
http://site-name.local/index.html
If the above loaded your document then, like #Pekka 웃 stated already, you've likely got a server option that's missing or enabling directory listings instead of looking for a index page within that directory. If this is the problem then there's two ways of fixing it that I've tried in the past. One, htaccess configuration to disable directory listing within that sub-directory, two, server vhost configuration to prevent whole site from directory listings. Personally I prefer to use option two and then on directories that should be allowed to be listed place an htaccess config for permissions instead of denials.
Working with .htacess file has always been a very frustrating experience for me. Someone please help.
This is what I want to achieve:
I am running Ubuntu 14.04.
Redirect my entire site (example.com) to a maintenance.html page.
Block everybody else except one IP, for example, I need to allow only 123.456.789.0
Here are my files:
Location of my index.html is /var/www/html
Location of my maintenance.html is /var/www/html
Location of my .htaccess file is /var/www/html
Contents of My .htaccess file:
#Rewrite to www
Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^example.com[nc]
RewriteRule ^(.*)$ http://www.example.com/$1 [r=301,nc]
#301 Redirect Old File
Redirect 301 /index.html /maintenance.html
#Block users by IP
order allow,deny
deny from all
allow from 123.456.789.0
Please help me understand:
Is the location of each of the above files right? In what cases, the
page ends up in 500 internal server error?
What changes should I make in
/etc/apache2/apache.conf
/etc/apache2/sites-enabled/000-default.conf OR
/etc/apache2/sites-available/000-default.conf
Is is necessary to run a2enmod rewrite?
Should I add <IfModule mod_rewrite.c> and </IfModule> as header and footer in any of the above config files?
Sorry for too many questions, but I really want know it all this time.
Thanks in advance.
Is the location of each of the above files right? In what cases, the
page ends up in 500 internal server error?
A "500 Internal Server Error" message means there's an error and you're expected to check the server logs for the exact details. Apache will not display the error message to be seen by everyone.
What changes should I make
It depends on what the problem is. If the problem is "500 Internal Server Error" that means that we still don't know what the problem is.
Is is necessary to run a2enmod rewrite?
That command enables mod_rewrite. You need to enable it if it isn't enabled. You don't need to enable it if it's already enabled.
It's worth noting that this command is not part of official Apache distribution. Some Linux distros (namely Debian and derivatives) change third-party packages to match their configuration preferences, as in this case.
Should I add <IfModule mod_rewrite.c> and </IfModule> as header
and footer in any of the above config files?
As documentation explains, this block can be used to ignore directives when a given module is not installed. This can be useful for configuration templates to be distributed and optional features. In your case, it'll silently ignore your code if mod_rewrite is not available—you don't want that.
Last but not least:
order allow,deny
deny from all
allow from 123.456.789.0
... belongs to the old (and really hard to understand) Apache/2.2 syntax. If you are using Apache/2.4* you may want to try Require.
(*) Some distros hate bundling recent software but 2.4 has been around for several years
Thanks to #OlafDietsche and #ÁlvaroGonzález for this quick help. I am keeping their suggestions here so somebody like me will find it useful.
The problem is with my goals, not with the syntax. With their comments and answers, I came to know that my 2 goals were mutually contradicting ones.
I configured .htaccess to do both page-redirection and IP block. But if I am blocking (almost) everybody from accessing the site, page redirection makes no sense.
The required configuration in .htaccess is:
#Rewrite to www
Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^example.com[nc]
RewriteRule ^(.*)$ http://www.example.com/$1 [r=301,nc]
#301 Redirect Old File
Redirect 301 /index.html /maintenance.html
When I access my website using localhost/myfiles/index.html, my index file opens fine but if I want to click on the other pages/buttons, it doesn't work. The only way to open the other pages is if I do it manually by using localhost/myfiles/news.html and then only that pages works so I can't basically navigate my way around the website.
I had my website online yesterday and I know it works because I used it. I plan on making changes to my website and I need to be able to test them offline before I upload them to my online server. I just want to be able to navigate my site offline using XAMPP the same way that I would if it was uploaded on GoDaddy.
EDIT:
This is my .htaccess file
RewriteBase /
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.html -f
RewriteRule ^(.*)$ $1.html
Any suggestions ?
Seems you have .htaccess at your root and its not working properly.
in httpd-vhosts.conf
<Directory "PATH TO YOUR PROJECT ROOT">
Options Indexes MultiViews FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
Or update your .htaccess file
Without seeing your system it's hard to tell what's wrong but try the following (comment answer if these didn't work WITH log error messages)
[STOP your Apache server instance. Ensure it's not running!]
1) move apache server/install to a folder that has no long file names and spaces
2) check httpd.conf in install\conf folder and look for AccessFileName. If it's .htaccess change it to a file name windows accepts (e.g. conf.htaccess)
3) double-check that your htaccess file gets read: add some uninterpretable garbage to it and start server: you should get an Error 500. If you don't, file is not getting read, re-visit httpd.conf file (if that looks OK, check if this is the only file which defines htaccess and it's location and it does at one place -within the file- only; also check if both httpd.conf and htaccess files are accessible: not encrypted, file access rights are not limited, drive/path available -and no long folder path and file names-)
STOP Apache again, then go on:
4) If you have IIS too on your system, stop it (uninstall it too if you can) from services.msc
5) Add the following to the top of your valid htaccess file:
RewriteEngine On
RewriteLog "/path/logs/rewrite.log" #make sure path is there!
RewriteLogLevel 9
6) Empty your [apache]\logs folder (if you use another folder, then that one :)
7) Check the following entries are set and correct:
Action application/x-httpd-php "c:/your-php5-path/php-cgi.exe"
LoadModule php5_module "c:/your-php5-path/php5apache2.dll"
LoadModule rewrite_module modules/mod_rewrite.so
Avoid long path names and spaces in folder names for phpX install too!
8) START apache server
You can do all the steps above or go one-by-one, your call. But at the end of the day make sure you tried everything above!
If system still blows up and you can't fix it, copy&paste error message(s) from log folder for further assistance
Ok, so i've previously set up two virtual hosts and they are working cool. they both house simple web projects and work fine with http://project1 and http://project2 in the browser.
Anyway, I've come to add another vhost. I edited the /etc/hosts file with 127.0.0.1 project3 and also updated the httpd-vhosts.conf file by copy and pasting the previous entries for project2 and editing the file path.
I've checked all the file and folder permissions (in fact I copied and pasted from project2) and simply put a "hello world" message in the index.php file.
I get a 403 forbidden permission denied message when accessing http://project3
Why is this, I just can figure out what step I've missed as everything seems to be set up correct.
Check that :
Apache can physically access the file (the user that run apache, probably www-data or apache, can access the file in the filesystem)
Apache can list the content of the folder (read permission)
Apache has a "Allow" directive for that folder. There should be one for /var/www/, you can check default vhost for example.
Additionally, you can look at the error.log file (usually located at /var/log/apache2/error.log) which will describe why you get the 403 error exactly.
Finally, you may want to restart apache, just to be sure all that configuration is applied.
This can be generally done with /etc/init.d/apache2 restart. On some system, the script will be called httpd. Just figure out.
I just fixed this issue after struggling for a few days. Here's what worked for me:
First, check your Apache error_log file and look at the most recent error message.
If it says something like:
access to /mySite denied (filesystem path
'/Users/myusername/Sites/mySite') because search permissions
are missing on a component of the path
then there is a problem with your file permissions. You can fix them by running these commands from the terminal:
$ cd /Users/myusername/Sites/mySite
$ find . -type f -exec chmod 644 {} \;
$ find . -type d -exec chmod 755 {} \;
Then, refresh the URL where your website should be (such as http://localhost/mySite).
If you're still getting a 403 error, and if your Apache error_log still says the same thing, then progressively move up your directory tree, adjusting the directory permissions as you go. You can do this from the terminal by:
$ cd ..
$ chmod 755 mySite
If necessary, continue with:
$ cd ..
$ chmod Sites
and, if necessary,
$ cd ..
$ chmod myusername
DO NOT go up farther than that. You could royally mess up your system.
If you still get the error that says search permissions are missing on a component of the path, I don't know what you should do. However, I encountered a different error (the one below) which I fixed as follows:
If your error_log says something like:
client denied by server configuration:
/Users/myusername/Sites/mySite
then your problem is not with your file permissions, but instead with your Apache configuration.
Notice that in your httpd.conf file, you will see a default configuration like this (Apache 2.4+):
<Directory />
AllowOverride none
Require all denied
</Directory>
or like this (Apache 2.2):
<Directory />
Order deny,allow
Deny from all
</Directory>
DO NOT change this! We will not override these permissions globally, but instead in your httpd-vhosts.conf file.
First, however, make sure that your vhost Include line in httpd.conf is uncommented. It should look like this. (Your exact path may be different.)
# Virtual hosts
Include etc/extra/httpd-vhosts.conf
Now, open the httpd-vhosts.conf file that you just Included. Add an entry for your webpage if you don't already have one. It should look something like this. The DocumentRoot and Directory paths should be identical, and should point to wherever your index.html or index.php file is located. For me, that's within the public subdirectory.
For Apache 2.2:
<VirtualHost *:80>
# ServerAdmin webmaster#dummy-host2.example.com
DocumentRoot "/Users/myusername/Sites/mySite/public"
ServerName mysite
# ErrorLog "logs/dummy-host2.example.com-error_log"
# CustomLog "logs/dummy-host2.example.com-access_log" common
<Directory "/Users/myusername/Sites/mySite/public">
Options Indexes FollowSymLinks Includes ExecCGI
AllowOverride All
Order allow,deny
Allow from all
Require all granted
</Directory>
</VirtualHost>
The lines saying
AllowOverride All
Require all granted
are critical for Apache 2.4+. Without these, you will not be overriding the default Apache settings specified in httpd.conf. Note that if you are using Apache 2.2, these lines should instead say
Order allow,deny
Allow from all
This change has been a major source of confusion for googlers of this problem, such as I, because copy-pasting these Apache 2.2 lines will not work in Apache 2.4+, and the Apache 2.2 lines are still commonly found on older help threads.
Once you have saved your changes, restart Apache. The command for this will depend on your OS and installation, so google that separately if you need help with it.
I hope this helps someone else!
PS: If you are having trouble finding these .conf files, try running the find command, such as:
$ find / -name httpd.conf
restorecon command works as below :
restorecon -v -R /var/www/html/
Notice that another issue that might be causing this is that, the "FollowSymLinks" option of a parent directory might have been mistakenly overwritten by the options of your project's directory. This was the case for me and made me pull my hair until I found out the cause!
Here's an example of such a mistake:
<Directory />
Options FollowSymLinks
AllowOverride all
Require all denied
</Directory>
<Directory /var/www/>
Options Indexes # <--- NOT OK! It's overwriting the above option of the "/" directory.
AllowOverride all
Require all granted
</Directory>
So now if you check the Apache's log message(tail -n 50 -f /var/www/html/{the_error_log_file_of_your_site}) you'll see such an error:
Options FollowSymLinks and SymLinksIfOwnerMatch are both off, so the RewriteRule directive
is also forbidden due to its similar ability to circumvent directory restrictions
That's because Indexes in the above rules for /var/www directory is overwriting the FolowSymLinks of the / directory. So now that you know the cause, in order to fix it, you can do many things depending on your need. For instance:
<Directory />
Options FollowSymLinks
AllowOverride all
Require all denied
</Directory>
<Directory /var/www/>
Options FollowSymLinks Indexes # <--- OK.
AllowOverride all
Require all granted
</Directory>
Or even this:
<Directory />
Options FollowSymLinks
AllowOverride all
Require all denied
</Directory>
<Directory /var/www/>
Options -Indexes # <--- OK as well! It will NOT cause an overwrite.
AllowOverride all
Require all granted
</Directory>
The example above will not cause the overwrite issue, because in Apache, if an option is "+" it will overwrite the "+"s only, and if it's a "-", it will overwrite the "-"s... (Don't ask me for a reference on that though, it's just my interpretation of an Apache's error message(checked through journalctl -xe) which says: Either all Options must start with + or -, or no Option may. when an option has a sign, but another one doesn't(E.g., FollowSymLinks -Indexes). So it's my personal conclusion -thus should be taken with a grain of salt- that if I've used -Indexes as the option, that will be considered as a whole distinct set of options by the Apache from the other option in the "/" which doesn't have any signs on it, and so no annoying rewrites will occur in the end, which I could successfully confirm by the above rules in a project directory of my own).
Hope that this will help you pull much less of your hair! :)
it doesn't, however, solve the problem, because on e.g. open SUSE Tumbleweed, custom source build is triggering the same 401 error on default web page, which is configured accordingly with Indexes and
Require all granted
The server may need read permission for your home directory and .htaccess therein
You can try disabling selinux and try once again using the following command
setenforce 0
In my case it was failing as the IP of my source server was not whitelisted in the target server.
For e.g. I was trying to access https://prodcat.ref.test.co.uk from application running on my source server.
On source server find IP by ifconfig
This IP should be whitelisted in the target Server's apache config file. If its not then get it whitelist.
Steps to add a IP for whitelisting (if you control the target server as well)
ssh to the apache server
sudo su -
cd /usr/local/apache/conf/extra (actual directories can be different based on your config)
Find the config file for the target application for e.g. prodcat-443.conf
RewriteCond %{REMOTE_ADDR} <YOUR Server's IP>
for e.g.
RewriteCond %{REMOTE_ADDR} !^192\.68\.2\.98
Hope this helps someone
Add
<Directory "/path/to/webroot">
Options Indexes FollowSymLinks Includes ExecCGI
AllowOverride All
Order allow, deny
Allow from all
Require all granted
</Directory>
What this does is tell Apache2 to override any previous configs, and allow (200) from all before denying. (403) It also requires all requests to be granted. This code will have to go in every vhost file, but it does work. I have been using this for over a year.
to your config file (e.g. /etc/apache2/sites-enabled/000-default.conf)
Tested LAMP stack Debian 11