Posts Tagged ‘High Sierra’

Sonntag, 8. März 2020

Mail.app unter macOS High Sierra sortiert IMAP-Ordner nicht (mehr) alphabetisch

Link zu diesem Artikel

Das Problem löst man, indem man Apple Mail zuerst schliesst und die Datei .mboxCache.plist des betroffenen IMAP-Kontos löscht.

Mit dem folgenden Befehl findet man alle von Mail.app angelegten Dateien mit diesem Namen:

$ find ~/Library/Mail -maxdepth 3 -type f -name .mboxCache.plist

Wer die Dateien gleich löschen möchte:

$ find ~/Library/Mail -maxdepth 3 -type f -name .mboxCache.plist -exec rm '{}' ';'

ACHTUNG: Bitte kopiert den zweiten Befehl auf eigene Verantwortung von hier. Der Befehl LÖSCHT Dateien auf deinem Computer — wenn alles gut geht nur diejenigen Dateien, die hier beschrieben wurden. Ich übernehme aber keine Gewähr..

Quelle: Using Apple Mail, my folders have stopped being displayed in alphabetical order – how can I restore this sort order?

Tags: , , , , , , ,
Labels: Apple

1 Kommentar | neuen Kommentar verfassen

Sonntag, 1. März 2020

Unter macOS High Sierra mit MacPorts, postfix und s-nail E-Mails versenden

Link zu diesem Artikel

Emails von der Kommandozeile versenden — was man bei Linux im Handumdrehen hinkriegt, erforderte bei mir unter macOS stundenlange Handstände.

MacPorts postfix anstelle macOS postfix

Doch jetzt habe ich den Kniff raus: Die von macOS mitgelieferte postfix-Installation habe ich schlussendlich ignoriert und auf das MacPorts postfix-Paket gesetzt.

MacPorts Variants nicht vergessen

Der erste Fallstrick lauert schon hier: Um heutzutage über einen Hoster E-Mails zu versenden, benötigt man zwingend SASL und TLS. Diese Features müssen als sog. MacPorts Variants explizit mitinstalliert werden, sonst landen sie nicht auf dem Mac:

# port install postfix +sasl +tls

Ansonsten meldet postfix:

...
Mar 01 14:16:11 imac postfix/smtp[70687]: warning: smtp_sasl_auth_enable is true, but SASL support is not compiled in
Mar 01 14:16:11 imac postfix/smtp[70687]: warning: TLS has been selected, but TLS support is not compiled in
...

Verzeichnisse und Pfade zur Sicherheit hardkodieren

Eine funktionierende postfix-Konfiguration mitsamt Installationsscript habe ich von meinen Linux-Servern herüberkopiert (diese Anleitung alleine würde das Format dieses Blog-Artikels sprengen). Die Konfiguration habe ich aber mit den MacPorts-Einstellungen ergänzt. Denke daran: Bei Linux liegen die Konfiguration sowie die Arbeitsverzeichnisse allesamt am erwarteten Ort (bspw. /etc/postfix/main.cf). Da wir unter macOS auf MacPorts setzen, liegt dieselbe Datei hier unter /opt/local/etc/postfix/main.cf. Deshalb habe ich zur Sicherheit in main.cf folgende von MacPorts vorgeschlagene Ergänzungen (siehe /opt/local/etc/postfix/main.cf.sample) hinzugefügt:

$ cat /opt/local/etc/postfix/main.cf
# Directories
queue_directory = /opt/local/var/spool/postfix
command_directory = /opt/local/sbin
daemon_directory = /opt/local/libexec/postfix
data_directory = /opt/local/var/lib/postfix
meta_directory = /opt/local/etc/postfix
manpage_directory = /opt/local/share/man
sample_directory = /opt/local/share/postfix/sample
readme_directory = /opt/local/share/postfix/readme
shlib_directory = no
html_directory = no

# Paths
sendmail_path = /opt/local/sbin/sendmail
newaliases_path = /opt/local/bin/newaliases
mailq_path = /opt/local/bin/mailq

