Debian WebServer - [SOLVED]

[Polybus]

Hi,

I'm trying to get a Debian WebServer running from home - with no luck.

I've got:
- Telstra Cable Connection
- Debian (Jessie) installed and working
- Apache2 installed and working
- I have forwarded Port 80 in my router to my Debian machine
- I have set up two different Virtual Sites via 000-default.conf in Sites-Available
- If I go to another machine on my home network and type in the local IP address (192.168.0.X) I get one of my sites (the first one in 000-default.conf)
- I have Dynamic DNS set up via Afraid DNS and the auto-updater set up via a CRON job.

- I am able to SSH and SFTP to my Debian machine using both my local IP address and my external IP address

But I just can't get to either of my Web Sites.

Always get the message:

Forbidden

You don't have permission to access /UI on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

I am thinking it is some kind of permissions thing that I don't understand with Debian - but clearly I don't really know what's going on.

What could be stopping me getting to my Websites externally?

Firewall?? Router?? Debian itself??

Help!!

Addit: On second thought - I don't think it will be Debian - because I can get to it via my Local Network - just not from the external world - must be the Router or Firewall??


Polybus

[dasein]

Ok, the fact that you can hit the machine in question from outside using SSH is a huge clue. Thanks both for checking it and for including the information in your post.

Likely culprits:

- Your ISP may be blocking traffic on Port 80.

- Your port forwarding for port 80 from your router to your server is misconfigured.

- A permissions issue

Based on everything you said in your OP, an ISP block on port 80 seems worth ruling out. The quickest way to check would be to have your Web server listen on a different port (say, 8080), and test it again. If you're successful using port 8080, then it's definitely your ISP. If not, then it's worth ruling out port forwarding misconfig.

If your router has a "DMZ" feature, putting the machine "outside" your firewall for a single test run would eliminate the router as the culprit. (Though I very much doubt that it's the router. If this were a matter of the router simply blocking all traffic, then SSH wouldn't work.)

The one thing that's bugging me is the error being thrown. It's an http error (403), which implies that the request is being received by your server box, but that Apache is having trouble handling the request. And that's what makes me think it could be a permissions issue. Are you 100% sure that you're using the exact same URL for both internal and external tests?

[dilberts_left_nut]

Suggests differences in the NameVirtualHost definitions, but not enough info.
What are the Servername directives, and how are you addressing your access attempts?

edit: @dasein - did you just add that or did I miss it on first read? .... (pre-coffee)...

[dasein]

edit: @dasein - did you just add that or did I miss it on first read? .... (pre-coffee)...

I added a little exposition to the last paragraph soon after I posted it, to explain why I was thinking what I was thinking. But that addition was several hours before your post, and I haven't been here since.

