Surprising Revelation about the Apache Listening IPs

One of the details in my Apache configuration which I had placed emphasis on, was that this Web-server is supposed to listen on all IPv4 as well as all IPv6 interfaces, on the host-machine I name ‘Phoenix’. And so in the configuration file ‘/etc/apache2/ports.conf‘, I have set up so:

 


# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf

Listen 80

<IfModule ssl_module>
        Listen 443
</IfModule>

<IfModule mod_gnutls.c>
        Listen 443
</IfModule>

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


 

And, in the file ‘sites-enabled/000-default.conf‘ I have stated:

 


<VirtualHost *:80>
        # The ServerName directive sets the request scheme, hostname and port that
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.
        #ServerName www.example.com

        ServerAdmin admin@dirkmittler.homeip.net


 

But, when I run the command ‘netstat‘, what that command seems to reveal is:

 


dirk@Phoenix:~$ netstat -l --tcp --numeric | grep 80
tcp6       0      0 :::80                   :::*                    LISTEN
dirk@Phoenix:~$ netstat -l --tcp --numeric | grep 443
tcp6       0      0 :::443                  :::*                    LISTEN
dirk@Phoenix:~$


 

What I expect to see, is instead:

 


dirk@Phoenix:~$ netstat -l --tcp --numeric | grep 80
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp6       0      0 :::80                   :::*                    LISTEN
dirk@Phoenix:~$ netstat -l --tcp --numeric | grep 443
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN
tcp6       0      0 :::443                  :::*                    LISTEN
dirk@Phoenix:~$


 

Yet, contrarily to what catastrophic expectations might suggest, I find that my site is accessible to IPv4 addresses to begin with. Not only that, but I routinely use the internal, IPv4 loopback-address, and the URL:

 



http://127.0.1.1/blog/


 

To access my own blog. The surprising fact about this setup, is that it still works, and I could come up with some creative ideas, about why this has been working all along.

  • The router could be forwarding all the IPv4 traffic from the WAN, to a LAN-specific IPv6 address belonging to my host-machine,
  • The way the kernel works could be such, that if any server is listening on ‘:::80‘, it is also automatically listening on ‘0.0.0.0:80‘.

My actual router settings only show my host as having an IPv4, LAN address.

I don’t understand it, but as long as this has not been creating any malfunctions, I’m not going to dig deeper into the subject for now. If indeed, my server was no longer listening on any IPv4 WAN addresses, I would have obtained notifications to that effect by now.

Dirk

(Edit : )

This has just been confirmed as the standard behavior of Apache (to use just one socket), as described in this external BB posting.

 

Routine PHP Update This Morning

This morning, the computer that hosts my Web-site received a routine update to its PHP 5 interpreter – i.e. to some of the modules of its PHP 5 system – which also triggered a routine restart of the Apache server processes. This has taken place without causing the slightest disruption to my site.

What most Linux-based services do, during a log-rotation, is also to restart, so that after the log-files have been renamed, the services obtain a new file-handle as well, and so that the actual writing of log data resumes with a newly-created log-file. Apache tends to be atypical, in that one of its available commands is to reload its configuration and/or its log-files. Thus, usually, the main Apache service just keeps running.

Technically, this morning, the Apache server was gone for two seconds. But, if an average reader was to find that this interfered with his browsing, he would have been able to fix that, just by clicking on the same URL a second time.

Also, my blog consists of PHP scripts, which every HTTP request executes independently of the other requests. Persistence is achieved by browser-scripts, and by a MySQL database which the server-scripts access. So there is also no loss of persistence, of my site, arising from an Apache server restart.

Dirk

Continue reading Routine PHP Update This Morning

Routine MySQL Update Successful Today

I use a system for updating my packages, which is named ‘unattended-upgrades’, and which I have blogged about before Here.

This morning, that system updated my MySQL server, which is also important to this blog, because these blog entries are in fact stored in a MySQL database. The way my blog generally works, each HTTP request causes a PHP script to be executed independently on the Apache server, and the PHP extensions I have installed, include a MySQL client. This part of the PHP scripts fetches the blog content, while other parts of the scripts format it as HTML, according to the Theme which I have chosen to install some time ago.

The individual blog entries do not actually form separate files or folders on my Web-site.

Also, it is an explicit WordPress Plug-In, which tries to retrieve the already-formed HTML from my server cache, If the HTML being requested has been cached. That Plug-In is named ‘Memcached Is Your Friend‘.

The fact that my blog still displays properly, indicates that the MySQL database is operating normally. After the upgrade, the scripts also restarted this server briefly. And, the fact that this server has been restarted, does not affect the cache, nor the speed of the blog, because the ‘memcached’ daemon is a separate process which did not receive any update or restart.

Dirk