# Log
maillog_file_prefixes = /var, /var/log/macports/postfix
maillog_file = /var/log/macports/postfix/postfix.log

# Other stuff ...
mail_owner = _postfix
setgid_group = _postdrop
default_privs = nobody
unknown_local_recipient_reject_code = 550
debug_peer_level = 2
...

Logs in eine Datei schreiben

Weiter hatte ich während dem Debuggen so meine liebe Mühe, die Logging-Informationen zu finden, da diese an syslog gesendet werden und bei macOS dann in der Console.app landen. Deshalb habe ich im Gegensatz zu meinen Linux-Installationen auch noch die Konfigurationsdatei /opt/local/etc/postfix/master.cf anpassen müssen. Essentiell war es, die folgende Zeile einzufügen:

...
postlog   unix-dgram n  -       n       -       1       postlogd
...

Quelle: Postfix logging to file or stdout

Verhindern, dass fälschlicherweise die macOS postfix-Konfiguration geladen wird

Damit mir die Parallelinstallation von Postfix nicht in die Quere kommt und ich mir sicher war, dass die MacPorts-Installation von postfix tatsächlich die Konfiguration unter /opt frisst, habe ich kurzerhand den macOS postfix-Ordner verschoben:

# mv /etc/postfix /etc/postfix.bkp

Ob das wirklich nötig gewesen wäre sei dahingestellt; Vorsicht, wer das auf seinem System macht: Ich garantiere für nichts.

Postfix starten und stoppen

Die Postfix-Installation lädt man folgendermassen:

# port load postfix
# launchctl unload /Library/LaunchDaemons/org.macports.postfix.plist
# launchctl load -w /Library/LaunchDaemons/org.macports.postfix.plist

Die plist-Datei zeigt als symbolischer Link nach /opt/local/etc/LaunchDaemons/org.macports.postfix/org.macports.postfix.plist. In dieser Datei habe ich folgendes angepasst/ergänzt — das ist nicht zwingend nötig, sollte aber dazu führen, dass Postfix bei jedem Neustart automatisch gestartet wird. Ausserdem sollten im Fall von Start-Problemen Fehlermeldungen in eine Log-Datei geschrieben werden:

...
        <string>--pid=none</string>
    </array>
    <key>Disabled</key>
    <false/>
    <key>KeepAlive</key>
    <true/>
    <key>StandardOutPath</key>
    <string>/var/log/launchd.macports.postfix.standard.log</string>
    <key>StandardErrorPath</key>
    <string>/var/log/launchd.macports.postfix.error.log</string>
</dict>
</plist>

s-nail verwendet standardmässig die macOS mail-Executables

Anschliessend musste noch eine Mail-Programm her, welches erlaubt, den Absender eines E-Mails selber zu setzen. MacPorts bietet hierzu s-nail an (Homepage des Entwicklers).

# port install s-nail

Als ich mit s-nail ein Test-Mail versenden wollte folgte eine weitere Hiobs-Botschaft:

$ echo "Test email" | mail user@domain.tld
unknown: fatal: open /etc/postfix/main.cf: No such file or directory
/Users/user/dead.letter 7/135
mail: ... message not sent

Ich übertreibe nicht, wenn ich sage, dass ich Stunden mit Debugging verbracht habe. Bis ich plötzlich realisierte, dass s-nail die offiziellen Mail-Executables mail, mailx und/oder sendmail unter /usr/bin verwendet. Der Lackmus-Test: Wenn ich diese Mail-Executables manuell aufrief, erschien ein- und dieselbe Fehlermeldung.

Dies obwohl meine Bash PATH-Variable /opt/local/bin und /opt/local/sbin vor /usr/bin und /usr/sbin nennt, verwendete s-nail aus irgendeinem Grund standardmässig die letztgenannten Pfade.

Wie sage ich s-nail aber, dass es stattdessen die MacPorts mail-Befehle verwenden soll? Folgende Anpassung in /opt/local/etc/mail.rc war nötig:

