Posts Tagged ‘macOS’

Donnerstag, 14. Oktober 2021

OpenInTerminal meldet „Waiting…“

Vor einiger Zeit habe ich hier im Artikel Öffne Terminal mit dem aktuellen macOS Finder-Pfad über die macOS Finder-Erweiterung OpenInTerminal geschrieben.

Folgendes Problem tritt dabei periodisch auf: Klickt man auf das Finder-Icon, heisst es im aufklappenden Dialog lapidar „Waiting…“

Die Lösung, eine Antwort auf meinen Bug-Report: Option-Klick auf Finder und Relaunch anwählen.

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 29. August 2021

/dev/disk unter macOS deutlich langsamer als /dev/rdisk

Kürzlich beim zurückschreiben eines SD-Card RPi Backups auf eine neue SD-Card:

Starting imaging './emeidi-dashboard.img' to /dev/disk4 ...
^C11128+0 records in
11127+0 records out
11667505152 bytes transferred in 3849.682711 secs (3030771 bytes/sec)
Done.

3030771 bytes/sec, das sind 2959 kilobytes/sec oder 2.89 megabytes/sec. Eine 32GB SD-Card schreibt man also in 11’072 Sekunden, das heisst … in unglaublich langen 3 Stunden.

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 9. Mai 2021

setlocale: LC_ALL: cannot change locale

Seit ich mein MacBook Air mit M1-Chip und macOS Big Sur verwende, erhalte ich beim Login auf meinen Raspberry Pi 3 über SSH folgende Warnung zu Gesicht:

ssh dashboard
Linux DASHBOARD 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l
Last login: Sat May  8 05:00:24 2021
-bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

Ursache des Problems: en_US.UTF-8 ist in /etc/locale.gen kommentiert:

$ cat /etc/locale.gen | grep -v "^#"

en_GB.UTF-8 UTF-8

Somit die Datei öffnen, die Zeile mit en_US.UTF-8 suchen, ent-kommentieren, speichern und dann folgenden Befehl ausführen:

# locale-gen

Via: warning: setlocale: LC_ALL: cannot change locale

Beim nächsten Login erscheint die Fehlermeldung nicht mehr.

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

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 16. März 2021

csshx läuft unter macOS Big Sur nicht mehr

Ich verwende csshx unter macOS gelegentlich, um mich gleichzeitig auf mehrere Linux-Maschinen zu verbinden und dann auf allen Maschinen dieselben Kommandos auszuführen.

Unter macOS Big Sur läuft csshx auf Anhieb nicht (mehr):

$ csshx
Unimplemented: POSIX::tmpnam(): use File::Temp instead at /System/Library/Perl/5.28/darwin-thread-multi-2level/POSIX.pm line 185.
Unimplemented: POSIX::tmpnam() at /usr/local/bin/csshX line 1130.
BEGIN failed--compilation aborted at /usr/local/bin/csshX line 1130.

Die Lösung:

$ defaults write com.apple.versioner.perl Version -string 5.18

Quelle: csshX not working on Mac OS Big Sur

Tags: , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 23. Februar 2021

iMac auf Mac mini M1 migrieren wird zu Mac mini M1 frisch aufsetzen

Vorweg: Apples macOS-Team hat hier mehrere Male grossen Mist gebaut. Unmöglich, dass ein Normalanwender diese Probleme selber lösen könnte.

Ein Bekannter hat sich kürzlich ein gebrauchtes iPhone 11 Pro geleistet.

Ein paar Tage nach dem Kauf nahm er Kontakt mit mir auf und fragte mich, wieso die Photos.app auf seinem iMac nur die Vorschaubilder der mit dem neuen iPhone geschossenen Photos anzeige, nicht aber das Original, wenn man es in der Grossansicht öffnet.

Der Fall war für mich rasch klar: HEIC. Beim iMac handelte es sich um das Early 2008-Modell, welches bis macOS El Capitan (10.11) aktualisiert werden konnte, welches vor fünf Jahren erschienen war. Unmöglich, dass die darunter laufende Photos.app HEIC versteht.

Selbstverständlich hätte ich den Bekannten nun anweisen können, das iPhone so zu konfigurieren, dass es Bilder anstelle im HEIC-Format als JPEG in iCloud Photos ablegt. Doch welcher verantwortungsbewusste ITler nutzt die Gunst der Stunde nicht, um einen solchen Bekannten zu überzeugen, doch den 13-jährigen iMac und das fünfjährige macOS mit etwas Modernem zu ersetzen?

