Let’s speak frankly; we are a geek family and we love configuring machines and networks (especially tbowan if you want to know everything). Over time, and under the pretext of training and staying up to date with thos technologies, we have built our little infrastructure of which we take a little pride…

Two internet access boxes and two high availability firewalls to never disconnect from the great Internet. An Voice over IP network because it’s funny everything you can do with an IPBX. Two DMZs to host our extranets and intranet. A lab to devoping on our public sites and also test lots of stuff (which are not on the diagram). A domain controller and its file shares. Two physical servers to virtualize all these services. And of course, computers, phones and printers to work play.

Even if we bought all that refurbished (except the smartphones, we admit), this debauchery of e-stuffs requires a lot of energy to work…

• The two physical servers combined 1kW, or 8760 kWh per year; depending on the prices, that’s around 1800€ and 880kg of CO₂.
• Reducing virtualization on the smaller server has since dropped to 250W; i.e. 450€ and 220kg of CO₂ per year.

And of course, we wondered if we couldn’t go further and simplify all that. Then we thought you might be interested.

The website

Let’s start by looking at how we put our website online… Whether it’s the old dynamic version with grav, or the new static version, we were using until recently a whole dedicated infrastructure: a gitlab server to host the source code and orchestrate the CI/CD with a runner to compile and deploy to pre-production environments, and another to retrieve the result of the first and deploy it in production. And to measure our audience, we send the logs to matomo on its own virtual machine.

Let’s be honest. It’s actually more “beautiful” and “satisfying” to use all that devops-lean-agile stuff (we only need docker, Kubernetes and Ansible to be trendy) but seriously… for static sites!?

Pre-productions: Knowing that we systematically compile the site manually to test before publishing anything, these automatically provisioned platforms and environment had no use (we had never used them by the way).

The runner for the production: In reality, the compilation being done on the preproductions, it only did an rsync to the server. So we can very well do it ourselves when we want to publish what we have just compiled.

The Stats: Between their varying reliability, the ethical questions they raised (would we appreciate this kind of tracking in the real world?), and the negative impact they had on our creativity, we decided to do without it. No more matomo, nor goaccess or anything on our sites and we are no worse off.

We therefore only keep gitlab to centralize the source code and we launch the commands by hand when we need to publish. The production is in one command line:

make deploy

Telephony

Now let’s move on to our second toy, IP telephony and all its essential components…

Since we had two access boxes, we used the two corresponding land lines. These lines are analog, so we needed an analog gateway, and since it had two FXS ports, we had connected two analog telephones to it (including an old rotary socotel 😊). This gateway does not provide an IPBX server, we had to add a vitalpbx server, and while we were at it we flashed and added 4 IP-8815. At this stage, we had also added applications to turn our smartphones into SIP-phones.

Once all these little minions managed to talk to each other, we were able to move on to the next step and configure the IPBX: the presentation of the number to know who is calling us, ringtone groups to ring several phones during an incoming call, voicemail to receive messages by email when you pick up not, the blacklist to block a troublesome number and a turing test to prevent spam.

Let’s be honest, it’s true that it’s pretty cool to use but objectively, apart from the call robots, only one person was calling us on these land lines. And we almost never use them either.

We therefore asked our operator to switch any incoming calls directly to voicemail (and to send us the messages by email). We will call back those who left a message, the others are not important. Then we deleted everything (except smartphones we admit).

The network

Now that we have eliminated the production of websites and IP telephony, we can already see a little more clearly.

We therefore had ADSL access to compensate for fiber side failures and then two high availability routers (in case one of them has a problem). Next to the usual LAN, we had a public DMZ with an apache to share files with friends, a private DMZ for our intranet to get organized. As well as a lab that served as a test network, distributed over the two hypervisors with a dedicated cable. And of course VLANs to pool certain cables.

Let’s be honest, it’s sure that security is at the heart of the project. But do we really need all that?

ADSL: Statistically network failures have been rare enough to make the investment a waste. Worse, since it no longer manages IPv6, we should downgrade everything to IPv4 so that it can be used in the event of a breakdown (because otherwise the machines remain in IPv6 and cannot use this connection). And above all, we realized that disconnections are good and that we always have plenty to take care of while the operator restarts.

The pfSense: Statistically, high availability has never been useful in five years. And since to save electricity these two machines are virtualized on the same hypervisor, one wonders what kind of failure it covers…

The DMZs: The public DMZ site has only been used twice in 5 years and can therefore be deleted without regret. On the private DMZ side, our kanboard is used daily but it is not necessary to partition it to this point given our user base.

The Lab: Now that the runners and the pre-production environments are gone, no machine is permanently out there. For the others, either it is for legal and crime expertise and they are on their own completely isolated network (therefore outside the diagram), or they are for other purpose and can connect to the LAN for the duration of the test.

VLANs: if we remove all of the above we no longer need them at all (we finally have enough cards and cables), so the switch no longer needs any specific configuration.

And now ?

On the energy side, we have reduced by 5W per telephone (except the socotel which does not consume anything if it is not used), 10W for the gateway and 20W for the ADSL box. Removing the virtual machines hasn’t changed much on the hypervisor (the biggest consumption is for the hard disks) and I can’t assess how much we save by removing the orchestration of the CI/CD at gitlab.

Rounding it up a bit, let’s say we arrive at 500 kWh per year. We therefore reduced our bill by 100€ and 50 kg of CO₂. This is not negligible, but we feel that if the objective is to save the energy consumed and the carbon emitted, there are plenty of other more efficient actions to be taken.

In fact, this ecology story is above all a pretext to initiate a process of simplification and a more global awareness. While all of this stuff is very satisfying to acquire, install, configure, maintain, and use, let’s be honest: we rarely really need it.

Faced with all these fashionable things, let’s not be afraid to question their real usefulness. Let’s measure what they really give us (and not what we think they will give us) and compare it to what they really cost us (in Watts, in euros, in carbon, in time or whatever unit). Then let us have the courage to remove all the superfluous.

One little thing at a time, we free up space, we free our minds a little more and we finally breathe.

Licenses

The diagrams were made with yEd. A freeware developed (in java 😭) by yworks.

The diagram icons were designed by VRT System (licensed CC By SA). They are initially for libre office but pafnow offers a git repository where he converted them for yEd (his work is under the GPL v3 license).

I could mimick cisco and cie and tell you must send us a mail to ask for source code. But you could also simply replace the png extension by graphml in the addresses of the images to get the source code directly 😉 (btw we till love to get mail from our readers).