This is a follow-up to Caleb Doxsey’s great article, Kubernetes: The Surprisingly Affordable Platform for Personal Projects. I think Caleb is absolutely right in his description of Kubernetes as a great platform even for small projects that would usually end up in “a small VPS somewhere”, especially if you already have experience with k8s. I’ve been using Kubernetes on AWS EC2 instances at work, and I was keen on trying Google’s fully-managed experience in GKE, so I followed Caleb’s steps and created my own cluster.
We recently got bitten by an innocent and standards-compliant improvement in Azure AD that effectively broke our OIDC-based authentication system for Kubernetes 1.9.x clusters. OIDC, short for OpenID Connect, is a convenient way of providing authentication in Kubernetes. The flow roughly goes as follows: User gets a JWT token from its OIDC provider (Azure AD) User sends this token to Kubernetes alongside its request Kubernetes validates this token by verifying the JWT signature against the provider’s public key Kubernetes lets the authenticated request through This theoretically ensures Kubernetes doesn’t need to “phone home” by calling the authN provider for every request, as happens for example under the Webhook Token authentication mode.
I recently read Caleb Doxsey’s article on how suprisingly affordable Kubernetes is for personal projects and got inspired to spin it up for myself. I’m familiar with Kubernetes at work, but we run our clusters on top of EC2 instances in AWS, and I’ve always been curious about how a fully hosted Kubernetes offering like GKE would fare. Setting up Kubernetes on GKE itself following Caleb’s directions was pretty straightforward (well… For the most part – but that’s another subject for another post), and I ended up with an empty “hello” page from nginx.
Programming · UNIX
I’ve been using Radicale as a contacts / calendar server (CardDAV / DalDAV) for some time now, and it worked flawlessly across macOS and Windows Phone for contacts and calendars. However, I recently got an iPhone and synchronising calendars from Radicale just crashed the iPhone calendar app. It worked fine some of the time, but most times it just crashed, which is not great. Therefore, I went on the search for a better self-hosted calendaring server.
Last week I needed to change my defective French SIM card, from Free (who as an aside are an awesome ISP and equally good mobile provider). I happened to be in Paris so I decided to go to the Free shop, as I thought it’d be easier then getting a new SIM card send to my address on file (my parent’s address in France) given I now live in the UK.
OVH emailed me a few weeks back telling me that my shared database for the plan that powers uponmyshoulder.com was approaching its (huge!) quota of 25MB, and then again last week to tell me that this time, the quota was reached. Once you reach the quota, the DB is placed in read-only mode, although SQL DELETE commands do go through correctly, as we’ll see later. So my first instinct was to see what was wrong, by going into the PhpMyAdmin that OVH gives to each shared DB owner.
A few days ago, a colleague was telling me about a project where she needs to implement a crypto scheme from an external vendor in order to talk to their API over HTTP. For complicated (and probably wrong) reasons, they decided to eschew TLS and develop their own system instead, relying on DES –not even triple DES! Basic DES, the one from the ‘70s that is horribly insecure today– and RC4, which isn’t great either.
Programming rails · ruby · upgrade
In 2011 I wrote a small Rails app in order to learn Ruby better and see what all the fuss was about â this was Antipodes, a website that shows you the antipodes of a given point or country/state using google maps. I built it using the latest and greatest version of Rails available at the time, which was 3.2. It has since fell to various security issues and has been superseded by newest version, and is currently unsupported.
So, remaildr.com had been in a pretty sorry state for a couple of months now, and I kept thinking I should go have a look into it and get to the bottom of the issue. And the bottom of the issue was the 6000 spam emails sitting in the inbox, making the server crash at startup. They’re now deleted, and everything is back up and happy. I’m currently thinking about different monitoring options, but given it’s all email-based, no solution that I know of seem overly practical to me.
“So, the tests sometimes fail inexplicably” is a sentence you probably hear pretty often if you’re running any type of full-stack, browser-driven integration tests over a large-enough code base, especially when customising on top of an existing product. Today’s instance was puzzling at first - the tests would sometimes fail to log in at all. That is, open the login page, fill in the username and password, wait until the URL change and assert that we’re now on the dashboard - nope, failure.