(I'm trying to be better at including the "why" and not just the "what" of my >1-word answers. I figure they teach more that way.)

Mebbe it's gremlins. (OTOH, any excuse for more coffee is a good one.)

[ralph.ronnquist]

- I have set up two different Virtual Sites via 000-default.conf in Sites-Available

Ordinarily you'd rather declare the sites in different configuration files, perhaps by first copying "default.conf" into two files, say, "siteA.conf" and "siteB.conf" before editing them to provide their respective appropriate content access. Thereafter you would change the sites-enabled directory to not have the "000-default.conf" link, and instead have links to your new configuration files, typically with number prefixes for the link names so as to prescribe their load order.

Anyhow, in addition to what has been suggested, you should also verify virtual site access by issuing a manually construed HTTP request using "telnet" or "nc" on the local network. The manual request would be three text lines as in:

• GET / HTTP/1.1
  Host: siteA
  empty line

The "Host" attribute of the request indicates which virtual server is concerned, and you should thus be able to verify the response for either of them. You may then drill down by providing longer URL paths as second element of the "GET" line, and thereby confirm that the virtual services are configured correctly.

[Polybus]

Thanks for the tips

You guys can try to see my site - URL : MyShed.hiddencorner.org - see the error for yourself - see if you get the /UI appended to the end of the URL like I do.

dasaein

Port Blocking??
I changed my ports.conf from Listen 80 to Listen 8080
I was then able to enter my external URL "MyShed.hiddencorner.org:8080"and it would take me to my Debian box, but would list the contents of the www directory rather than display the Web Site - if I then selected the directly "MyShed" from the directory listing, the Website displayed OK.

Permissions Issue??
The directories /var/www and /var/www/html plus the Virtual Site directories and all the files in them are owned by root and in the root group - but they all definitely have read permissions for everyone.

The fact that when I use Port 8080 as makes me think its probably Port 80 being blocked - but everything I can see all over the Web says Telstra (the major ISP in Australia) don't block Port 80.

As for using the exact same URL -
I can get to the Web Page using my internal IP address - this will also work when I am trying to log in via SSH or SFTP

I can log in using my URL "MyShed.hiddencorner.org" via SSH or SFTP - but when I enter that into my Browser it changes it to MyShed.hiddencorner.org/UI and I get the error message.

ralph
Sorry for being such a chucklehead - but I didn't really understand some of what you said - and certainly don't know how to action it.

I kinda understand about splitting up the two different sites into different files

but not a clue about issuing manually constructed TELNET commands - when I put in the lines you suggest - (replacing in my names) I just get error messages - HOST: Command not found


dilbert

Here is my 000-default.conf file:

NameVirtualHost *

<VirtualHost *>
ServerName airgunner.homenet.org
ServerAlias http://www.airgunner.homenet.org
DocumentRoot /var/www/html
CustomLog /var/www/html/Logs/Airgunner.log combined
ErrorLog /var/www/html/Logs/Airgunner.log
</VirtualHost>


<VirtualHost *>
ServerName myshed.hiddencorner.org
ServerAlias http://www.myshed.hiddencorner.org
DocumentRoot /var/www/html
CustomLog /var/www/html/Logs/MyShed.log combined
ErrorLog /var/www/html/Logs/MyShed.log
</VirtualHost>


Here is My apache2.conf file: (which is just the default Debian one....
# This is the main Apache server configuration file. It contains the
# configuration directives that give the server its instructions.
# See http://httpd.apache.org/docs/2.4/ for detailed information about
# the directives and /usr/share/doc/apache2/README.Debian about Debian specific
# hints.
#
#
# Summary of how the Apache 2 configuration works in Debian:
# The Apache 2 web server configuration in Debian is quite different to
# upstream's suggested way to configure the web server. This is because Debian's
# default Apache2 installation attempts to make adding and removing modules,
# virtual hosts, and extra configuration directives as flexible as possible, in
# order to make automating the changes and administering the server as easy as
# possible.

# It is split into several files forming the configuration hierarchy outlined
# below, all located in the /etc/apache2/ directory:
#
# /etc/apache2/
# |-- apache2.conf
# | `-- ports.conf
# |-- mods-enabled
# | |-- *.load
# | `-- *.conf
# |-- conf-enabled
# | `-- *.conf
# `-- sites-enabled
# `-- *.conf
#
#
# * apache2.conf is the main configuration file (this file). It puts the pieces
# together by including all remaining configuration files when starting up the
# web server.
#
# * ports.conf is always included from the main configuration file. It is
# supposed to determine listening ports for incoming connections which can be
# customized anytime.
#
# * Configuration files in the mods-enabled/, conf-enabled/ and sites-enabled/
# directories contain particular configuration snippets which manage modules,
# global configuration fragments, or virtual host configurations,
# respectively.
#
# They are activated by symlinking available configuration files from their
# respective *-available/ counterparts. These should be managed by using our
# helpers a2enmod/a2dismod, a2ensite/a2dissite and a2enconf/a2disconf. See
# their respective man pages for detailed information.
#
# * The binary is called apache2. Due to the use of environment variables, in
# the default configuration, apache2 needs to be started/stopped with
# /etc/init.d/apache2 or apache2ctl. Calling /usr/bin/apache2 directly will not
# work with the default configuration.


# Global configuration
#

#
# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
#
# NOTE! If you intend to place this on an NFS (or otherwise network)
# mounted filesystem then please read the Mutex documentation (available
# at <URL:http://httpd.apache.org/docs/2.4/mod/core.html#mutex>);
# you will save yourself a lot of trouble.
#
# Do NOT add a slash at the end of the directory path.
#
#ServerRoot "/etc/apache2"

#
# The accept serialization lock file MUST BE STORED ON A LOCAL DISK.
#
Mutex file:${APACHE_LOCK_DIR} default

#
# PidFile: The file in which the server should record its process
# identification number when it starts.
# This needs to be set in /etc/apache2/envvars
#
PidFile ${APACHE_PID_FILE}

#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 300

#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 100

#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 5


# These need to be set in /etc/apache2/envvars
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}

#
# HostnameLookups: Log the names of clients or just their IP addresses
# e.g., http://www.apache.org (on) or 204.62.129.132 (off).
# The default is off because it'd be overall better for the net if people
# had to knowingly turn this feature on, since enabling it means that
# each client request will result in AT LEAST one lookup request to the
# nameserver.
#
HostnameLookups Off

# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a <VirtualHost>
# container, error messages relating to that virtual host will be
# logged here. If you *do* define an error logfile for a <VirtualHost>
# container, that host's errors will be logged there and not here.
#
ErrorLog ${APACHE_LOG_DIR}/error.log

#
# LogLevel: Control the severity of messages logged to the error_log.
# Available values: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the log level for particular modules, e.g.
# "LogLevel info ssl:warn"
#
LogLevel warn

# Include module configuration:
IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf

# Include list of ports to listen on
Include ports.conf


# Sets the default security model of the Apache2 HTTPD server. It does
# not allow access to the root filesystem outside of /usr/share and /var/www.
# The former is used by web applications packaged in Debian,
# the latter may be used for local directories served by the web server. If
# your system is serving content from a sub-directory in /srv you must allow
# access here, or in any related virtual host.
<Directory />
Options FollowSymLinks
AllowOverride None
Require all denied
</Directory>

<Directory /usr/share>
AllowOverride None
Require all granted
</Directory>

<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>

#<Directory /srv/>
# Options Indexes FollowSymLinks
# AllowOverride None
# Require all granted
#</Directory>


# AccessFileName: The name of the file to look for in each directory
# for additional configuration directives. See also the AllowOverride
# directive.
#
AccessFileName .htaccess

#
# The following lines prevent .htaccess and .htpasswd files from being
# viewed by Web clients.
#
<FilesMatch "^\.ht">
Require all denied
</FilesMatch>


#
# The following directives define some format nicknames for use with
# a CustomLog directive.
#
# These deviate from the Common Log Format definitions in that they use %O
# (the actual bytes sent including headers) instead of %b (the size of the
# requested file), because the latter makes it impossible to detect partial
# requests.
#
# Note that the use of %{X-Forwarded-For}i instead of %h is not recommended.
# Use mod_remoteip instead.
#
LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

# Include of directories ignores editors' and dpkg's backup files,
# see README.Debian for details.

# Include generic snippets of statements
IncludeOptional conf-enabled/*.conf

# Include the virtual host configurations:
IncludeOptional sites-enabled/*.conf

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

[dasein]

Ok, a couple of mechanical points

1) For the love of J "Bob" Dobbs, help those who are trying to help you; put

Code: Select all

 tags around text output to improve readability (think "tl;dr" on steroids).

2) Some of the detail in your follow-up post illuminates two things:

- You may have more than one underlying issue, but your "presenting symptom" is an Apache config problem, pure and simple.  It is [b]not[/b] a problem with Debian, nor is it a hardware issue of any kind (including port blocking).  That is to say, URLs do not spontaneously rewrite themselves [i]en route[/i] between client and server.  I ran the telnet test so aptly suggested by ralph.ronnquist, above; your port 80 is open and Apache is listening and responsive.  What's happening is that HTTP requests are being received by a misconfigured server daemon that is (among other things?) munging the URL and then throwing an error (two errors, actually).  

- Your current approach to diagnosis is a bit unfocused and scattered.  You can't compare "results" across tests conducted in fundamentally different ways; it's an "apples and oranges" kind of thing.  Correctly identifying your issue(s?) will require a more rigorous and systematic approach (with oddles of note-taking).

[Polybus]

Once again - thanks for taking the time to read and reply to my post.

To be blunt - my

current approach to diagnosis is a bit unfocused and scattered

simply because I don't really know what I'm doing - which I suppose is the real root of the problem..... I'm stumped - hence my questions to you guys.

I appreciate you taking the time to run your own little tests - and now that I know for sure that the Port is not blocked and Debian/ISP/Router/Anything else is not preventing this from working - the only other option is me - something I have done broke it - so I'll just have to go back to square one and try again....

Did the URL get changed to have /UI on the end for you too??

As for the code - sorry - you guys are teaching me quite a few things - and now I know what tl;dr means

I'll keep trying with the Web Server and see how it goes.

Just to try out the <code> tags - here is my 000-default.conf file:

Code: Select all

NameVirtualHost *

<VirtualHost *>
 ServerName airgunner.homenet.org
 ServerAlias http://www.airgunner.homenet.org
 DocumentRoot /var/www/html
 CustomLog /var/www/html/Logs/Airgunner.log combined
 ErrorLog /var/www/html/Logs/Airgunner.log
</VirtualHost>


<VirtualHost *>
 ServerName myshed.hiddencorner.org
 ServerAlias http://www.myshed.hiddencorner.org
 DocumentRoot /var/www/html
 CustomLog /var/www/html/Logs/MyShed.log combined
 ErrorLog /var/www/html/Logs/MyShed.log
</VirtualHost>

I'll report back with results

Polybus

[dasein]

...I don't really know what I'm doing

All the more reason to proceed systematically.

I'll just have to go back to square one and try again....

The smart approach is to start simple: don't try to run multiple VHosts, etc. Just focus on creating a single, working instance of Apache. Then add features/functions one at a time. (See "proceed systematically," above )

Did the URL get changed to have /UI on the end for you too??

Yes, hence my comment that URLs don't spontaneously change in transit. But Apache has at least two built-in ways to munge URLs.

[dilberts_left_nut]

It's more normal to have separate files for each vhost definition, rather than combining them as you have (which will work though).

The 'ServerAlias' directive is an alternate hostname that the vhost will respond to (and doesn't include "http://").

Both your vhost definitions point to the same DocumentRoot - presumably this isn't what you want.

[ralph.ronnquist]

You may also use the following command line to find the configuration file with the rewriting rules.

Code: Select all

# grep UI /etc/apache2/{sites,conf}-enabled/*.conf

If you would google 'apache2 "/UI"' you might well find advice regarding a couple of "My Cloud" services with detailed enough instructions about how to wrap those rewriting rules so as to avoid them being used for all URLs, but only for those directed to the admin interface pages. I did. Or, you might consider removing all "sites-enabled" links that you don't want to use.

As you should know, the directories "sites-enabled" and "sites-available" are used by apache2 in different ways. Namely, it uses whatever is in "sites-enabled", and nothing in "sites-available", except that which is linked from "sites-enabled". That's why "sites-enabled" only has links. That scheme is their way of providing optional configurations, and it also applies to "conf-enabled" and "conf-available".

How about visiting http://www.apachelounge.com/ ?

[Polybus]

Trying to act and think in a logical, methodical way I decided to start from square one.

Trashed my Debian Box....

Step 1: Installed Debian 8 (Jessie)
Step 2: Installed Apache2
Step 3: Port Forward Port 80 on my Router
(all these things seemed to go well with no errors)
Step 4: Access Default Apache Web Page via local IP address: 192.168.0.3 - Worked fine
Step 5: Access Default Apache Web Page via external IP address: Didn't work - and the URL got changed to append /UI to the end.

So at least now I know it is nothing that I have done wrong.

Clearly It is something I need to change - some setting somewhere....

Polybus

[kedaha]

Install ufw and then allow http and ssh; for example;

Code: Select all

# ufw allow ssh
# ufw allow 80/tcp

or

Code: Select all

# ufw allow http

But be sure to read documentation about ufw in man page or wherever so you know what you're doing.

Code: Select all

# ufw status
# ufw enable

[Polybus]

Firewall installed

Still getting the Forbidden error message though.

What is the /UI directory? And where should it be located in Debian - I can't find it.

Code: Select all

# grep UI /etc/apache2/{sites,conf}-enabled/*.conf
/etc/apache2/conf-enabled/localized-error-pages.conf:
#ErrorDocument 411 /error/HTTP_LENGTH_REQUIRED.html.var

I had a look through those files - doesn't appear to be anything that helps.

[dasein]

This is not a firewall issue

Apache. Really.

Good luck.

[ralph.ronnquist]

It appears your problem is with the network traffic path, and it appears that packets to your external IP 121.209.249.88 (DN airgunner.homenet.org) , port 80, do not get forwarded via your router as per your routing rule, but get captured somewhere on the way, and passed on to some other Apache server. That's one of the possible explanations to your reported experiences.

There are various ways you can test this, to confirm or refute. One of those would be to set up a different forwarding rule on the router, where the input port is something else, say 8888, while the target port remains as 80. Then you'd try accessing your server as "121.209.249.88:8888", to hopefully get a different response than the missing "/UI". Or not.

[dasein]

...captured somewhere on the way, and passed on to some other Apache server. That's one of the possible explanations to your reported experiences.

Ooooo. Very nice catch. You're right; some sort of quasi-MITM shenanigans explains everything.

It also explains why the earlier experiment with port 8080 made the problem disappear.

@OP: Listen to this man. He's definitely "got your back."

[dilberts_left_nut]

Firewall installed

Still getting the Forbidden error message though.

What is the /UI directory? And where should it be located in Debian - I can't find it.

Code: Select all

# grep UI /etc/apache2/{sites,conf}-enabled/*.conf
/etc/apache2/conf-enabled/localized-error-pages.conf:
#ErrorDocument 411 /error/HTTP_LENGTH_REQUIRED.html.var

I had a look through those files - doesn't appear to be anything that helps.

It's nothing to do with Debian, or apache - it's your site.

[Polybus]

Still going......

Given that I couldn't get past square 1 with Apache2 I thought I'd try something else.

I removed apache:

Code: Select all

apt-get purge apache2

And installed nginx

Code: Select all

apt-get install nginx

Once again - I could access the nginx default web page if I used my local IP 192.168.0.3

Once again I got the same "Forbidden" error when I tried to used the External IP address.

I have now removed nginx and put apache2 back on.

I must admit - I'm not sure what the MITM thing is all about - but I'll try the suggested test - but my Router won't allow me to map one port to a different one - it only allows me to forward from one port number to the same port number on a downstream box.

Polybus

[Polybus]

As always - thanks for you input - I really do appreciate it.

dilberts_left_nut

It's nothing to do with Debian, or apache - it's your site.

What do you mean by that?

At the moment - I have a clean install of Debian 8 and a clean install of apache2 - I still get the error just trying to see the default Apache Web Page.

How can my site have anything to do with that?

Polybus