Schlagwort-Archive: Software

macOS Sierra

Veröffentlicht am von

Vor nunmehr fünf Wochen hat Apple sein aktuelles Computerbetriebssystem macOS Sierra veröffentlicht. Neben Neuerungen wurden aber auch einige Änderungen unter der Haube durchgeführt.
Eine wesentliche was die Kompatibilität mit älteren Programmen betrifft, ist der Wegfall der Garbage Collection für das Handling des Arbeitsspeichers der Programme. Hat ein Programm auf dieses gesetzt, so wird es nach dem Upgrade leider nicht mehr ausführbar sein, da Apple die Unterstützung für den Garbage Collector in Sierra entfernt hat. Um also vor dem Upgrade prüfen zu können, ob Programme mit Sierra kompatibel sind oder nicht, kann man mit folgenden Befehl im Terminal dies überprüfen, um hinterher keinen Reinfall zu erleben. Allerdings muss für die Prüfung Xcode installiert sein.:

Befehl:

otool -oV /Applications/PROGRAMMNAME.app/Contents/MacOS/PROGRAMMNAME | tail -3

Ausgabe:

Contents of (__DATA,__objc_imageinfo) section
  version 0
    flags 0x6 OBJC_IMAGE_SUPPORTS_GC

Sollte in der Terminalausgabe nun „OBJC_IMAGE_SUPPORTS_GC“ erscheinen, so kommt noch der Garbage Collector zum Einsatz und das Programm ist unter macOS Sierra nicht mehr lauffähig.

Außerdem ist Apple beim Einsatz von OpenSSH von Version 6.x auf 7.x gewechselt. Die Entwickler von OpenSSH haben aber in der Major-Version 7.0 eine wesentliche Änderung vorgenommen, was das automatische Laden von SSH-Schlüsseln in den ssh-agent betrifft. Hat man sich früher mit dem lokalen Mac via SSH auf einen anderen Rechner eingeloggt und sich dann wiederum von diesem mittels Public-Key-Verfahren auf einen weiteren Rechner verbunden, so hat der lokale SSH-Client sowohl Privat-Key als auch die Passphrase in den ssh-agent hinein geladen. Dies funktioniert seit Version 7 nicht mehr. Um sich dennoch Schlüssel und Passphrase des Man-in-the-middle-Computers wieder in den Agent seines lokalen Computers dauerhaft laden zu können, reicht es, wenn man in die benutzereigene Client-Konfiguration folgende Option hinzufügt.

echo "AddKeysToAgent yes" >> ~/.ssh/config

Des weiteren lässt sich wie gewohnt der macOS-Installer auf einem GPT-vorformatierten USB-Stick mit folgendem Konsolenbefehl kopieren, so dass dieser auch für künftige Installationen ohne Internetverbindungen ein Rettungssystem beinhaltet.

sudo /Applications/Install\ macOS\ Sierra.app/Contents/Resources/createinstallmedia --volume /Volumes/Stick --applicationpath /Applications/Install\ macOS\ Sierra.app/ --nointeraction

HandBrake und El Capitan

Veröffentlicht am von

Mit El Capitan hat Apple im OS X die System Integrity Protection (SIP) eingeführt, welche bestimmte Ordner im Root-Dateisystem noch einmal zusätzlich vor unberechtigten Zugriff schützen soll. Da HandBrake bisher zum Rippen von DVD’s seine libdvdcss in /usr/lib speicherte, wird diese von der SIP mit OS X 10.11 nun unter Quarantäne gestellt, um den Kernel zu schützen. Dadurch ist es leider nicht mehr möglich DVD’s zu rippen, oder verschlüsselte ISO-Dateien mit der normalen DVD-Applikation wiederzugeben. Abhilfe wird dadurch geschafft, dass man sich mit einem Paket-Manager das libdvdcss-Paket nachinstalliert und die Bibliothek in einem Unterordner des /usr – Verzeichnis kopiert, welches von SIP standardmäßig nicht zusätzlich geschützt wird.
In meinem Fall habe ich die Bibliothek mit Hilfe MacPorts nachinstalliert und die Datei libdvdcss.2.dylib aus dem Verzeichnis /opt/local/lib nach /usr/local/lib kopiert. Somit ist HandBrake wieder versorgt. DVD-ISO’s lassen sich alternativ mit dem VLC-Player wiedergeben, da er seine eigene Codec-Bibliothek mitbringt.

Speichermedien grundieren mit f3write / f3read

Veröffentlicht am von

Das Thema ist zwar schon älter, aber es kommt wohl immer noch vor, dass USB-Sticks oder SD-Karten mit gefälschten Kapazitätsangaben in Umlauf gebracht werden. Auch wenn diese aus seriösen Quellen stammen, sollte man sie auf die korrekte Kapazität und Funktionsfähigkeit prüfen, bevor man darauf unwiederherstellbare Daten aufzeichnet. So schreibt beispielsweise eine Kamera fröhlich 32 GB auf eine Karte, die tatsächlich nur 8 GB fasst. Die Daten sind dann hinüber. Außerdem kann die Karte auch einfach nur defekt sein, oder die versprochene Schreibgeschwindigkeit nicht halten.

