The sed(1) stream editor is one of the most powerful tools from the classic Unix tool box. It is a close cousin to the ed(1) command line editor and a descendant of the ex(1) editor, the command line mode of vi(1). In this article I’ll show a few idioms that I frequently use in practice.
In many applications it’s important to react to failed logins and other security-critical events, for example to log the failed login attempt to a file or to display a captcha after repeated failures. Spring-based applications come with a simple mechanism to access this kind of information using Application Events.
In the old days, many Java APIs were fairly low level and pretty generic. You often had to explicitly select a concrete implementation, provide lots of parameters, and generally needed to know how things worked. This has changed in recent years – modern APIs provide lots of convenience functionality that raises the level of abstraction and increases productivity. I like this as much as anybody else, but unfortunately it can also lead to subtle bugs.
The other day, I was trying to build a simple batch upload interface for a Java web application running Spring Boot with Spring MVC on Apache Tomcat. But when I tried reading the InputStream in my controller, it was always empty. Fortunately, this turned out to be quite easy to fix.
On Linux/Unix systems, there’s occasionally the need to check whether a process is running. Some people use it for simple status checks or when building their own lifecycle scripts for startup and shutdown. I don’t think it’s a particularly good practice these days because all of this can be achieved with tools like systemd, supervisord, JavaServiceWrapper, or even Docker. But if you can’t use these for some reason, read on.
In my article on unattended upgrades I described how to set up an Ubuntu system to install security upgrades automatically. This is convenient for small setups, but in an enterprise environment you typically want to perform some QA before applying the change. A better solution is to have your monitoring system generate an alert if security upgrades are available. In this article, we’re going to build an Icinga plugin to hook into your monitoring/alerting system.
Thanks to Ubuntu 16.04 which includes a fairly recent Nginx version, I have now enabled HTTP/2 on my private server. Of course, I also wanted to verify whether my configuration change had any effect – after all, there is no visible change (except for a little speed-up). One option that works really well is the HTTP/2 and SPDY indicator Chrome extension. But after some playing around with Python, I also found an easy way to detect HTTP/2 support using just Python’s standard library.
