Tag: Apache

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