Für die gängigen Unixoiden Betriebssysteme kann man f3write / f3read benutzen. Dabei wird der Datenträger mit einem verifizierbaren Muster beschrieben und dieses wird im Anschluss wieder gelesen.

Vorher muss der Source-Code aber an einem Ort der Wahl innerhalb des Dateisystems entpackt und mit ‚make‚ kompiliert werden.

sommteck:f3-6.0 franky$ ./f3write /Volumes/USB-Stick/
Free space: 3.78 GB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK! 
Creating file 3.h2w ... OK!
Creating file 4.h2w ... OK!
Free space: 0.00 Byte
Average writing speed: 4.40 MB/s
sommteck:f3-6.0 franky$ ./f3read /Volumes/USB-Stick/
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 1631936/        0/      0/      0
 
  Data OK: 3.78 GB (7923392 sectors)
Data LOST: 0.00 Byte (0 sectors)
	       Corrupted: 0.00 Byte (0 sectors)
	Slightly changed: 0.00 Byte (0 sectors)
	     Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 20.70 MB/s

Idealerweise kann man vielleicht noch Aliases in der .profile erstellen, um die Tipperei auf der Konsole zu reduzieren.

Außerdem gibt es das Programm als native Cocoa-GUI-Variante. Aber diese gefällt mir persönlich nicht so gut, weil sie keine so detaillierten Statusinformationen liefert.

Update

Inzwischen kann man f3write/f3read auch mittels MacPorts und HomeBrew automatisiert installieren. Zudem ist der Quellcode auf GitHub verfügbar.

Link: https://github.com/AltraMayor/f3

Erstellen eines S/MIME-Zertifikats unter Mac OS X

Veröffentlicht am von

Nicht immer lässt sich GnuPG als e-Mail-Verschlüsselungslösung auf allen Geräten benutzen, da dafür Plug-Ins nötig sind, die nicht für alle Plattformen verfügbar sind. Im Gegensatz zu GnuPG ist S/MIME in den Mail-Programmen bereits integriert. Es funktioniert aber genauso mit Schlüsselpaaren.

Damit man auf dem Mac S/MIME benutzen kann, braucht man zuerst einmal ein Zertifikat. Es gibt einige Stellen, die einem auch kostenlos ein solches Zertifikat ausstellen, doch reicht es eigentlich schon, selber ein Zertifikat zu erstellen. Der Unterschied dabei ist, dass ein selbsterstelltes Zertifikat per se als “nicht überprüfbar” ausgewiesen wird. Es geht also in erster Linie um das Vertrauen.

S-MIME-Zertifikat_erstellen_0

Um ein Zertifikat auf dem Mac zu erstellen, benutzt man das Programm “Schlüsselbundverwaltung”, welches sich im “Dienstprogramme”-Ordner befindet. Im Menü “Schlüsselbundverwaltung” wählt man unter “Zertifikatassistent” den Eintrag “Zertifikat erstellen”. Im sich nun erscheinenden Fenster müssen Schrittweise Einstellungen vorgenommen werden. Hier die einzelnen Schritte in Bildern:

Schritt 1:

S-MIME-Zertifikat_erstellen_1

Hier ist es wichtig, die Option “Standardwerte überschreiben” zu wählen, sofern man mehr als eine e-Mail Adresse im System eingetragen hat. Ansonsten nimmt der Assistent einfach die Adresse, welche als “Hauptadresse” eingestellt ist.

Schritt 2:

S-MIME-Zertifikat_erstellen_2

In diesem Schritt wird die Dauer der Gültigkeit festgelegt. Voreingestellt ist 1 Jahr.

Schritt 3:

S-MIME-Zertifikat_erstellen_3

Nun folgen allgemeine Angaben zur Person bzw. Firma, für welche das Zertifikat erstellt wurde. Bei e-Mail Adresse muss man nun die e-Mail Adresse wählen, für welche das Zertifikat erstellt werden soll.

Schritt 4:

S-MIME-Zertifikat_erstellen_4

Diese Einstellungen können getrost so belassen werden.

Schritt 5:

S-MIME-Zertifikat_erstellen_5

In diesem Schritt wird ausgewählt, wofür das Zertifikat verwendet werden soll. Am besten einfach genau so einstellen, wie im Bild.

Schritt 6:

S-MIME-Zertifikat_erstellen_6

Für welche Dienste das Zertifikat verwendet wird, wird in diesem Schritt angegeben. Für uns reicht die Option “e-Mail-Schutz”.

Die restlichen Schritte können so belassen werden, wie sie voreingestellt sind. Beim letzten Schritt klickt man auf “Erstellen” und dann hat man sein selbsigniertes Zertifikat erstellt und erscheint in der Liste der Zertifikate in der Schlüsselbundverwaltung.

