For WebPi, the computer that would become responsible for the connection between my local area network and the world wide internet, an RPi3 was chosen. The idea was to install a renowned web server software package on it, Apache.
The first step is installing the operating system, Raspbian. Since the machine would run without console, the light version should be sufficient. Any missing packages can be added anyhow. At the time of writing, the latest version is Stretch. That proved not to be fully stable yet for the subsequent steps, so I chose the previous version Jessie (2017-04-10). Installation runs smoothly and after changing the host name, allowing SSH and setting the time zone the machine is ready for use. Important issue is here to set a new password for the standard user, pi, otherwise the vulnerability of the web site and subsequently the whole local area network will be at stake.
There are quite a few descriptions available on the internet to install Apache, I chose the one that was clearly aimed at the kind of RPi I was using: “How to Make a Raspberry Pi Webserver” by Alok Naushad. It is intended for RPi2 but appears to work as well for the RPi3 with Jessie Lite. All steps were followed until setting a static IP-address. In my router, a Fritz!Box 7581, there is no need for that, as it has a primitive DNS for the connections within the LAN, e.g. WebPi.fritz.box . This will keep track of a correct IP-address. The router also has the option to fix the IP address to the MAC address of the device but that appeared unreliable. Furthermore, my internet provider already has a host name on the world wide web set for me so there is also no need for that step. Although this host name is a bit clumsy as it contains the whole IP-address it can be used. In practice, the user should not need to use this host name but it will be used for a dynamic link to the web site(s).
An important issue is the security of the web site as it provides the access from the world outside to the local area network. Again, there are many descriptions – right and wrong – that describe how to do this. One that, in my humble opinion, is very well written and stands out for clarity is the answer written by Thomas Ward in response to problems associated with this issue. It clearly describes how to set ownership of the various folders as are accessible from outside.
The second step involves setting up the Apache web server so that it will pass on html-information from the various other RPis in the local area network, such as control of the central heating system, solar heaters, etc. to the outside world without compromising the machines or the network. Of course the web site of Apache has a description, albeit a bit brief. A better description was by LeaseWeb Labs, but actually a combination of various examples finally gave the hint. The essence is to set up the reverse proxy virtual host configuration in “/etc/apache2/sites-available/yourwebsite-proxy.conf”. Mine essentially looks like
<VirtualHost *:80> ServerName www.yourwebsite.com DocumentRoot /var/www/html ProxyPreserveHost On ProxyRequests off ProxyPass /pi1 http://RPi1.fritz.box:8083 ProxyPassReverse /pi1 http://RPi1.fritz.box:8083 ProxyPass /pi2/ http://RPi2.fritz.box/~pi/ ProxyPassReverse /pi2/ http://RPi2.fritz.box/~pi/ </VirtualHost>
From the web, the machines are now available as www.yourwebsite.nl/pi1 etc. The ServerName is the one provided by my provider. the other names come from the router and host name settings. There are two examples, one where a port is different, 8083, from the standard 80 and one where the html-information is in another directory. One remark though: it is possible to replace the host names by their IP-addresses; this is extremely helpful while testing.
Finally, there are free services that test the security of the web site. I tried ScanMyServer and it gave 60%; most problems are associated with the older version of Apache but there is no more recent version available for RPi or one has to do the compiling and further processing oneself. For the time being good enough.