Akonadi not working after Upgrade from Ubuntu 19.10 to 20.04

After the upgrade the Akonadi server did not start. The respective error messages when starting it manually again pointed to a database problem. The reason was that the maria db server was not allowed to access my personal files thanks to AppArmor. To fix it, I had to apply the following partch to /etc/apparmor.d/usr.sbin.mysqld:

  /run/user/7503/akonadi/* rw,
  /home/wilmes/.local/share/akonadi/** rwk,

This is very specific to my personal user, so it would be better to replace my user name by some wildcard but I just do not have the time to look deeper into this. This must be sufficient as reminder for the next time this happens ...

Transfer MySQL user grants to another server

How to transfer a set of user's grants from one mysql server to another?

There is an answer on serverfault.

The essential part is to define this function in bash:

  mysql -B -N $@ -e "SELECT DISTINCT CONCAT(
    'SHOW GRANTS FOR \'', user, '\'@\'', host, '\';'
    ) AS query FROM mysql.user" | \
  mysql $@ | \
  sed 's/\(GRANT .*\)/\1;/;s/^\(Grants for .*\)/## \1 ##/;/##/{x;p;x;}'

edit the skript and remove all double backslashes (\\) and then use it like this:

mygrants --host=prod-db1 --user=admin --password=secret | grep rails_admin | mysql --host=staging-db1 --user=admin --password=secret

Delete files older than ... with find

I need a reminder on how to delete files that are older than a certain date so here it is:

sudo find . -not -newermt "2012-05-11" -type f -print0 | xargs -0 -L 100 sudo rm

This deletes every file in . that is older than 2012-05-11.

The two letters behind the "newer" option define that we are using the modification time of the files and that the parameter to the option is a date rather than a file name.

The xargs argument -L specifies that a maximum of 100 file names will be appended for a single execution of rm.

To also remove all empty directories that remain after this operation issue

sudo find . -type d -empty print0 | xargs -0 -L 1 sudo rmdir

Resizing a Linux filesystem without lvm

Recently I had a problem with virtual machine (vmware, ESX) which had a second disk that was too small. So somebody used vmware to resize the disk but, of course the change was not reflected by Linux since the partition size and the file system size must be changed manually. So I came into the game.

The Linux was an RHEL 6 on vmware. It contained a production level Oracle server that was busy (load constantly at 0.5 at least) and accessing the disk in question.

Since this is not my daily job I searched the Internet for hints on traps you could step into when doing this. First of all was to request a full backup of the disk in question so that took some time to complete and I had time for a rehearsal.

Next step was to negotiate a down time of about 2 hours. That was necessary because the manipulation of the file system implied to stop the Oracle server. It might have worked without but I was not ready to take the responsibility on this, not knowing exactl how important this server was.

Ok, now to the action. Here are the steps I used to complete the job:

  1. Log on to the machine means here to establish a VPN connection and to connect via rdesktop to the vmware ESX. Then I was able to use the console of the virtual machine to log on.
  2. Stop Oracle (/etc/init.d/rc.oracle stop) and verify that there is no oracle process running any more.
  3. Just to note how it looks now issue a df -h
  4. unmount the file system in question (umount /dev/sdb1).
  5. Resize the partition with fdisk. This involves printing all the partitioning parameters, delete the original partition, recreate it with the same starting position and the full size of the disk. Then write the partition table.
  6. If the kernel recognized the changed partition size we are fine and can proceed to resizing the file system. Otherwise:
  7. Remove the Oracle-Link from /etc/rc3.d to prevent Oracle from starting on reboot. Then reboot.
  8. The kernel should now have recognized the new disk/partition size so we can proceed to
  9. Resizing the file system: Since it is a ext4 we just need to umount the file system (not necessarily but I prefer to) and then use the command /sbin/resize2fs -p /dev/sdb1 to do the actual resizing. It might be necessary to execute a disk check before so use /sbin/e2fsck -f /dev/sdb1 to do that.
  10. The most important stuff is done so lets take back any changes to the system that we might have done:
  11. Remount the file system
  12. Issue df -h to compare it to the state of before the change.
  13. Restore the link to the oracle start script in /etc/rc3.de
  14. (Re)start Oracle

The machine should now be in a safe state and usable as a production ready server again. The problem on the whole thing is that if something goes wrong, specifically on resizing the partition or resizing the file system, you will be lost in nowhere and you will ave to restore a backup of the disk.


Jedes Mal wenn ich eine neue Datenbank auf einem neuen Rechner anlegen will, stellt sich wieder dasselbe Problem: Wie komme ich an die ersten Nutzer? Hier ist es aufgeschrieben.

  1. Als Benutzer root die Datei pg_hba.conf anpassen. Für den Zugriff per Passwort empfielt es sich z.B. diese Zeilen drin zu haben:
    1. host    all         all          md5
    2. host    all         all         md5
    ident sollte in der letzten Spalte nicht vorkommen. Ich bin zwar nicht ganz sicher warum, aber es kann sein, dass es mich hier gehindert hat, eine Verbindung zu bekommen.
  2. Ebenfalls als root in der Datei postgresql.conf einen Eintrag listen_addresses = '*' und einen Eintrag port = 5432 anlegen.
  3. Benutzer postgres werden (sudo -s -u postgres)
  4. psql aufrufen
  5. Dem Benutzer postgres ein Passwort verpassen, z.B. mit alter user postgres with password 'xyz';
  6. Nun kann man als beliebiger Nutzer z.B. pgadmin3 verwenden und sich als Benutzer postgres anmelden und so Datenbanen und Benutzer anlegen.