Wir schauten uns auf Revendo kurz einige gebrauchte iMacs an, unter welchem Big Sur noch installierbar ist — doch angesichts des Wechsels der Prozessorarchitektur tendierte ich nach einem kurzen finanziellen Überschlag dazu, anstelle eines Intel-iMacs doch lieber einen Mac mini M1 mit einem höher auflösenden Bildschirm mit 22–24 Zoll Diagonale zu kaufen. Ein iMac M1 wäre mir lieber gewesen, doch dieses Teil wird wohl erst irgendwann einmal in diesem Jahr erscheinen.

Die Wahl fiel auf einen Mac mini M1 mit 8G RAM und 512GB SSD, sowie einen Dell P2421DC. Tastatur und Maus würde ich ihm schenken, da ich noch ein Magic Keyboard und eine Magic Mouse (beide mit Lightning-Ladeanschluss) herumliegen hatte.

Nachdem die Ware per Post eingetrudelt war, machte ich mich auf den Weg zum Bekannten, um die Migration vorzunehmen. Ich verband den iMac mittels Ethernet-Kabel mit dem Mac mini, startete auf beiden Geräten den Migration Assistant, und sagte dem Mac mini, dass er nun alle Kontos und Daten vom iMac herüberkopieren sollte. Der Vorgang benötigte über vier Stunden, angabegemäss mit einer Übertragungsrate von 20 MBit/s (dem iMac hatten wir vor einigen Jahren zum Glück eine SSD verpflanzt, sonst hätte der Kopiervorgang vermutlich noch deutlich länger gedauert). Da ich noch einen anderen Termin wahrnehmen musste, wies ich den Bekannten an, die Migration gelegentlich mitzuverfolgen und die Installation danach auf dem Mac mini abzuschliessen, sobald alle Daten kopiert worden sind.

Am Abend meldete der Bekannte, dass alles geklappt hätte, er nun aber ein Problem habe, das neueste macOS Big Sur-Update einzuspielen: Der Mac mini akzeptiere im Software Update-Dialog das Kennwort seines Benutzerkontos nicht — Logins nach einem Neustart funktionierten hingegen. Nichts half — Neustart, Kaltstart, neues Admin-Konto einrichten. Das Internet ist voll mit Geschichten zu diesem Problem.

Nach vermutlich einer Stunde hin und her sandte mir der Bekannte mit dem iPad angefertigte Bildschirmfotos des Migrationsassistenten (zum Glück hatte er diese selbst angefertigt, aber zu meinem Pech hatte er mir das bis 60 Minuten in den Supportfall nicht erzählt). Und da las ich zu meinem Schrecken:

Sorry. An error occurred while transferring your information.

Die Autorisierung zum Erstellen neuer Benutzer auf dem System konnte nicht erhalten werden.

Der Bekannte führte die Installation anschliessend fort, realisierte aber nicht, dass macOS ihn nun aufforderte, ein neues Benutzerkonto zu erstellen. Das tat er brav.

Als ich das realisierte, erklärte ich Abbruch der Übung. Der neue Ansatz für den nächsten Tag war: Mac mini M1 platt machen, macOS Big Sur fabrikneu installieren, Benutzerkonto manuell erstellen und die Daten von iMac dann manuell rüberkopieren.

Am nächsten Tag also die Plattmacherei: Ich bootete den Mac mini M1 in den Recovery-Modus, indem ich die Power-Taste betätigte und zehn Sekunden lang gedrückt hielt. Ich wechselte in das Disk Utility und löschte („Erase“) die zwei Macintosh HD- und die Data-Partition und formatierte sie als AFPS neu. Anschliessend liess ich macOS auch über die Recovery Console neu installieren.

Ich aktivierte den Mac mini, und danach wollte ich den initialen Benutzeraccount erstellen. Nachdem ich die Informationen in das Formular eingefüllt hatte, klickte ich auf „Continue“ … und dann passierte für gefühlte 10 Minuten lang nichts. Schlussendlich die Fehlermeldung:

Computer account creation failed

Your computer account could not be created with the name and password specified. Please try again.

Der Klick auf „Try Again“ brachte nix.

Nach einigen Recherchen im Netz dann die Erkenntnis, dass man in der schönen, neuen ARM64-Welt die Macintosh HD- und Data-Partition nicht einfach platt machen darf. Stattdessen müsse man den Mac mini in den Device Firmware Update (DFU)-Modus booten und einen Restore durchführen. Dazu sei ein USB-C auf USB-C-Kabel nötig, sowie ein zweiter Mac (egal ob Intel oder ARM).

Zum Glück gibt es in unserem Haushalt zwei MacBook 12 Zoll, davon eines in meinem Besitz. Dieses musste nun zusammen mit einem Original Apple USB-C-Ladekabel für den Restore herhalten.

