BigSmoke

Smokes your problems, coughs fresh air.

Author: halfgaar (Page 1 of 26)

Halfgaar is Wiebe. Wiebe is a contributing author on this weblog. He also has a lot of stuff (such as long, in-depth articles) on his personal website.

Wiebe's day job is as a senior software developer and system administrator at YTEC.

In his free time, he built the free, open-source FlashMQ software. Together with Jeroen and Rowan, he is now building a managed MQTT hosting business around his open masterpiece.

The ME FW of system was found abnormal

February 25, 2024 /

My computer sometimes doesn’t want to boot and/or shutdown anymore and gives the warning at boot time in plain text (not graphically): The ME FW of system was found abnormal. It happened last night and because I had this before, I still had a USB stick with firmwares on it from last time, it was quickly recovered. But, I did need to refresh my memory about which version to use. Last time I used the most recent version, and that caused problems. So, hence this blog post.

As a reminder to myself: the emergency firmware E7971IMS.B50 is located on two USB sticks: the one on my key chain and the ‘switch blade’ one on my desk.

Mainboard: MSI H170A PC MATE (MS-7971)

Upgrading Roundcube on Ubuntu 18.04 and Ubuntu 20.04

June 18, 2023 /

What a mess… After postponing this for many months because I knew what awaited me, I double-upgraded an Ubuntu 18.04 server today, and aside from MySQL breaking in some spectacular ways (corrupt redo log for one), the Roundcube package was broken, primarily due to MySQL.

In MySQL 8, ‘system’ is now a reserved keyword; a change that in my opinion was quite risky, because many people use that word. This resulted in the Roundcube Debian migration scripts failing, because the word ‘system’ was used without back-ticks around it. 

mysql said: ERROR 1064 (42000) at line 15: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'system SET value='2018021600' WHERE name='roundcube-version'' at line 1.

These scripts are actually part of the .deb file, to be executed by dbconfig.

I reported the bug, but there was no interest in fixing it. Today I posted my work-around there too. Look there for the SQL files I used. I can’t upload them to this blog.

I had more problems, so I wanted to lay out what I did to fix it.

Ubuntu 20.04 installs this deb. In it are the SQL migration scripts in ‘usr/share/dbconfig-common/data/roundcube/upgrade/mysql’. I extacted it with ‘dpkg –extract’ and I took out ‘1.4.1-1’ and removed everything above the line that failed (because in MySQL the migration is not atomic…) and ran it like:

mysql roundcube < 1.4.1-1__starting_from_first_failed_statement.sql

Then on the next upgrade, I had to do the same with the deb for 1.5.

This one was more problematic, because the migration steps contained a change to case insensitive collation. This breaks if you have multiple users with different collation:

ERROR 1062 (23000) at line 33: Duplicate entry 'Info@example.nl-mail.example.nl' for key 'users.username'

I had to remove the users in question, from the table ‘users’ and ‘identities’, and continued running the script from the offending line (because again, DDL is not atomic in MySQL).

To be honest, I didn’t check if it cascaded foreign keys, like users’ address books and such… It was primarily ancient users, so I didn’t care.

A weird observation, is that the ‘system’ table is actually empty. That “SET value=’2018021600′” was a no-op. Now I wonder if I should add that row…?

The ‘system’ problem is likely to happen again on the next upgrade. At least I’m prepared now.

Verification of salt-archive-keyring.gpg fingerprints

April 26, 2022 /

Because a hacked website can easily replace GPG keys, I wanted to write down for myself what the verified fingerprints of the Salt archive keyring are:

# sha256sum /usr/share/keyrings/salt-archive-keyring.gpg
ea38e0cdbd8dc53e1af154a8d711a2a321a69f81188062dc5cde9d54df2b8c47  /usr/share/keyrings/salt-archive-keyring.gpg
 
 
# gpg /usr/share/keyrings/salt-archive-keyring.gpg
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
pub   rsa2048 2014-06-24 [SC]
      754A1A7AE731F165D5E6D4BD0E08A149DE57BFBE
uid           SaltStack Packaging Team <packaging@saltstack.com>
sub   rsa2048 2014-06-24 [E]

FlashMQ version 0.8.0

June 13, 2021 /

Just released FlashMQ version 0.8.0, a multi-threaded (multi-core) lightweight MQTT server. The latest new feature is a native authentication plugin interface for easy implementation of custom authentication and authorization.

Gitlab ‘Your password expired. Please access GitLab from a web browser to update your password.’

June 3, 2021 /

I just fixed a very obscure error in Gitlab of ‘Your password expired. Please access GitLab from a web browser to update your password.’ This error would appear during SSH operations, and in various log files in /var/log/gitlab. Also XHR requests to the server got that response.

Nowhere in the GUI was it visible that anything expired. It’s about a gitlab that linked to a Windows Active Directory.

It turned out that in Postgres table ‘users’, of hundreds of users, 5 had ‘password_expires_at’ set to somewhere in 2014. I guess in a recent update they started checking that field.

To fix it, I did:

sudo -u gitlab-psql /opt/gitlab/embedded/bin/psql -h /var/opt/gitlab/postgresql -d gitlabhq_production
update users set password_expires_at = null where password_expires_at is not null;

« Older posts

© 2025 BigSmoke

Theme by Anders Noren — Up ↑