Forum Moderators: phranque

Message Too Old, No Replies

CustomLog on Apache does not work and one web site fails

one works, the others don't

         

dstiles

8:43 pm on Mar 14, 2019 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



As an experiment I've redesigned two small web sites from IIS to PHP to work on linux (Mint) apache. The two sites work fine on a local Manjaro test server. Moving them to an existing online server, I thought, would be easy. Hmm. That was two weeks ago (note: only working a few hours a day!).

Server is Apache/2.4.1.18 (ubuntu) running on Linux Mint 18.1 (Serena) (on Windows Hyper_V if it matters). Test server is Manjaro running apache/2.4.38.

All sites are in /srv with permissions www-data:www-data.

The original HTTPS web site on the online server (squirrelmail for my mail server) works fine, with error and custom server logs.

Neither of the two new ones writes logs at all.

One of the sites works in a local browser, the other does not. Neither is yet online. Both are HTTPS sites with no certificate.

As far as I can see all three sites are virtually the same.

Original site has external IP and DNS. New sites assigned VirtualHost *:443 and given 127.0.0.1 in hosts file.

.htaccess files same for all three.

Neither of the new sites generates session data. Original site - no idea where it's kept. Do I need to put any of the mods-available session*.load files into mods-enable? The test server runs a slightly different version of apache (httpd) which does not enable things this way so no example to copy, but there are no session* modules enabled with a LoadModule statement.

VirtualHost for the new working site is (no SSL defined)...

<VirtualHost *:443>
ServerAdmin alert@mymail.domain
DocumentRoot /srv/brisacu
ServerName www.example.com
ServerAlias example.com
<Directory "/">
AllowOverride None
Require all denied
</Directory>
<Directory "/srv/brisacu">
DirectoryIndex index.php
AllowOverride All
Require all granted
</Directory>
CustomLog ${APACHE_LOG_DIR}/brisacu/access.log combined env=!dontlog
</VirtualHost>

I've tried commenting out the two <directory> blocks (which are not in the original working one) on both new web sites.

I've searched the web for various topics to do with this and found nothing that makes a difference. Can anyone help, please?

ClosedForLunch

9:35 pm on Mar 14, 2019 (gmt 0)

5+ Year Member Top Contributors Of The Month



Both are HTTPS sites with no certificate


The sites won't be served over HTTPS until they have a certificate.

First, get the sites working properly on port 80.

dstiles

10:30 pm on Mar 14, 2019 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



One of them IS being served. They wouldn't work on 80 either and the logs are still the problem.

The error for the failed site is "connection refused" on port 80. I could believe that would not be logged but the working site isn't logged either. For 443 the failed site returns Unexpected TLS packet.

phranque

12:10 am on Mar 15, 2019 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



The error for the failed site is "connection refused" on port 80. I could believe that would not be logged but the working site isn't logged either. For 443 the failed site returns Unexpected TLS packet.

since these messages obviously indicate the connection and secure handshake failed, i would NOT expect to see any action by the server.

dstiles

10:39 am on Mar 15, 2019 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



But the other site works - just no logging or session info. Can we concentrate on that one, perhaps? Then maybe the other one will make sense.

phranque

11:00 am on Mar 15, 2019 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



But the other site works - just no logging or session info. Can we concentrate on that one, perhaps?

describe the site that works without logging.
(impossible to determine from rereading your posts)

dstiles

6:28 pm on Mar 15, 2019 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



VirtualHost as detailed above. Worked fine on Manjaro/httpd server but took a while to get working under Mint/apache (details as above).

Posting here and getting a few suggestions has clarified what was happening.

I was confused by the working site: the reason that was not logging was that it is working from its original online server (IIS) with its own certificate. Changing the conditions to use the local 127 ip was too late: the cache had the online site and hung onto it. My next move now, after getting letsencrypt to provide a real certificate, is to switch IP in DNS to point to the new site - and then sort out how to block unwanted bots etc, which is half-done for the squirrel.

All of this confused me into thinking the local server was working on at least one site with no certificate attached. ClosedForLunch was correct in that; I should have taken more notice. Sorry. :(

Now that I have a self-signed cert for the failing site it works locally. Now to provide a real certificate and set up DNS accordingly.

As I said, posting here helped put things into perspective after having to make several changes from the newer Manjaro to the older Mint server. Many thanks for all your tolerance and suggestions. :)