Da wir unserem Zertifikat ja bestimmt selber vertrauen, sollten wir dies auch angeben. Dazu auf das neu erstellte Zertifikat doppelklicken, um das Informationsfenster dazu zu öffnen. Unter dem Eintrag “Vertrauen” können wir nun diese Einstellung vornehmen:

S-MIME-Zertifikat_erstellen_7

Ein weiterer Vorteil von S/MIME gegenüber von GPGMail ist, dass dieses auch unter iOS funktioniert (seit iOS 5). Somit braucht man nicht auf ein eher umständliches Drittanbieter-Programm umzustellen. Um S/MIME unter iOS verwenden zu können, müssen die Zertifikate zuerst auf die iDevices gebracht werden. Am einfachsten geschieht dies, indem man sich selbst eine e-Mail schickt, an welche die Zertifikate angehängt sind. Die Zertifikate können aus der Schlüsselbundverwaltung zu diesem Zweck exportiert werden.

Nun die E-Mail auf dem iPhone bzw. iPad öffnen und auf das angehängte Zertifikat klicken. So wird man nun schrittweise durch die Installation geführt.

Apache Logfiles anonymisieren oder abschalten

Veröffentlicht am von

Soweit ich das richtig verstanden habe, dürfen nach dem deutschen Recht Webserver keine IP-Adressen abspeichern, solange sie aus technischen oder geschäftlichen Gründen nicht zwingend erforderlich sind. (siehe TMG §15)

Das gilt sowohl für den Webserver als auch für Kommentare in den Content-Managemand-Systemen. Ein Apache ist in der Standardeinstellung aber nicht nach der deutschen Rechtslage voreingestellt. Mit ein paar Zeilen in der Konfiguration lassen sich die Logfiles eines Webservers anonymisieren oder ganz abschalten.

Logfiles anonymisieren

Eine Möglichkeit ist das anonymisieren von Logfiles. Die Einträge werden dabei weiterhin in die Dateien geschrieben – doch mit entfernter IP-Adresse. Unter Ubuntu 14.04 wechselt man in das Konfiguraionsverzeichnis /etc/apache2/conf-available/ und öffnet die Datei other-vhosts-access-log.conf, um die Logeinstellungen für vHosts zu ändern. Eine neue Zeile wird hinzugefügt:

LogFormat "[IP] %l %u %t \"%r\" %>s %b" vhost_combined

Danach muss der Webserver neu gestartet werden:

service apache2 reload

Statt der echten IP eines Clients erscheint nun „[IP]“ in den Logfiles.

Auf ähnliche Weise wird die Einstellung für die Errorlogs geändert. Die Datei /etc/apache/apache2.conf öffnen und folgende Zeile hinzu fügen:

ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client [IP]] %M"

Logfiles abschalten

Wer ganz auf den Accesslog verzichten kann, kann diesen auch ganz abschalten und so Ressourcen sparen. Dazu wird in /etc/apache2/conf-available/other-vhosts-access-log.conf einfach die Zeile „CustomLog …“ mit einem vorangestellten „#“-Zeichen auskommentiert. Dasselbe gilt für den Errorlog: Hier muss in /etc/apache2/apache2.conf die Einstellung „ErrorLog“ auskommentiert werden.

Nach jeder Konfigurationsänderung ist ein Neuladen der Konfiguartionsdateien nötig, damit die Einstellung aktiv werden.

service apache2 reload

Update: 12.10.2019 18:00 Uhr

Ich habe mich ja für das vollständige Abschalten der Logfiles entschieden, wenn ein HTTP-Client auf dieses Blog Anfragen schickt.

Um die Access-Logs zu deaktivieren, reicht es nach wie vor aus, die Zeile „CustomLog …“ in der Datei /etc/apache2/conf-available/other-vhosts-access-log.conf aus zu kommentieren.
Um die Fehler-Logs zu deaktivieren, reicht es hingegen beim meinem aktuell eingesetzten Apache nicht mehr, die Zeile „ErrorLog“ in der Datei /etc/apache2/apache2.conf einfach mit einem „#“-Zeichen aus zu kommentieren. Der Apache stört sich stattdessen daran, dass kein Wert für diese Konfiguartion in der Datei vorhanden ist und verweigert das neue Einlesen der Datei bei ihm als einen bereits laufenden, beziehungsweise er würde sich gar nicht erst als Dienst starten lassen. Alternativ lässt sich die Abschaltung des Loggings von gescheiterten Anfragen in der Datei wie folgt konfigurieren.:

…
# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a 
# container, error messages relating to that virtual host will be
# logged here.  If you *do* define an error logfile for a 
# container, that host's errors will be logged there and not here.
#
#ErrorLog ${APACHE_LOG_DIR}/error.log
ErrorLog /dev/null

#
# LogLevel: Control the severity of messages logged to the error_log.
# Available values: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the log level for particular modules, e.g.
# "LogLevel info ssl:warn"
#
#LogLevel warn
…