Routine Update to my Apache Server Today

As I have written many times, I host my Web-site and blog on my own server, from home. The actual Web-server is a complex piece of software called ‘‘.

Today, a set of updates was pushed through the Debian repositories, specifically to this server. This update meant that I was briefly offline from about 20h15 until 20h17.

My site is up again, and this time around, there was never any need for me to restart my caching daemon, for which reason the response of my server to the routine queries by readers should not be slowed down.




How DynDNS Works

You could face the following problem. You could be intending to set up your own Web-server, for it to be visible to the public, on your home computer. You could have an ISP, which assigns and reassigns you IP addresses which they own, and which therefore, you do not own as static IP addresses.

You could have taken the step of installing a Web-server on your machine, as well as to do “Port Forwarding” on your router, meaning that the router listens on Port 80 on the WAN, and forwards all incoming connection attempts to that port, to the host machine on your LAN.

You would now have the problem that your Web-site needs a URL, with a domain name, which anybody on the Internet can use, to access your Web-server. After all, your IP address can change, and it would not be practical to update people directly, with your new IP addresses.

There is a freemium service on the Web, which would be able to help you with that problem. When we give our Web-browsers a URL with a domain-name, the browser accesses a public DNS server, to look up the IP address of the Web-site, associated with that domain name. “DynDNS” offers a specialty service, by which its members have ‘a Dynamic DNS service’. Its members install an update client on their machines, and reserve a domain-name with DynDNS, which is to be associated with their potentially changing IP address, continually.

Whenever the ISP changes our IP address, the update client on our computers detects this, and logs in to the DynDNS account we have. Then, the update client notifies DynDNS of the new IP address, and DynDNS has the connections with the public network of DNS servers, to propagate the new IP address. It is the responsibility of DynDNS, that requests for domain-names which its members hold, from Web-browsers, be answered with your updated IP address.

The Web-browser is never notified in any way that your IP address or domain name are different from ones with static IP addresses, it simply receives the IP address from its subscribed DNS server, that is your WAN address, and connects to it.

Further, if you have registered a host-name, as they call it, with DynDNS, there is no specific reason why you would need to listen on Port 80 always. Your purpose could be to make other services publicly-accessible, which listen on other port numbers, which you have instructed your router to forward to some machine on your LAN.

This is the arrangement by which I host my own Web-site, and additional services, from my home computer.


dirk@Phoenix:~$ host has address has IPv6 address 2001:0:53aa:64c:d1:32e7:b9cc:d8a8 mail is handled by 10




I use, not, for most of what I subscribe to.

I think it is a bit my own fault, for not explaining in a clear way, what the difference is between and . is a specialized blog-hosting site, on which members can write their blogs, but which runs on professionally-maintained servers, by .

But, the people behind this service have also made the PHP Scripts available for free, that run on the server, and that cause the HTML to be generated, which causes proper WordPress blogs to appear on the browser of the reader. People may download those, and may upload them to whatever Web-server they have access to, provided that that Web-hosting service, also supports the running of server-side scripts, by the Web-hosting service members. Some Web-hosting services put a lot of restrictions on what their members may publish, such as static HTML Pages only, or such as no access to any MySQL server, the latter of which uses actually to store the blogs.

And so, because this support-factor is the main part of the expenses incurred by, I will assume that sharing their core scripts poses no perceived threat to them. Their main expense is not, that core set of PHP Scripts. But, because an individual may have problems setting all this up as well, there is an associated Web-site, namely, where independently-hosted WordPress users can go for tech support, and to download plug-ins.

Continue reading I use, not, for most of what I subscribe to.

eGroupWare Installed

Under Linux, or on several Web-server installations, there exists a Web-application, which is written in PHP scripts, named “eGroupWare”. This is particularly easy to install under Debian / Linux.

Its purpose to to allow an administrative user to grant numerous non-administrative users access to tools, which allow the coordination of projects, timetables, and the booking of (any, symbolized) resources. It allows for notifications to be sent out, as well as for some socializing to take place between registered users. It also allows for its own WiKi to be created, and a custom Web-page. It is extensible through numerous apps that exist within.

Most importantly, each user has complex Access Control Lists, which control in great detail what aspects of the functioning of objects he is allowed to decide. Obviously, the main administrative user has his ACLs set to allow access to everything, including the editing of the ACLs themselves.

I have installed and started eGroupWare on this server. But my great failing in this is, that currently, I am also the only user, even though I could invite people to visit and receive accounts from me, and to collaborate through this site.

Without an actual user population, this is just a fun game to play for me, in administering my Web-site in general.


(Edit 11/05/2016 : ) It is a fact that while I was installing eGroupWare on this machine, because the same machine also hosts my blog, my blog was offline for a few minutes, around 15h08 November 3. This happened in fact, because I was making ad-hoc changes to a suggested configuration script belonging to the Debian-packaged version of eGroupWare, in hopes of making this Web-application more secure. These changes of mine prevented me from restarting the Apache server, until I edited them back out. And so, by 15h27 that same night, my server was back up.

I had assumed that nobody would notice, as this outage really only lasted a few minutes, and I was not experiencing heavy traffic at that time.

And as it turned out, there was a more-correct way to change the configuration, than the method I had been trying – to edit that file.