Nach Mac OS Catalina Update – Mail App Suchfunktion ist kaputt

Das Update auf Mac OS Catalina lief bei mir eigentlich ohne Probleme durch, aber heute fiel mir dann auf, dass die Suchfunktion in der Mail App sich sehr komisch verhielt bzw. einfach kaputt war.

Mir war natürlich gleich klar, dass der Suchindex wahrscheinlich einen Treffer hatte, da ich die App ja trotzdem normal bedienen und Mails senden/empfangen konnte.

Um das Problem zu beheben, musste ich also den Suchindex der Mail App zurücksetzen und neu aufbauen lassen. Dazu sind folgende Schritte nötig:

  1. Mail App beenden
  2. Im Finder den Ordner ~/Library/Mail/V7/MailData öffnen (mit CMD+SHIFT+G)
  3. Alle Dateien, die mit „Envelope Index“ beginnen löschen (oder in einen Backup-Ordner schieben)
  4. Mail App wieder starten. Es empfängt euch ein Screen, der mitteilt, dass Mail sich selbst reparieren muss. Anschließend werden die Mails neu indiziert, in dieser Zeit ist Mail nicht benutzbar.

Nginx Docker Reverse Proxy wirft 404 Fehler ab dem zweiten Request

Als großer Fan von “nackten Servern” auf denen nur Docker Container laufen, nutze ich Nginx als Reverse Proxy – im Speziellen das großartige Setup von jwilder/nginx-proxy in Kombinantion mit dem Let’s Encrypt Addon. Effektiv läuft das Teil passiv mit und schaut nur auf bestimmte Environment-Variablen anderer Docker Container. Sobald es diese sieht, wird automatisch ein Reverse Proxy in Nginx so konfiguriert, dass er diesen Dienst erreichbar macht und gleichzeitig wird noch ein Let’s Encrypt Cert für die entsprechende Domain besorgt und auf dem neuesten Stand gehalten.

Nun hatte ich in einem Setup mit sehr vielen gleichzeitig laufenden Diensten das Problem, dass einer der Dienste immer nur auf den ersten Request erfolgreich geantwortet hat, aber bei jedem weiteren Request nur noch einen 404 geworfen hat. Der Dienst selbst lief, Nginx hat auch keinen Fehler im Log geworfen und ich war etwas ratlos.

Nach ein paar grauen Haaren mehr und dem ein oder anderen versteckten Hinweis auf Google kam ich dann auf des Rätsels Lösung: durch ein fehlerhaftes Deployment lief kurzzeitig ein weiterer Container, der mittels der Environment Variable die gleiche URL für sich beanspruchte. Der Nginx Automatismus machte daraus automatisch einen Load Balancer. Nachdem das fehlerhafte Deployment weg war, wurde der Loadbalancer aber nicht mehr aufgelöst und somit war nur noch einer von beiden Einträgen aktiv. Warum der Nginx dann trotzdem immer wieder auf den nicht vorhandenen Host gehen wollte erschließt sich mir nicht so richtig, aber das war des Problems Lösung.

Also bin ich einfach per docker exec in den Nginx Container und habe die Datei /etc/nginx/conf.d/default editiert:


# server.name.com
upstream server.name.com {
# CONTAINER_NAME_1
server 123.45.0.67:1234;
# CONTAINER_NAME_2
server 123.45.0.78:1234;
}

Nachdem ich den Part von CONTAINER_NAME_2 gelöscht hatte, konnte ich mittels

nginx -s reload

die Config von Nginx on the fly neu laden und ab dem Moment lief der Service wieder wie gewohnt.

Chrome scheint Videosoftware unter MacOS auszubremsen

Creative Director Felipe Baez von der Agentur Cre8ive Beast hat bemerkt, dass sich Final Cut Pro deutlich langsamer wird, und teilweise sogar abstürzen kann. Grund dafür ist das “Video-Toolbox” Framework, welches von MacOS bereitgestellt wird. Chrome nutzt dieses Framework und klaut somit die Ressourcen anderen Programmen, wie eben Final Cut Pro. Das gleiche Problem tritt auch z.B. bei Handbrake auf, und somit wahrscheinlich auch bei weiteren Video-Editoren.

Aktuell ist der Ratschlag: sobald man irgendeine Art von Videoschnitt macht, sollte Chrome nicht laufen.

Bei dieser Gelegenheit rate ich wirklich JEDEM dazu, sich den aktuellen Firefox nochmal anzusehen. War er in den letzten Jahren eher langsam und behäbig geworden, ist er nun seit ca. 0,5-1 Jahr wieder in seiner alten Form zurück. Er ist super schnell (teilweise sogar schneller als Chrome), hat die gleichen Funktionen, und ganz wichtig: nimmt Privatsphäre und Datenschutz höchstwahrscheinlich deutlich ernster als andere Browserhersteller. Ich bin schon vor einer ganzen Weile umgestiegen (auf meinem Mac und auch auf iPhone/iPad) und bereue es in keinster Weise!

via Golem

Nextcloud mit nginx reverse proxy macht endlos reloads

Langer Titel, einfaches Problem.

Ich habe eine Nextcloud Instanz, die lokal läuft und dann mittels Nginx Reverse Proxy aus dem Internet nur per HTTPS erreichbar ist. Nach einem der üblichen Updates endete dieses Setup, welches bis dahin problemlos lief, immer in einer Endlossschleife – aber nur für die Website. Die Nextcloud Sync Clients liefen problemlos weiter.

Mir war also klar, dass es irgendwie mit dem Reverse Proxy zusammenhängen muss. Und so war es dann auch. Nachdem ich folgendes zur Config Datei hinzugefügt hatte, lief es wieder:

