Gefiltert nach Falko Filter zurücksetzen

Letsencrypt Root CA auf altem MacOS

05. October 2021, Falko - Technik

Fehlermeldung zu Zertifikat auf MacOS 10.11 und älter

Seit letztem Donnerstag 30.9.21 kann es passieren, dass bei alten MacOS Systemen die folgende Meldung auftaucht:

Behebung

https://letsencrypt.org/certs/isrgrootx1.der herunterladen und speichern.

Schlüsselbundverwaltung öffnen und diese heruntergeladene Datei dort vom Finder hinein ziehen.

Dann im Finder per Doppel-Click auf diese Datei, über das Dreieck vor "Vertrauen" die Auswahlliste öffnen und von "Systemvertrauen" zu "Immer Vertrauen" ändern.

Beim Verlassen/Schließen dieses Fensters wird eventuell eine Passwort-Eingabe verlangt.


gitlab storage migration legacy to hashed workaround

13. May 2021, Falko - Linux, Anwendungen

Gitlab migrate_to_hashed funktioniert nur teilweise

Betrifft Gitlab omnibus 13.x

Nach Umzug meiner gitlab-omnibus-Installation auf einen anderen Server habe ich auch die Migration von legacy zu hashed storage durchgeführt.

Leider hat das bei 39 von knapp 150 Projekten bzw. deren Repos nicht funktioniert. Auch mehrmaliges Anstoßen führte zu keiner Fehlermeldung. Ab Gitlab Version 14.x gibt es den legacy storage nicht mehr ... man muss hier also tätig werden.

Relevante Links dazu: https://docs.gitlab.com/ee/administration/raketasks/storage.html  https://docs.gitlab.com/ee/administration/repository_storage_paths.htmlhttps://forum.gitlab.com/t/repo-migration-fails-projects-repositoryinuseerror/48808   https://forum.gitlab.com/t/a-number-of-hashed-storage-project-migrate-jobs-failed-projects-show-the-repository-for-this-project-does-not-exist/46002/6 (mit Script zum Rücksetzen des readonly flag)

Der grundlegende Hinweis war, man soll nicht auf 13.4.0, sondern gleich auf 13.5.4 updaten - was aber, wenn man zwischendurch auf der fehlerhaften Version war?

Scheinbar passiert Folgendes: repos werden im hashed storage neu angelegt, können aber wegen readonly-flag nicht im legacy storage gelöscht werden.

Wenn man o.g. Script nutzt, sind die readonly flags zwar weg - aber die migration funktioniert trotzdem nicht, weil das Repo im legacy wie auch im hashed storage vorhanden ist.

Hilfen dazu:

 