...
set mta=/opt/local/sbin/sendmail

Absender (From:) der E-Mails selber festlegen

Anschliessend musste noch eine Mail-Programm her, welches erlaubt, den Absender eines E-Mails selber zu setzen. Ich verwende in Bash-Scripts sehr oft folgendes Konstrukt, und ich wollte sicherstellen, dass die Scripts sowohl unter Debian GNU/Linux als auch macOS laufen (Argument -a):

$ echo -e "Test" | $(which mail) -a "From: DNS Query Analyzer " -s 'Top 25 DNS Queries' user@domain.tld another.user@domain.tld

Ich habe leider eine schlechte, aber auch eine gute Nachricht. Die gute: Man kann auch unter macOS den Absender setzen. Leider aber nicht mit demselben Befehl wie unter Debian GNU/Linux.

Bei s-nail muss ich leider ein anderes Argument verwenden:

$ echo -e "Test" | $(which mail) -r "DNS Query Analyzer " -s 'Top 25 DNS Queries' user@domain.tld another.user@domain.tld

Postfix hat Probleme mit selber gesetzter Absenderadresse und SPF Records

Doch nun trat bereits das nächste Problem auf, wie ein Blick in die leere INBOX und in /var/log/macports/postfix.log zeigte:

...
Mar 01 15:43:59 imac postfix/smtp[81049]: 4D0E3FBBE221: to=<user@domain.tld>, relay=s000.cyon.net[149.126.4.000]:25, delay=20, delays=0.03/20/0.03/0.04, dsn=5.0.0, status=bounced (host s000.cyon.net[149.126.4.000] said: 550 SPF: 1.2.3.4 is not allowed to send mail from emeidi.com (in reply to RCPT TO command))
...

Faszinierend. Unter Linux hatte ich eine solche Fehlermeldung noch nie gesehen. Ich verwende für den Versand „offizieller“ E-Mails jeweils emeidi.com als Absenderadresse.

Schlussendlich blieb nur die Holzhammer-Methode. Ich verschob alle Konfigurationsdateien, welche auf meinen Linux-Installationen nicht existierten, von /opt/local/etc/postfix in den Unterordner _old. Schlussendlich sah das Verzeichnis so aus:

$ find /opt/local/etc/postfix/opt/local/etc/postfix
/opt/local/etc/postfix/_old
/opt/local/etc/postfix/_old/access
/opt/local/etc/postfix/_old/access.sample
/opt/local/etc/postfix/_old/aliases
/opt/local/etc/postfix/_old/aliases.sample
/opt/local/etc/postfix/_old/bounce.cf.default
/opt/local/etc/postfix/_old/canonical
/opt/local/etc/postfix/_old/canonical.sample
/opt/local/etc/postfix/_old/generic
/opt/local/etc/postfix/_old/generic.sample
/opt/local/etc/postfix/_old/header_checks.sample
/opt/local/etc/postfix/_old/LICENSE
/opt/local/etc/postfix/_old/main.cf.default
/opt/local/etc/postfix/_old/main.cf.proto
/opt/local/etc/postfix/_old/main.cf.sample
/opt/local/etc/postfix/_old/master.cf.proto
/opt/local/etc/postfix/_old/master.cf.sample
/opt/local/etc/postfix/_old/relocated
/opt/local/etc/postfix/_old/relocated.sample
/opt/local/etc/postfix/_old/TLS_LICENSE
/opt/local/etc/postfix/_old/transport
/opt/local/etc/postfix/_old/transport.sample
/opt/local/etc/postfix/_old/virtual
/opt/local/etc/postfix/_old/virtual.sample
/opt/local/etc/postfix/header_checks
/opt/local/etc/postfix/main.cf
/opt/local/etc/postfix/makedefs.out
/opt/local/etc/postfix/master.cf
/opt/local/etc/postfix/postfix-files
/opt/local/etc/postfix/sasl
/opt/local/etc/postfix/sasl/outgoing
/opt/local/etc/postfix/sasl/outgoing.db