Doch hier nun das nächste Problem: Den Mac mini in den DFU-Modus zu booten, ist mit vielen Fallstricken umgeben. Schlussendlich half dieses Video eines Dritten (wie peinlich, wenn Apples Supportseiten weniger helfen als YouTube-Videos):

Apple Configurator 2 muss aus dem App Store heruntergeladen und gestartet werden. Wichtig ist dann, das USB-C-Kabel vom MacBook an den USB-C-Anschluss direkt neben dem Ethernet-Port des Mac minis anzuschliessen. Anschliessend zieht man das Stromkabel aus dem Gerät, zählt auf fünf, drückt den Stromschalter und steckt während man den Schalter gedrückt hält das Stromkabel ein.

Apple Configurator 2 zeigt nun mit einem riesigen Symbol und dem Schriftzug DFU an, dass der Mac mini im DFU-Modus läuft.

Anschliessend klickt man mit der rechten Maustaste auf das Symbol und wählt Restore aus. Der Mac mini wird gelöscht, partitioniert und danach das aktuellste macOS heruntergeladen und frisch auf den Mac mini rüberkopiert.

Und endlich, bei diesem nun mehr dritten Anlauf den Mac mini aufzusetzen klappte die Installation endlich wie am Schnürchen: Ich konnte das Benutzerkonto einrichten und das Konto erhielt auch tatsächlich Administratorenrechte. Jetzt endlich läuft die Kiste, und wie!

Nachtrag

According to the small print in Apple’s Platform Security Guide, when you set up a new M1 Mac, or set one up after restoring it in DFU mode, the primary admin account created is special: it’s the Owner account of that Mac. During that inital setup, the Mac sends a request to Apple for that Mac’s signed Owner Identity Certificate (OIC). This is based on a private key generated in the Secure Enclave known as the Owner Identity Key (OIK).

Each M1 Mac has just a single OIK, and access to that is confined to that primary admin user of the internal SSD, who is thus its Owner.

Quelle: Last Week on My Mac: The perils of M1 Ownership

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

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 1. Dezember 2020

Mehrere Unix Timestamps auf der macOS Kommandozeile in Daten umwandeln

Voraussetzung: MacPorts und das Utility gdate (unter Linux: date) (Teil des Pakets coreutils) sind installiert.

$ python -mjson.tool < netatmo.json | grep utc | cut -d ":" -f 2 | awk '{print $1}' | xargs -I '{}' gdate -d "@{}"
Mon Nov 30 22:28:06 CET 2020
Mon Nov 30 22:27:57 CET 2020
Mon Nov 30 22:28:03 CET 2020
Mon Nov 30 22:27:38 CET 2020
Mon Nov 30 22:28:03 CET 2020
Mon Nov 30 22:28:03 CET 2020
Mon Nov 30 22:28:03 CET 2020
Mon Nov 30 17:07:34 CET 2020
Mon Nov 30 17:07:21 CET 2020
Mon Nov 30 17:07:21 CET 2020
Mon Nov 30 20:03:52 CET 2020
Mon Nov 30 20:03:52 CET 2020
Mon Nov 30 20:03:52 CET 2020
Mon Nov 30 20:03:52 CET 2020
Mon Nov 30 20:03:46 CET 2020
Mon Nov 30 22:07:42 CET 2020
Mon Nov 30 22:07:00 CET 2020
Mon Nov 30 22:07:07 CET 2020

Im vorliegenden Fall nahm mich Wunder, wann meine Netatmo-Sensoren das letzte Mal einen Wert an den Server übertragen hatten.

Mindestens zwei Stationen mit einer handvoll Sensoren haben den Wert seit gestern nicht mehr aktualisiert. Ich vermute auf Grund dieses Absturzes.

Hierzu lud ich über die Netatmo API das JSON mit den Daten aller meiner Stationen herunter, gab das JSON schön formatiert aus (ein Key-Value Pair pro Zeile), selektierte die Zeilen mit dem Attribut time_utc, isolierte deren Wert — die Unix Timestamp (ein Integer), entfernte die Leerzeichen vor und nach dem Wert und übergab die Liste der Werte mittels xargs dem Tool gdate zur Umwandlung in ein menschenlesbares Datum.

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 8. März 2020

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

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, 8. März 2020

Unter Linux Nicht-ASCII-Charakter in einer Datei ausgeben

Unter Linux verwendet man folgenden Befehl:

$ grep --color='auto' -P -n "[^\x00-\x7F]" dump.txt

Quelle: How do I grep for all non-ASCII characters?

macOS‘ grep unterstütz dies leider nicht.

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 1. März 2020

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

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

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