'overwritehost'     => 'WWW.MEINE.DOMAIN',
'overwriteprotocol' => 'https',

Das Problem war einfach, dass scheinbar Nextcloud intern auf HTTP gehen wollte, was durch den Auto-Redirect des Nginx auf HTTPS dann für die Endlosschleife gesorgt hatte 🙂

[Quicktip] Better Snap Tool started nicht mehr unter Mac OS Mojave

Nachdem ich vor kurzem auf Mac OS Mojave aktualisiert hatte, fiel mir heute morgen auf, dass Better Snap Tool auf meinem zweiten Macbook gar nicht mehr startet. In der Systemkonsole erschien nur eine Fehlermeldung:

Unable to load Info.plist exceptions (eGPUOverrides)

So richtig Sinn machte die aber für mich nicht, denn ich bezweifle, dass Better Snap Tool regen Gebrauch von der GPU macht 🙂

Ein Hinweis im Forum des Herstellers brachte mich dann aber weiter: Die Application Firewall bzw. die Datenschutzeinstellungen im Security System sind das Problem.

Die Lösung ist dann, wie immer, sehr einfach:

  • In den Systemeinstellungen den Punkt “Sicherheit”/”Security” aufrufen und dann das Better Snap Tool aus der Liste der erlaubten Apps entfernen.
  • Better Snap Tool starten, der Dialog für das erneute Hinzufügen der App in den Sicherheitsbereich erscheint:
  • Nach erfolgreichem erneuten Aktivieren der App im Sicherheitsbereich startet Better Snap Tool dann auch endlich wieder wie erwartet

Freenas Jail meldet, dass das Shared Object libdl.so.1 fehlt

Beim Herumspielen mit einem neuen Jail in meiner Freenas Instanz konnte ich zwar alle möglichen Packages installieren, jedoch meldeten die diversen Tools immer wieder folgendes (in diesem Fall bei python3):

Shared object "libdl.so.1" not found, required by "python3.5"

 

Soweit ich es herauslesen konnte, liegt das wohl an ein paar umgebauten Paketen im aktuellen Freenas Jail Template, weswegen es zu dieser Unstimmigkeit kommt. Um das Problem vorerst zu lösen, kann man sich mittels eines kleinen Downgrades behelfen:

  • die Datei “/usr/local/etc/pkg.conf” bearbeiten und in der ersten Zeile folgendes hinzufügen:
    set OSVERSION = 1101001
  • in der Datei /etc/pkg/FreeBSD.conf die Property “url” auf folgendes ändern:
    url: "pkg+http://pkg.FreeBSD.org/${ABI}/release_2",
  • in der Datei /usr/local/etc/pkg/repos/FreeBSD.conf die Property “url” auf folgendes ändern:
    url: "pkg+http://pkg.FreeBSD.org/freebsd:11:x86:64/release_2",
  • und dann mittels folgender Befehle das Downgrade starten:
    pkg update -f
    pkg upgrade -f

Alle aufkommenden Fragen mit y bestätigen, und schon sollten Python und co wieder laufen.

Quelle: forums.freenas.org

python pip läuft nicht mehr wegen OpenSSL lib Fehler

Heute hat mich pip mit der Fehlermeldung

AttributeError: 'module' object has no attribute 'SSL_ST_INIT'

begrüßt. Da nach diesem Fehler sämtliche pip Operationen nicht mehr funktionieren, muss man etwas nachhelfen. Genauer gesagt: zwei Python OpenSSL Module müssen entfernt und nochmal neu installiert werden:

rm -rf /usr/lib/python2.7/dist-packages/OpenSSL
rm -rf /usr/lib/python2.7/dist-packages/pyOpenSSL-0.15.1.egg-info
sudo pip install pyopenssl

Danach sollte pip wieder wie gewohnt funktionieren.

PS: bitte achte drauf, dass du die korrekte Python Version bereinigst, das gleiche gilt für die pyOpenSSL Version!

Am einfachsten findest du die Version heraus, indem du dir per

which pip

den Pfad zu pip geben lässt, dann mit einem vi/nano /[PATH_TO_PIP]/pip in der obersten Zeile anschaust, welcher Interpreter verwendet wird, diesen Pfad kopierst und dann mit

/PATH_TO_PYTHON/python --version

die korrekte Version herausbekommst.

[Quicktip] Symfony2 / Doctrine Schema Update funktioniert nicht und liefert keine Ausgabe

Die Logging Mechanismen von Symfony2 sind manchmal nicht ganz durchschaubar: wenn irgendwas in den Entities nicht stimmt, kann es sein, dass die Schema Validierung oder auch das Schema Update beim Aufruf des entsprechenden Konsolenkommandos kommentarlos beendet werden. In diesem Fall prüft intensiv, dass die Namespaces und auch die Annotations innerhalb der Entities sowie den Repositories korrekt sind!

[Quicktip] iTunes Match meldet Fehler 4002 und kann nicht mehr synchronisieren

Dieser Fehler hat mich schon länger beschäftigt, die Lösung ist aber dann doch relativ einfach. Er kommt durch “Genius” zustande und kann sehr leicht so behoben werden: “iTunes Match deaktiveren” im Menüpunkt “Store” auswählen, anschließend iTunes Match wieder aktivieren. Bei mir war das Problem damit behoben 😉

[Quicktip] Symfony2 bringt weiße Seite und keinen Eintrag in den Error Logs

Wenn auch euch dieser Fehler begegnen sollte und ihr nicht mehr weiter wisst: prüft, ob in euren Config Dateien (bei mir war es die service.yml) die Keys (also z.B. der Name eines Service) ungültige Zeichen enthalten – wie z.b. Bindestriche 😉