In sasl/outgoing entfernte ich zudem den TCP-Port nach der Server-Adresse, und master.cf ergänzte ich mit Zeilen, die bisher nur unter Linux existierten.

Heureka

Und jetzt endlich kann ich mir von der Kommandozeile aus E-Mails senden. Hat nur geschlagene sechs Stunden gedauert.

Tags: , , , , , , , , , , , , , , , ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

Samstag, 9. November 2019

sed unter macOS an Hand von duplicity

Link zu diesem Artikel

Momentan gleise ich gerade die Migration von tarsnap mit Amazon S3 zu duplicity mit Backblaze B2 auf. Hauptgrund: Die verhältnismässig hohen Kosten.

Da MacPorts nur die veraltete duplicity-Version 0.7.17 liefert, welche mit folgender Fehlermeldung den Upload der Backup-Chunks verweigert … 

Attempt 1 failed. AttributeError: B2ProgressListener instance has no attribute '__exit__'
Attempt 2 failed. AttributeError: B2ProgressListener instance has no attribute '__exit__'
Attempt 3 failed. AttributeError: B2ProgressListener instance has no attribute '__exit__'
Attempt 4 failed. AttributeError: B2ProgressListener instance has no attribute '__exit__'
Giving up after 5 attempts. AttributeError: B2ProgressListener instance has no attribute '__exit__'

… habe ich mir ein Script geschrieben, welches Version 0.7.19 herunterlädt, kompiliert und in meinem Heimverzeichnis installiert.

Diese Version wiederum hat aber leider das Problem, dass die shebang-Zeile in ~/Library/Python/2.7/bin/duplicity folgendermassen lautet:

#!/usr/bin/env python2
...

Meine MacPorts-Installation kennt kein Executable mit dem Namen python2 und duplicity stirbt deshalb mit folgender Fehlermeldung:

env: python2: No such file or directory

Mein Installationsscript passt das duplicity-Script nun mit sed, dem Stream Editor, an. Da mit macOS das BSD sed mitkommt und nicht das GNU sed, muss man für ein Inline-Replacement folgendermassen vorgehen, damit es klappt:

sed -i "" 's/env python2$/env python2.7/g' /Users/user/Library/Python/2.7/bin/duplicity

Die leeren Quotes nach -i müssen zwingend angegeben werden, ansonsten erscheint die nachfolgende Fehlermeldung (vgl. Sed: ’sed: 1: invalid command code R‘ on Mac OS X).

sed: 1: invalid command code m

Wer mehr über die Unterschiede in den verschiedenen seds erfahren will, liest sich folgenden Artikel durch BSD/macOS Sed vs. GNU Sed vs. the POSIX Sed specification.

Tags: , , , , , , , , ,
Labels: Apple, Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 24. März 2018

ABBYY FineReader Pro for Mac meldet „Internal program error: Src/DefaultFontMetrics.cpp, 56“

Link zu diesem Artikel

Ich schwöre auf die Digitalisierung von Dokumenten und verwende dazu einen Fujitsu ScanSnap iX500 (teuer, aber jeden Rappen wert) zusammen mit einer separat gekauften Volllizenz von ABBYY FineReader Pro for Mac, um die gescannten Dokumente auf Knopfdruck durchsuchbar zu machen.

Leider habe ich seit dem Umstieg auf einen iMac 27 Zoll (Late 2015) mit macOS High Sierra das Problem, dass mich der FineReader fast bei jedem Texterkennungsvorgang mit der folgenden Fehlermeldung nervt:

Mein Workaround: Mittels Klick auf das „Read“-Icon die Texterkennung erneut starten. Manchmal reicht ein Klick, manchmal muss ich die Texterkennung bis vier Mal ankicken, bis die Software durchläuft.

Was manchmal auch hilft: Die Seiten rearrangieren respektive unnötige (leere) Seiten löschen.

