Commit it!

I have to fix a bug and finally find the code where everything goes south. And immediately I ask myself: “Why is that written in this way? I mean: It *has* to break!”

Sounds familiar?

Luckily I am not editing files via FTP directly on a server but am in a project that uses version control. Which allows me to check who and when this line was last changed. Which will provide me with some information on whom to ask about why that line was written in that specific way.

And guess what? That line was last changed 5 years ago by a then-coworker that has since left.

But at least we have the commit-message that was left by that coworker.

And, yeah! You guessed it: It’s not helpful: “Fixed bug”…

If you are lucky, it contains a link to an issue. But: Yeah! 3 years ago the team changed their issue-tracker and they didn’t bother to move over closed tickets…

So let me talk a bit about what It takes to

Write a good Commit Message

Continue reading Commit it!

Deploy using git archive

When deploying code I by now almost always use git archive for that no matter whether that is library code or actually product code that gets deployed onto a (web)server.

Recently I had a chat with someone that so far hadn’t heard of that so I realized perhaps it’s time to write about it.

What is it

git archive is a tool that exports the content of a git repository into an archive file. But while doing so it also uses information in a .gitattributes file to decide whether to include a file into the archive or not and also whether to modify a file.

A lot of people already know about the .gitattributes file as it makes sure that certain files are removed from the archive that is created by github when creating a release.

The documentation for .gitattributes has (amongst a huge number of other information and awesome things that can be done via that file – but that’s for some other time) a special part about creating archives that talks about two attributes:

Continue reading Deploy using git archive

ICU in PHP-images from Docker-Hub

Recently I was preparing a talk for the fwdays PHP in Kyiv. A talk about internationalization. And gues what: One of the parts of internationalization is: Timezones. Yes, I know, I am fond of them and all but that’s not what this is going to be about.

In the talk I am showing how to propperly render a datetime for a given locale in a given timezone using the IntlDateFormatter. As the talk will be in Kyiv I thought it’s only fair to use the Europe/Kyiv timezone.

The timezone Europe/Kyiv is a rather new one and was introduced in 2022 when the former timezone Europe/Kiev was renamed to Europe/Kyiv as that by now was the more widely used international spelling of the Ukrainian capital (Thank you, Vladimir, for making the world aware that the russian transcription isn’t the correct one!!)

So I added my example and thought I’d better run it through a current PHP-Version to check wether my code is actually sane and runs.

As the ICU-extension is not by default part of the images on docker-hub I created this little Dockerfile to get an image with the ICU extension:

FROM php:8.3-rc-fpm
MAINTAINER andreas@stella-maris.solutions

RUN apt-get update \
 && apt-get install -y libicu-dev \
 && docker-php-ext-configure intl --enable-intl \
 && docker-php-ext-install -j$(nproc) intl \

It’s using the latest PHP 8.3 image and adds the ICU extension. Yes! it’s not slim, there is cleanup missing etc but that is not the point here, it’s just to demonstrate something.

I created a container via docker build -t icutest .

So now let’s check the ICU version.

$ docker run icutest bash -c "php -i | grep -i icu"
ICU version => 72.1
ICU Data version => 72.1
ICU TZData version => 2022e
ICU Unicode version => 15.0
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Wait! ICU TZData version => 2022e?

As https://data.iana.org/time-zones/tzdb-2022e/ shows, that’s from October 2022! What the heck?

What’s the timezone-DB version that PHPs DateTime lib uses?

$ docker run icutest bash -c "php -i | grep -i Olson"
"Olson" Timezone Database Version => 2024.1

Oh! Great!

So we learn different things here:

PHP libraries use separate timezone-data

The DateTime extension (you know: date, DateTimeImmutable etc) use the latest timezone-db version available at compile time of the PHP-library. (Thank you Derick for that!) One of the reasons why one should stay up-to-date with PHP-versions. If that’s not possible, you can use the timezonedb pecl-package.

But the Intl Extension – as it is a wrapper around the ICU4C library – uses it’s own timezone database. Also the last one available at release time of the library.

So why do we have a mismatch there? Because at the time of writing the current release of ICU is 75.1 – and not 72.1 as the output of PHP-info shows.

The issue I am running into here is that I installed the libicu-dev package when building the container. And that installs the – by now outdated – ICU data as debian/ubuntu do not update those packages to higher major versions. An upgrade to a higher major version of a lib only happens when updating Debian/Ubuntu to a higher Major.

Despite the fact that neither Debian/Ubuntu nor ICU are using Semantic Versioning…

Don’t come with a problem!

OK. I now had analyzed the problem (my main problem was that the code didn’t run because I was using the bullseye image and not the bookworm one which is on an even older timezone DB that didn’t know Europe/Kyiv as it was from 2019…).

How to fix it?

Well, the solution seems simple: Update the ICU extension…

So I fiddled a bit around and updated another library to handle the non-semver versioning that ICU uses and ended up with this somewhat more complex Dockerfile

What happens here

Let’s shortly go through the dockerfile

In line 5 I install stuff that is necessary for compiling code as I will need to do that with the ICU lib.

In line 6 I download the latest version of the ICU4C library. It uses getlatestassets that will make sure that we will always get the latest relerased version. Sadly the github API doesn’t provide a way to do that out of the box, so I have to use getlatestassets.com here. To make handling easier I store the archive in a file consitently named icu.tgz

The next steps are to extract the archive and change the working directory.

In line 9 I set the LIBDIR variable from what is set for PHP so that the ICU library will afterwards be placed in the right folder where PHP expects all the libs to be. Otherwise I get some odd runtime errors when PHP tries to load a library that is not available.

In line 10 I tell the config script where to put that library file and then it’s make and make install to build and install the library.

Afterwards I remove the archive file. In a production image I’d do some more cleanup here to get the imagesize down.

After that it’s the same commands that I already used in the old Dockerfile, just this time the “correct” library-version will be used.

So let’s create and check the container:

Great! Now we have a current version of ICU with a rather recent version of the timezone-database. And also all the other awesome things that are part of a new ICU version! Like new translations, new emojis etc.

What did I learn?

Whenever I am using the Intl extension in PHP I will now make sure that the PHP-Version I am using is actually using the latest available ICU-library as one can not take for granted that that is delivered by default.

In essence I should probably check that for every library I use, but most of them do not contain such volatile information as the (constantly changing) timezone DB. And usually fixes for critical issues are ported to the respective libraries by the distros. But that requires me to keep on a distro-version that gets these patches!

So in essence the main thing is – as always – Stay up to date

Outlook.com and self-hosted email-servers

I am running my own email-server for some time now. It started out of curiosity and went live after my hosting-provider got hacked several times and I then was sick of it. It’s not as hard as people make one believe when it’s just for a few email-addresses. Still I check the server every now and then.

The setup and what I do in between might be a separate blogpost (or actually several) but today I just want to write about one thing that nagged me really deeply and where the solution was pretty easy. I had to think about it when Rob Allen today wrote about DKIM, SPF and DMARK.

What happened

Whenever I wanted to send an email to an outlook.com (or outlook.de or hotmail.com) address, that email just didn’t get through. It was considered spam and I received a nice feedback in the mailserver-log:

Continue reading Outlook.com and self-hosted email-servers