gitlab-rake gitlab:storage:list_legacy_projects | tee legacy_projects.txt
find /var/opt/gitlab/git-data/repositories/@hashed/ -name config -exec grep -H "fullpath" {} \; | tee list-hashed-repos.txt
grep -H fullpath /var/opt/gitlab/git-data/repositories/*/*.git/config  | tee list-legacy-repos.txt
# in einem anderen terminal zur Kontrolle:
tail -n100 -f /var/log/gitlab/sidekiq/current |grep moved
# pro repo und ID aus legacy_projects.txt führe aus:
# grep -h (reponame) list*txt
# lösche repo im hashed storage, dann:
gitlab-rake gitlab:storage:rollback_to_legacy ID_FROM=129 ID_TO=129 && gitlab-rake gitlab:storage:legacy_projects

 

Hier hilft also nur, eine Liste der Projekte mit legacy storage UND hashed storage zu erstellen. Der  jeweils überflüssige Pfad im hashed storage wird gelöscht WENN dasselbe Repo im legacy storage vorhanden ist und dann wird die Migration erneut angestoßen, erfolgreich.

Das lässt sich zwar auch sicherlich per Script automatisieren, wenn es zu viele Repos sind ... aber in dem Fall war mir wichtiger, dass nicht aus Versehen etwas Falsches gelöscht wird.

Leider bleiben ein paar Repos übrig, die kein legacy Repo mehr haben - nur ein hashed - die aber immer noch als "legacy" aufgeführt werden .... wenn jemand weiß, was zu tun ist: gern Mail-an-mich


Ein altes Gigabyte-Mainboard und die host protected area

31. October 2020, Falko - Linux, System

  • Lizenz: https://creativecommons.org/licenses/by-sa/3.0/ Quelle: https://en.wikipedia.org/wiki/BIOS_boot_partition#/media/File:GNU_GRUB_components.svg

Stell dir vor, du aktualisierst dein (Server-) System ... und dann lassen sich auf keiner Festplatte mehr Partitionen einhängen - außer vom System selbst.

Schreck lass nach: alle Daten weg?

Bei fdisk -l sieht das dann z.B. so aus:

 

Disk /dev/sdb: 2,75 TiB, 3000591900160 bytes, 5860531055 sectors
Disk model: Hitachi HUS72403
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start        End    Sectors Size Id Type
/dev/sdb1           1 4294967295 4294967295   2T ee GPT

 

gdisk findet die Partitionen noch, meldet aber Fehler mit der GPT:

 

~:# gdisk -l /dev/sdb
Main header: OK  
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Disk /dev/sdb: 5860531055 sectors, 2.7 TiB
Model: Hitachi HUS72403
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): xxxxxxxxxxxxxxxxxxxxxxxxxx
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 0 sectors (0 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      2147485695   1024.0 GiB  8300  
   2      2147485696      4294969343   1024.0 GiB  8300  
   3      4294969344      4303357951   4.0 GiB     8200  
   4      4303357952      5860533134   742.5 GiB   8300  

 

Erstmal suchen wir nach möglicherweise geänderten BIOS-Einstellungen, ohne Erfolg.

Die Logik sagt: da fehlt ein Stückchen am Ende der Festplatte,
Backup-Partitionstabelle und -Header scheinen daher weg zu sein.

Was war passiert: wir hatten die Vermutung, dass beim Update auf
Ubuntu 20.04 eine alte Einstellung wieder reaktiviert wurde,
die, solange Ubuntu 18.04 installiert war, keine Beachtung fand:
die Host Protection Area (HPA).

In einer Log-Datei von vor zwei Tagen - manchmal ist es ganz gut, seine
Aktionen mitzuschreiben - finden wir die bisherigen Sektorgrößen der
Festplatten wieder:

 

root@server:~# grep TiB logs/sicherung.txt
Disk /dev/sdb: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
Disk /dev/sdc: 2,7 TiB, 3000592982016 bytes, 5860533168 sectors

root@server:~# hdparm -N /dev/sdb
/dev/sdb:
 max sectors   = 5860531055/5860533168, HPA is enabled

root@server:~# hdparm -N /dev/sdc
/dev/sdc:
 max sectors   = 7814035055/7814037168, HPA is enabled

 

Die Vermutung bestätigt sich durch Aufruf von hdparm: die erste Zahl
ist geringfügig kleiner (2113 bytes) als die eigentliche Festplattengröße.

Weitere Informationen zu HPA finden sich im Thomas-Krenn-Wiki sowie bei Wikipedia

Das System ist offensichtlich so eingestellt, dass die HPA nicht ignoriert wird:

 

~:# cat /sys/module/libata/parameters/ignore_hpa
0

 

Wir testen das Gegenteil der bei Thomas Krenn erwähnte Lösung, indem wir dem Kernel beim Booten (in /etc/default/grub)
einen neuen Parameter mitgeben:

 

libata.ignore_hpa=1

 

Was letztlich die "Erlösung" bringt: alle Daten-Partitionen sind wieder da und können
auch - als wäre nix gewesen - wie immer eingehangen werden.

Unklar bleibt, wieso das passiert ist - und ob es wirklich mit dem Upgrade auf Ubuntu 20.04 zusammenhängt. Zeit für's Feierabend-Bier ...

Update: es scheint ehr mit dem Versuch, von der falschen Festplatte zu booten, zusammen zu hängen - siehe https://superuser.com/questions/1282451/sudden-decrease-of-hard-drive-sectors

 

"... if you are using a Gigabyte motherboard manufactured before 2010 then you should definitely check to see 
if you have HPA on any of your drives.  Also, it is definitely possible to have an HPA from a previous motherboard.  
If a drive has at any point in time been used with one of these HPA-inducing boards, then there's a good chance 
that it still has a vestigial HPA, even if it has been formatted since."

 

PS: du kennst das Problem auch - und hast eine Erklärung? Schreib uns gern in den Kommentaren dazu.

PPS: Die GUID-Partition-Table wird hier gut erklärt. Quelle für das Aufmacher-Bild.


Warum ich serverseitige Mail-Filter nutze und das Dilemma mit Thunderbird-Addons

02. October 2020, Falko - Anwendungen, Anwendungen

Serverseitige Mail-Filter mit Sieve

... oder wie ich gerne unnötige Zeitfresser vermeide

Heute bin ich wieder mal über das Problem gestolpert, dass sich plötzlich im Thunderbird etwas nicht mehr so verhält, wie ich es gewohnt bin. Das hat einerseits damit zu tun, dass ich alles, was Zeit fressen könnte, möglichst wegautomatisiere und gleichzeitig doppelte Arbeit vermeiden möchte/muss.

Serverseitige Filter (oder "sieve" = engl. Sieb) haben den entscheidenden Vorteil, dass Mails automatisch in Ordner "weg-"sortiert werden können. Da das auf dem Mailserver passiert, brauch ich mich weder auf Handy, Tablet, in Webmail oder wo auch immer ich Mails lesen will darum zu kümmern, also am Client. Sondern der Server erledigt das für mich. Normalerweise (= "normal für mich". hallo Hetzner, warum geht das bei euch nicht??) ist das Sieve-Protokoll auf dem Server aktiviert - zumindest wenn man einen eigenen Mailserver betreibt, auf jeden Fall zu empfehlen.

BTW: Bei GMail heißt das Nachrichtenfilter und es gibt eine Beispielsammlung.

Die Sache mit Thunderbird und dem Sieve-Addon

Für die Bearbeitung dieser Sieve-Filter gibt es nun mehrere Möglichkeiten - eine ist z.B. den Webmailer Roundcube auf dem Server zu verwenden und dazu dann im Roundcube das managesieve-Plugin zu aktivieren. Dann lassen sich die Filter "grafisch" per Web-GUI bearbeiten ... eher nix für Programmierer, aber für normale Nutzer perfekt.

Für Thunderbird gab/gibt es entsprechend ein Addon, mit dem sich diese Filter einfach unter Nutzung der Sieve-Sprache mit Regeln wie if, else, regex, header, contains usw. bearbeiten lassen - schon eher etwas für Programmierer. An sich kein Hexenwerk - das Thunderbird-Addon muss nur die Verbindung zum Server-Port 4190 aufbauen, die Regeln laden, bearbeiten und wieder zurück schreiben. Das Ganze noch schön mit Syntax-Prüfung und Suche ... läuft jahrelang.

Bis die Kollegen bei Mozilla dann anfangen, die Addon-Schnittstellen zu ändern. Teilweise kein Addon-Programmierer mehr hinterher kommt, die kompatiblen Versionen im Addon nachzutragen. Die Addons komplett neu programmiert werden müssen. Und als ich heute feststelle, dass das Sieve-Plugin im Thunderbird "mal wieder" nicht funktioniert, finde ich das:

Rezension bei Mozilla-Addons:

github.com/thsmi/sieve/


Several years ago Mozilla made a strange decision. They dropped their very flexible addon system and copied the extremely limited WebExtensions from Google Chrome.
An this ultimately meant for Thunderbird that "classic" addons will go way.

Now in 2020 classic Thunderbird addons are dead. Which meant for the addon it needed to evolve and drop its Thunderbird dependencies. It is now a portable standalone application!

Mit anderen Worten: es gibt das Addon zwar noch. Aber die Entscheidung, dieses Addon umzubauen zu einer eigenständigen - und damit von Thunderbird im Grunde unabhängigen - Anwendung ist wirklich eine gute Idee..

Manage Sieve Scripts - Webanwendung

Inzwischen gibt es ja mit "AppImage" die Möglichkeit, eine ausführbare Linux-Anwendung ohne weitere Abhängigkeiten zu nutzen. Oft hab ich das noch nicht gemacht - aber angefangen z.B. beim Foto-Manager DigiKam war das eine perfekte Möglichkeit, gleich die neueste Version haben zu wollen.

Was soll ich sagen: die Sieve App funktioniert einfach (unter Linux. Windows noch nicht getestet, aber funktioniert sicher genauso). Der Import der Einstellungen von Thunderbird klappt ebenfalls tadellos. Und nun hoffentlich immer und unabhängig von den Mozilla-Entwicklern :)


Ready for takeoff ...

10. September 2020, Falko - Familie, TYPO3

Von 4.5 nach 10.4

war es doch ein Stück weiter als vermutet. Aber alle relevanten Daten sind "mitgekommen", wenn auch inzwischen leicht reduziert und aktualisiert ... sicher ist da noch Einiges zu tun.

Was ich mir schon lange gewünscht habe - das Umschalten auf ein anderes Layout ist nun sehr einfach möglich: einerseits zum Ausprobieren von neuen Ansichten, aber auch für diejenigen, die vielleicht wegen Kontrast, Farbsehschwäche oder anderen Problemen lieber mehrere Möglichkeiten haben möchten.

Jetzt kann Neues sehr schnell ausprobiert und eingebaut werden, die Seite ist mobil-fähig und Google dann hoffentlich auch zufrieden :)

Die Blog-Einträge konnten zumindest von t3blog zu t3extblog gerettet werden, wenn auch mit viel Handarbeit. Ob die noch viel älteren ee_blog Posts das wert sind, nochmal eingepflegt zu werden ... vielleicht irgendwann aus historischen Gründen.

Auch das Einbinden von Bildern/Videos und anderen Inhalten ist nun leichter möglich.