Diskimage vergrößern

Disk Images kennt jeder von Software-Installationen am Mac. Viele Apps am Mac gelangen in dmg-Dateien zum Kunden. Diese sind wie eine virtuelle Festplatte, die per Doppelklick erst auf dem Mac gemountet wird und dann den Zugriff auf ihre Inhalte gewährt. Wenn Time Machine-Backups auf einem Netzwerk-Volume wie einem NAS gespeichert werden, wird im Hintergrund ebenfalls mit diesen Disk Images gearbeitet. Diese haben zudem die Fähigkeit, sich dynamisch zu vergrößern (sog. mitwachsende Images). Wenn das Backup weiter wächst, wird das Image im Hintergrund automatisch vergrößert.

Images sind auch eine praktische Möglichkeit, wichtige Dateien geschützt abzulegen, denn sie lassen sich bei Bedarf verschlüsseln. Beim Anlegen von mitwachsenden Images muss man dennoch eine Dateigröße des Images angeben, im Beispiel 100 MB.

Mitwachsendes Image mit 100 MB Größe anlegen

Mitwachsendes Image mit 100 MB Größe anlegen

Will man nun eine Datei in das Image kopieren, die dessen Gesamtgröße übersteigt, passt sich die Image-Größe nicht automatisch an:

Nicht genügend freier Platz

Um das Image zu vergrößern, muss es erst ausgeworfen werden. Anschließend kann man mit einem Terminal-Befehl die neue Größe festlegen. In diesem Fall wollen wir die Image-Größe von 100 MB auf 1 GB erweitern:

hdiutil resize -size 1g Ortundnamedesimages.dmg

Anschließend hat das Image 1 GB und die Datei kann erfolgreich in das Image kopiert werden.

Datei erfolgreich kopiert, Restspeicherplatz wird oben angezeigt.

Datei erfolgreich kopiert, Restspeicherplatz wird oben angezeigt.

Veröffentlicht in Apple

Remote-Administration unter OS X El Capitan

RemoteDesktopApp