Ich habe nun Mal beim Hersteller angefragt, was das Problem sein könnte und wie man es ein für allemal wegbringt.

Tags: , , , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Freitag, 23. März 2018

VirtualBox unter macOS High Sierra zum Laufen bringen

Link zu diesem Artikel

Das ist nicht so ganz trivial, da bei diesem und früheren macOS SIP (System Integrity Protection) aktiviert ist, VirtualBox aber einige Kernel Extensions (kext) laden können muss. Sonst kommt es zu folgenden Fehlermeldungen:

$ sudo "/Library/Application Support/VirtualBox/LaunchDaemons/VirtualBoxStartup.sh" restart
Loading VBoxDrv.kext
/Library/Application Support/VirtualBox/VBoxDrv.kext failed to load - (libkern/kext) system policy prevents loading; check the system/kernel logs for errors or try kextutil(8).
Error: Failed to load /Library/Application Support/VirtualBox/VBoxDrv.kext
Loading VBoxUSB.kext
/Library/Application Support/VirtualBox/VBoxUSB.kext failed to load - (libkern/kext) system policy prevents loading; check the system/kernel logs for errors or try kextutil(8).
Error: Failed to load /Library/Application Support/VirtualBox/VBoxUSB.kext
Loading VBoxNetFlt.kext
/Library/Application Support/VirtualBox/VBoxNetFlt.kext failed to load - (libkern/kext) system policy prevents loading; check the system/kernel logs for errors or try kextutil(8).
Error: Failed to load /Library/Application Support/VirtualBox/VBoxNetFlt.kext
Loading VBoxNetAdp.kext
/Library/Application Support/VirtualBox/VBoxNetAdp.kext failed to load - (libkern/kext) system policy prevents loading; check the system/kernel logs for errors or try kextutil(8).
Error: Failed to load /Library/Application Support/VirtualBox/VBoxNetAdp.kext
(kernel) Kext org.virtualbox.kext.VBoxNetAdp not found for unload request.
Failed to unload org.virtualbox.kext.VBoxNetAdp - (libkern/kext) not found.
(kernel) Kext org.virtualbox.kext.VBoxNetFlt not found for unload request.
Failed to unload org.virtualbox.kext.VBoxNetFlt - (libkern/kext) not found.
(kernel) Kext org.virtualbox.kext.VBoxUSB not found for unload request.
Failed to unload org.virtualbox.kext.VBoxUSB - (libkern/kext) not found.
(kernel) Kext org.virtualbox.kext.VBoxDrv not found for unload request.
Failed to unload org.virtualbox.kext.VBoxDrv - (libkern/kext) not found.

Apple beschreibt im Dokument User-Approved Kernel Extension Loading, wie man diese Kernel-Extensions trotz dem Schutz aktiviert.

Abgesehen davon gibt es auch noch den Issue-Thread „Cannot install virtualbox on macOS High Sierra“ auf Github. Ein Leser hat dort ein Script gepostet, mit dem die Freischaltung nach und nach vorgenommen werden kann.

Hier noch zwei nicht mit VirtualBox verwandte Meldungen, die zeigen, wie dem Benutzer von macOS High Sierra die Blockierung von kexts bekannt gegeben wird:

Tags: , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

curlftps kann unter macOS High Sierra mit macports nicht installiert werden

Link zu diesem Artikel

Heute erhielt ich folgende Fehlermeldung:

--->  Computing dependencies for curlftpfs
--->  Dependencies to be installed: osxfuse
--->  Building osxfuse
Error: Failed to build osxfuse: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_fuse_osxfuse/osxfuse/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port curlftpfs failed

In der angegebenen main.log las ich:

