Kuba ist, was den Zugang zum Internet betrifft, immer noch ein Entwicklungsland. Für einige Jahre gab es nur Internet über Satellit, und das war entsprechend langsam. Mittlerweile gibt es Seekabel, was die Geschwindigkeit, Stabilität und Erreichbarkeit verbessert hat. Der Internetzugang in Kuba wird grundsätzlich vom staatlichen Anbieter ETECSA angeboten. Auch das Internet in Hotels läuft letztendlich darüber.
Continue reading "Internet Zugang in Kuba"
Every time Ansible runs a Playbook, the first step (by default) is gathering facts about the target system:
PLAY [all-systems]
TASK [Gathering Facts]
ok: [host1]
ok: [host2]
This step is implicit, and it is not necessary (but possible) to add the gather facts step to every Playbook. The module which retrieves all the information is "setup", and by default it tries to gather as much information about the target system as possible. When the "setup" task is added as an extra step in the Playbook, the information about the destination system is refreshed and updated:
tasks:
- name: Refresh destination information
setup:
That might be necessary when a Playbook changed vital system settings.
Gathering the facts is a time-consuming process, and for a short Playbook it is quite possible that this is the longest-running task. And it's repeated every time the Playbook runs.
Ansible provides Cache plugins which can store the gathered facts. If the system facts don't change between Playbook runs, this will greatly speed up the runtime of Playbooks. The facts cache can be stored in JSON files, in a Redis DB, in a Memcache, and a few other options. The simplest way, without additional tools required, is the "jsonfile" cache. Central implementations like Redis or Memcache allow multiple Ansible controller hosts to use the same facts cache, whereas local caches like "JSON" are only available on a single host, and every Ansible controller must build and maintain it's own cache.
Continue reading "Local cachíng of Ansible Facts"
A while ago I switched backups from "Duplicity" to "Restic". About time: I was using Duplicity for many years (I think I started using it around 2010, long before "Restic" became available) and it served me well. But recently I ran into more and more issues, especially with archives getting larger and larger. There is an 11 years old open bug in the Duplicity bugtracker, which describes a showstopper for backing up larger archives. And it doesn't look like this will be solved anytime soon. Therefore it was time for something new.
Since I'm rolling out my backups with Ansible, it was relatively easy to create a set of scripts for Restic which use almost the same infrastructure as the old Duplicity backups. That works as expected on all our laptops. But the Raspberry Pi, which does the fileserver backups, seem to had a problem. Backups took way longer than before, jumped from 30-60 minutes (depending on the amount of changes) to constantly around 10 hours.
After some investigation (means: --verbose --verbose --verbose debugging), it turns out that Restic identifies most of the files as new, even though they did not change at all. Some background information: the Raspberry mounts the QNAP fileserver using the SMB3 protocol. The "mount -t cifs" uses the "serverino" option, but apparently that is not enough to provide a stable inode number. And if the inode for a file changes, Restic assumes it is a new file.
On the bright side, because the content of the files do not change, the deduplication still works, and no additional content is added to the backup. The size of the backup does not increase. Still, Restic fetches all the data from the server, and that takes a long time.
Continue reading "Restic upgrade on Debian Buster"
About two years ago I blogged about how to create and renew Let's Encrypt certificates using Ansible. Back then, the "letsencrypt" module was State of the Art. This changed, and with all the Let's Encrypt API changes, the Ansible module changed quite a lot, and is now "acme_certificate". ACME stands for: Automatic Certificate Management Environment, and is the idea that every step along the way of creating and renewing certificates should be automated. No more manual creation of CSR (Certificate Signing Request), sending them per mail or manually uploading them to a CA website, enter your credit card details, and at some point get a mail back with the new signed certificate. All of this (except the credit card - you no longer need one) can be automated, and handled in a matter of seconds.
Time to write an updated blog post for the new module.
Continue reading "Create and renew Let's Encrypt certificates using Ansible - and the acme_certificate module"
The 7" Raspberry display in the kitchen is nice, but unfortunately by default the installation comes with a screensaver enabled. After a while, the display goes dark. No one wants to stare at a blank display, and touch the screen in order to see crucial information.
Continue reading "Disable screensaver for Raspberry Pi"
Our home automation got a nice 7" Raspberry display in the kitchen, showing the most relevant information (like temperature, weather, washing machine, dryer ect) on a dedicated screen. Quite handy, especially the temperature, and the one-click stop to the weather forecast.
While installing the Pi and setting everything up, I stumbled over the Icons which LXDE by default shows on the desktop. Not necessary, I want them removed. All I want on the desktop is the browser icon which directly goes to the HABpanel.
The reason is simple: if the Pi starts up, but the browser for unknown reasons doesn't come up, I don't want anyone to be confused by additional icons on the desktop. After all, usually the LXDE desktop is not seen by default.
Hugo is a static templating system. It is (mainly) used to deploy websites/blogs which don't have and need dynamic content. The content of all pages is pre-generated, and the webserver delivers files from disk (or rather from cache, once files are loaded into memory). This approach allows for extremely fast websites, as no dynamic content is generated on every request.
While I know Hugo from work, I haven't really used it for private projects - until recently. I have started a new project where I present interviews with people behind the PostgreSQL Project - and this is perfect for a static website. Interviews don't change, once published.
There was just a little problem: every interview must be approved by the interviewed person. This requires a full preview, but one which does not show up on the main website, or the Sitemap, or the RSS feed. By default, even drafts show up in Sitemap and the RSS feed in Hugo.
Continue reading "Public previews in Hugo"
SCALE 18x is taking place during the next week, in Pasadena, CA. I will present a 3 hours workshop about PostgreSQL data types on Friday morning.
In order to attend, you need a SCALE registration. No special knowledge is required for the workshop. If you want to follow the exercises, you need a PostgreSQL database installed on your computer.
See you there!