Apples erstes Software-Update für El Capitan, Version 10.11.1 hat es in sich für Admins und Support-Mitarbeiter. Liest man sich die Informationen zum Sicherheitsinhalt durch, die Apple hier bereitgestellt hat (https://support.apple.com/de-de/HT205375), steht dort unter dem letzten Punkt:

SecurityAgent
Verfügbar für: OS X El Capitan 10.11
Auswirkung: Ein Schadprogramm kann programmatisch Aufforderungen der Schlüsselbundverwaltung steuern
Beschreibung: Es bestand eine Methode für Programme, bei Schlüsselbund-Aufforderungen synthetische Klicks zu erzeugen. Dieses Problem wurde behoben, indem synthetische Klicks für Fenster der Schlüsselbundverwaltung deaktiviert wurden.
CVE-ID
CVE-2015-5943

Schön und gut, sollte man meinen, Apple hat also eine weitere Schwachstelle ausgeräumt. Konkret ging es darum, dass Schadsoftware bekannt geworden war, die die genaue Position von Dialogfeldern auf dem Computerbildschirm ausfindig machen und selbst betätigen konnte, also z.B. selbständig auf ‚OK‘ klicken.

Apple hat diese Lücke in OS X 10.11.1 mit Fokus auf Warnmeldungen des Schlüsselbundes geschlossen, ist allerdings möglicherweise über das Ziel hinausgeschossen: Die Schlüsselbundverwaltung erlaubt seither nur noch Eingaben von verifizierten Eingabegeräten. Ein per Remote-Sitzung mit Apple Remote Desktop, Bildschirmfreigabe oder TeamViewer verbundener Anwender (typischerweise ein Administrator oder Support-Mitarbeiter) zählt nicht dazu. An einem Mac mit OS X 10.11.1 werden sämtliche entfernte Eingaben in Schlüsselbund-Dialogfenstern oder auch in der Schlüsselbundverwaltung ignoriert! Übrigens selbst dann, wenn ein Anwender lokal vor dem Rechner sitzt und auf Anweisung des remote zugeschalteten Support-Mitarbeiters auf das Feld klicken will. Im System.log erscheint dann folgende Fehlermeldung:

SecurityAgent: Ignoring User action since the dialog has received events from an untrusted source

ARDCautionWie Apple sich zukünftig die Administration eines Macs mit OS X 10.11.1 in einer entfernten Co-Location ohne physikalischen Zugriff vorstellt, ist mir schleierhaft. Lösungshinweise in den Kommentaren sind herzlich willkommen!

Referenzen:

https://discussions.apple.com/thread/7305746?start=0&tstart=0

Veröffentlicht in Allgemein, Apple, Sicherheit

El Capitan und Software Update Server

Softwareaktualisierung-Appstore

Dieser Artikel ist nicht mehr aktuell, das beschriebene Problem wurde zwischenzeitlich durch ein Software-Update von Apple behoben.

Man kann noch so viel testen und mit Beta-Versionen arbeiten, manche Probleme werden einfach erst „in freier Wildbahn“ entdeckt. So geschehen mit Apples neuester Betriebssystemversion OS X 10.11 El Capitan und der neuen Server-Version 5.
Ist am Server der Caching-Dienst sowie der Software-Aktualisierungsdienst aktiviert, bekommen Clients im lokalen Netzwerk (die auf den Software-Aktualisierungsserver eingestellt sind) die verfügbaren Software-Updates zwar noch angezeigt, aber wenn diese installiert werden sollen, bricht der Ladevorgang bei 0 KB ab.

Im System-Log erscheint zeitgleich folgende Fehlermeldung:

Oct 27 20:39:24 xserve AssetCache[93595]: #7sadM4t2Eeo7 Request by "Softwareaktualisierung" for http://192.168.0.111:55399/content/downloads/43/63/zzzz031-36002/5cnamdr2ij90oyafgyjlcwcyrvzly6j71r/CoreFP.pkg?source=xserve.example.de%3A8088 denied because the source is not whitelisted

Offenbar hat Apple irgendwo eine statische Liste vertrauter Domains fest hinterlegt. Der lokale Software-Aktualisierungsserver ist dort natürlich nicht hinterlegt und deshalb wird das Update für den Client nicht freigegeben.

Man beachte, dass der Prozess AssetCache das Update nicht freigibt. Das bedeutet, dass der Caching-Server die Finger im Spiel hat. Da ich weder in den Config-Dateien noch in den Serveradmin-Settings im Terminal eine Möglichkeit gefunden habe, den Server der Whitelist hinzuzufügen, gibt es derzeit für mich nur eine Möglichkeit, den Software Update Server mit Server 5 und El Capitan zu nutzen: indem man den Caching-Dienst ausschaltet.

SUS-Server5Mit OS X 10.11.1 und Server 5.0.15 ist das Problem übrigens nicht nicht behoben. Wir warten …

Update

Mit OS X 10.11.2 gehört der Fehler der Vergangenheit an. Software Update Server und Caching Server können also wieder parallel benutzt werden.

Wer mehr über die Hintergründe und über andere Workarounds zum Problem erfahren möchte, lese hier weiter: https://onemoreadmin.wordpress.com/2015/10/21/the-evil-triangle-el-capitan-sus-and-caching/

Veröffentlicht in Apple, OS X Server

High-End Animation mit dem Mac

Mac Setups: A High-End Animation Studio

Quelle: Mac Setups: A High-End Animation Studio

Veröffentlicht in Allgemein, Apple, Business, OS X Server

TRIM in OS X Yosemite aktivieren

SSD-Gehäuse

Mit dem am 30. Juni 2015 veröffentlichten OS X 10.10.4 hat Apple die Möglichkeit eingebaut, auf nachträglich installierten SSDs den TRIM-Befehl zu aktivieren. Dieser war bislang nur auf von Apple gelieferten SSDs verfügbar. Folgender Terminal-Befehl ist nötig, um TRIM zu aktivieren:

sudo trimforce enable

Daraufhin erfolgt folgende Warnmeldung, die man bestätigen muss. Danach startet das System neu und TRIM ist aktiv.

IMPORTANT NOTICE:  This tool force-enables TRIM for all relevant attached
devices, even though such devices may not have been validated for data
integrity while using TRIM.  Use of this tool to enable TRIM may result in
unintended data loss or data corruption.  It should not be used in a commercial
operating environment or with important data. Before using this tool, you
should back up all of your data and regularly back up data while TRIM is
enabled.  This tool is provided on an “as is” basis. APPLE MAKES NO WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF
NON-INFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE,
REGARDING THIS TOOL OR ITS USE ALONE OR IN COMBINATION WITH YOUR DEVICES,
SYSTEMS, OR SERVICES. BY USING THIS TOOL TO ENABLE TRIM, YOU AGREE THAT, TO THE
EXTENT PERMITTED BY APPLICABLE LAW, USE OF THE TOOL IS AT YOUR SOLE RISK AND
THAT THE ENTIRE RISK AS TO SATISFACTORY QUALITY, PERFORMANCE, ACCURACY AND
EFFORT IS WITH YOU.
Are you sure you wish to proceed (y/N)? y
Your system will immediately reboot when this is complete.
Is this OK (y/N)? y
Enabling TRIM…
.
.
Operation succeeded. Your system will reboot momentarily, please wait…

Veröffentlicht in Apple