It’s been three and a half years since the last post. But nothing much changed in our infrastructure and apparently those are the only posts that actually get published here. Now its time to change everything up again.
In the last three some years the container landscape has changed considerably again. From pure docker containers to orchestration environments that put full blown enterprise software to shame. All in the name of availability. Might as well also jump on that ship. Even if not full-blown kubernetes.
Something I wanted to try out since I set up the blog as hugo static site was the automatic testing and deployment straight from the git to our webserver. As we are not using any of the common hosts for static sites, because why would we when we have a server at our disposal, it was a interesting to find a solution without using third-party services.
Our current setup is a VPS running a nginx and a docker environment for everything we don’t quite trust and or want to run on bare metal. Two of those docker containers are Gogs and Drone CI, which work miraculously well together.
Let’s Encrypt was released to the public on the 6th of December last year and has been a huge boon to the worldwide adoption of SSL/TLS Encrpytion for admins who prefer their own little site or mail server to huge sites like Google and the inherit indexing and spying by basically everyone.
Up until now SSL Certificates were either expensive, not quite trustworthy or generally not accepted in any browser or mail client. Let’s Encrypt certificates on the other hand are easily requested, verified and installed on any machine while also being free and trusted by any software thanks to a cross sign.
Let’s Encrypt offers a rather complex python script which helps setting up the certificates for different webservers and alike but almost always requires a standard setup to work. And anyone who has set more than a few basic settings is out of luck and has to do it manually, which is rather annoying considering the very short certificate lifetime of three months.
Alternative tools to the rescue. There is now already a pletora of different tools implementing the ACME protocol ranging from little bash scripts to full blown python applications. Many of these will do the job just fine as does the official client for that matter. I decided to go with acmetool a great little tool written in Go.
In addition to the common webroot, listen and manual mode acmetool also offers
DNS verification and a proxy mode, basically webroot without the need for
filesystem access. Due to the fast iteration on the tool it also already
supports the signing of ECDSA certificates in addition to the standard RSA
ones.
And once again a new blog software. Well not as much blog software as just a static site generator. I went with hugo as it seemed to be of reasonable complexity and allowed me to port over the blog theme in a minimal amount of time. Whole blog and the content are now maintained in the old microblog git.
All old links should still work as before. e.g. /entry/1/ or /page/2/. In addition code blocks now support syntax highlighting for all of pygments supported languages, which are quite numerous. Including most programming and config file syntaxes. Which is quite important for a coding and administration oriented blog.
//go example
import "fmt"
func main() {
fmt.Println("Hello World")
}server {
listen [::]:80 ipv6only=off;
server_name server.name.nic;
location / {
add_header Strict-Transport-Security max-age=15768000;
return 301 https://$server_name$request_uri;
}
}The old famfam icon set was replaced by a web font with just a minimal set of glyphs we actually need, thanks to fontello. The Icons come from Font Awesome and Entypo I’ll do an inlined version of the SVG font version later to remove absolutely all binary traffic from the blog.
For one of my projects I’m making heavy use of I²C devices. For development it would be nice to connect them to my notebook and develop and debug the sourcecode natively.
Luckily I remembered that all common display connection standards (VGA, HDMI, DVI) have an I²C control channel. In the linux kernel these pins are exported as I²C device by the graphic card driver. For example my intel driver exports 8 I²C devices.
So the only hardware needed to use an I²C device on my notebook is a cheap VGA cable. After cutting it in half we have two I²C adapters. I decided to create one cable for 5V I²C devices. This one is already done after cutting the cable in half. I soldered a jumper wire connector on the four needed wires and removed the others.