...
:info:build Command /bin/sh failed with exit code 1
:info:build ** BUILD FAILED **
:info:build The following build commands failed:
:info:build 	PhaseScriptExecution BridgeSupport\ Metadata build/OSXFUSE.build/Release/OSXFUSE.build/Script-28D525C40EA8076400B7CF7B.sh
:info:build (1 failure)
:info:build T:framework          | Failed to build target
:info:build Terminated: 15
:info:build Received signal: SIGTERM
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_fuse_osxfuse/osxfuse/work/osxfuse-osxfuse-431bdc5" && ./build.sh -t packagemanager -a build -v 5 --build-directory="/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_fuse_osxfuse/osxfuse/work" -- -a x86_64 --framework-prefix="/opt/local" --fsbundle-prefix="/opt/local" --library-prefix="/opt/local" 
:info:build Killed by signal: 15
:error:build Failed to build osxfuse: command execution failed
:debug:build Error code: CHILDKILLED 1299 SIGTERM {software termination signal}
:debug:build Backtrace: command execution failed
:debug:build     while executing
:debug:build "system {*}$notty {*}$nice $fullcmdstring"
:debug:build     invoked from within
:debug:build "command_exec build"
:debug:build     (procedure "portbuild::build_main" line 8)
:debug:build     invoked from within
:debug:build "$procedure $targetname"
:debug:build invalid command name "::ui_init"
:debug:build     while executing
:debug:build "::ui_init $priority $prefix $channels($priority) {*}$args"
:debug:build     ("uplevel" body line 2)
:debug:build     invoked from within
:debug:build "uplevel 1 $body"
:error:build See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_fuse_osxfuse/osxfuse/main.log for details.

Da ich keine Lösung für das Problem fand, eröffnete ich im MacPorts Trac einen Defect: osxfuse: build failed with SIGTERM

Die Antwort kam postwended — das Problem sei bekannt und bereits im Defect osxfuse @3.7.1: Library not loaded: @rpath/libclang.dylib (LoadError) beschrieben.

Als temporärer Workaround wird dort empfohlen:

$ cd /Applications/Xcode.app/Contents/Developer/Toolchains
$ sudo ln -s XcodeDefault.xctoolchain OSX10.13.xctoolchain

Danach kompilierte die Sache problemlos.

Tags: , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 22. November 2017

rsync über SSH verwendet auf dem Zielsystem die falsche rsync-Version

Link zu diesem Artikel

Die Migration von meinem Mac mini auf einen iMac 27″ Retina schreitet stetig voran. Die Daten habe ich dazu mit rsync über Gigabit-Ethernet vom Mac mini auf den iMac rüberkopiert.

Der Befehl sah ungefähr so aus:

$ rsync --protect-args -avz -e ssh . mario@domain.tld:/tmp

Bei einem besonderen Verzeichnis trat (ungefähr) folgende Fehlermeldung auf (ich habe sie leider nicht festgehalten):

rsync: on remote machine: --extended-attributes: unknown option
rsync error: syntax or usage error (code 1) at /SourceCache/rsync/rsync-45/rsync/main.c(1333) [server=2.6.9]
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.1]

Nach etwas Googlen realisiert ich, dass auf dem Zielsystem (dem iMac) zwar MacPorts mitsamt dem neuesten rsync längst installiert waren (/opt/local/bin/rsync mit rsync version 3.1.2 protocol version 31), über den ssh-Tunnel stattdessen aber das alte, von Apple mitgelieferte Binary verwendet wurde (/usr/bin/rsync mit rsync version 2.6.9 protocol version 29).

Der Grund: Wenn rsync einen SSH-Tunnel aufbaut, werden die üblichen Initialisierungsfiles von bash nicht geladen und somit auch die MacPorts-Pfade (/opt/local/...) nach Binaries abgesucht.

Abhilfe schafft man, indem man dem lokalen rsync mit dem Argument --rsync-path sagt, wo sich die gewünschte Binary befindet:

$ rsync --rsync-path=/opt/local/bin/rsync -av -e ssh . mario@domain.tld:/tmp

Quelle: How can I set environment variables for a remote rsync process?

Tags: , , , , ,
Labels: Apple, Linux

Keine Kommentare | neuen Kommentar verfassen