[[:mac|{{ :Apple.png?40|}}]] ===== Eigene Installationspakete erstellen ===== In den Developer Tools findet man den PackageMaker, mit dem man sich eigene Installationspakete erstellen kann. Ich muss zB bei jeder Installation eine Fülle von ICC-Profilen, Distiller Settings, Exportvorgaben und PPD Dateien auf dem Mac installieren und erleichtere mir diese Arbeit mit einem Installationspaket, was mir diese Kopierarbeit abnimmt. Dieser Artikel dokumentiert die Erstellung eines solchen Installationspaket. ==== GUI basierte Konfiguration ==== === Basisinformationen === [{{ :mac:pm_1a.png?330|Bild 01}}] [{{ :mac:pm_02.png?330|Bild 02}}] [{{ :mac:pm_03.png?330|Bild 03}}] [{{ :mac:pm_04.png?330|Bild 04}}] [{{ :mac:pm_05.png?330|Bild 05}}] [{{ :mac:pm_06.png?330|Bild 06}}] [{{ :mac:pm_07.png?330|Bild 07}}] [{{ :mac:pm_08.png?330|Bild 08}}] [{{ :mac:pm_09.png?330|Bild 09}}]**(Bild 01)** Wenn man den PackageMaker öffnet, wird man zuerst nach ein paar Basisinformationen gefragt. Da wäre zum einen die ''**Organisation**'', welche man in Form eines Reverse FQDN angeben sollte. Ich verwende hier für meine Installationen zB >>org.prontosystems<<. Diese Information wir als Prefix für das zu erstellende Paket verwendet und dient als Identifier für Ihre Projekte. Erstellen Sie zB ein Paket mit dem Namen >>PostAdobeInstall<< und der zuvor genannten Organisation >>org.prontosystems<<, heißt der Paket Identifier später >>org.prontosystems.postadobeinstall<<, bzw. wenn sich im Paket >>postadobeinstall<< weitere Pakete befinden, werden diese Paket Identifier nochmals hinten drangehängt. Des Weiteren wird das ''**Minimum Target**'' abgefragt, wobei diese Angabe hier etwas irreführend ist, denn an dieser Stelle wird dem PackageMaker lediglich mitgeteilt, welche Art Paket er bauen soll. Im Falle 10.4 oder früher wird ein Bundle based Installations Paket gebaut und im Fall 10.5 oder neuer wird ein Flat Installation Paket gebaut. Da ich bei Neuinstallationen nur noch mindestens ≥ 10.5.x als OS verwende, wähle ich Leopard als Minimum Target aus. Wenn Sie dennoch Minimal-Voraussetzungen für die Installation des Pakets prüfen möchten, steht Ihnen während der Konfiguration des Pakets noch die Möglichkeit >>Settings Installation Requirements<< zu definieren. \\ === Paketkonfiguration === **(Bild 02)** **Configuration:** Im Register >>Configuration<< können Sie unter >>Title<< den Namen einstellen, der später im Installer Dialog angezeigt wird. Der Titel wird __nicht__ für den späteren Paketnamen, der Projektdatei und für den Package Identifier verwendet. Hier verwende ich den Titel >>Post Adobe Installation Paket<<. * **User Sees:** Des Weiteren wird im >>User Sees:<< Feld festgelegt, welches Installations Interface der User später angezeigt bekommt, wählen Sie hier >>Easy Install Only<< um das Standard Interface festzulegen. * **Install Destination:** Bei >>Install Destination<< wird festgelegt, ob und wenn, welche Möglichkeiten für das Zielvolume der User später hat. Da unsere Dateien fest nach >>/Library/Application Support<< kopiert werden, bietet sich nur das >>System Volume<< an und dem User keine weitere Wahlmöglichkeit zu lassen. * **Certificate:** Wenn Sie 10.5 als Minimum Target ausgewählt haben und ein eigenes Zertifikat besitzen, welche Sie identifiziert, können Sie dies hier bei >>Certificate<< mit angeben. Damit wird die Integrität des Pakets und des Erstellers gesichert. ich habe keines, also lassen wir das an dieser Stelle. * **Description:** Im Feld bei >>Description<< können Sie weitere Informationen hinterlegen, die später im Installer angezeigt werden. \\ === Contents === **(Bild 03; Bild 04; Bild 05)** Im linken Feld >>Drop contents here<< können Sie entweder per Drag & Drop oder mit dem + Zeichen unten Links den eigentlichen Inhalt einfügen. Sie können dies entweder mit einzelnen Dateien machen oder aber sogenannte Deployment Root Folders mit dem entsprechenden Inhalt erstellen und diese dort einfügen. Die Variante mit den Verzeichnissen hat den Vorteil, dass Sie nicht bei jeder einzelnen Datei die später noch notwendigen Einstellungen vornehmen müssen, sonder diese nur auf das Verzeichnis vergeben müssen. Die Einstellungen werden dann auf den Inhalt vererbt. In unserem Beispiel werden die Verzeichnisse >>House_Settings<<, >>Customer_Settings<< und >>Kastner_CM<< mit den entsprechenden Dateien als Inhalt angelegt (Bild 03) und in das Contents Feld gezogen. Wenn Sie die links im Contents Feld die Headline (auch Installation Choice genannt) eines Ordners markieren, sehen Sie im Register >>Configuration<< unter >>Initial State<< die Checkboxen >>Selected<<, >>Enabled<< und >>Hidden<<. Selected und Enabled sind bereits aktiviert, was bedeutet, dass später im Installer der User die Möglichkeit hat, die einzelnen Pakete an- oder abzuwählen (Enabled) und dieses Paket bereits angewählt ist. Im Bild 04 sehen Sie zB den Ordner (auch Installation Component package genannt) >>House_Settings<<, welcher standardmäßig aktiviert ist und im Bild 05 den Ordner >>Customer_Settings<<, der standardmäßig abgewählt ist, weil diese Einstellungen nur bestimmte User bzw. nur auf bestimmten Rechnern benötigt werden, die mit diesem Kunden zu tun haben. Auf einer solchen Maschine kann man entweder dann die >>Customer_Settings<< mit aktivieren oder wenn auf dem System, die Basiskomponenten schon vorhanden sind, den Paketinstaller nochmal ausführen und ggf die bereits installierten Settings abwählen und die Custom Settings dafür anwählen. Diese Flexibilität bieten Ihnen diese beiden Checkboxen >>Selected<< und >>Enabled<<. \\ === Configuration === **(Bild 06)** Wenn Sie dann einen Ordner unter der Headline markieren und auf das Register >>Configuration<< wechseln, können Sie im Feld >>Destination<< das Zielverzeichnis angeben in welchen der Inhalt des Ordners auf der Zielmaschine installiert werden soll. Hier scheiden sich ggf die Geister und wir installieren diese Settings in das >>/Libray/Application Support<< Verzeichnis, um sie in jedem User verfügbar zu haben, man könnte sie aber auch in das Application Support Verzeichnis im jeweiligen User Verzeichnis installieren aber das wäre recht umständlich und weil alle User die gleichen Settings benutzen sollen, ist das so die einfachste Lösung. Die Distiller Settings und Exportvorgaben werden demnach nach >>/Library/Application Support/Adobe/Adobe PDF/Settings<< und die ICC-Profile nach >>/Library/Application Support/Adobe/Color/Settings<< kopiert. Die Checkbox >>Allow custom location<< sollte wegen des expliziten Pfades nicht aktiviert werden und der >>Package Identifier<< wird automatisch vervollständigt und sollte nicht einmalig und nicht verändert werden. Durch diesen Identifier identifiziert das System das Paket, legt die entsprechenden BOM- und PLIST-Dateien in >>/var/db/receipts/<< ab, die uA wieder ausgewertet werden, wenn die Zugriffsrechte des Systems überprüft werden oder die installierte Version des pakets ermittelt werden soll, usw. Die >>Package Version<< wird vom System benutzt um festzustellen, ob das Paket uU ein Update eines bestehenden Pakets ist. Sollte ein älteres Paket gefunden werden, wird dieses aktualsiert, ist es noch nicht vorhanden, wird es ganz normal installiert. Diese Option kann hilfreich sein, wenn sich an den Einstellungs-Dateien, die mit diesem Paket auf das System kopiert werden, etwas ändert. Sie können das dieses Installer Paket als Ausgangslage für die neue Version verwenden und brauchen (bzw. müssen dann sogar) an dieser Stelle die Versionsnummer erhöhen. Das Pull-Down Menü bei >>Restart Action<< gibt an, ob ein Neustart des Systems erforderlich ist, was in unserem hier gezeigten Beispiel nicht der Fall ist und die Checkbox bei >>Require admin authentication<< ist unserem Fall erforderlich, da wir unsere Dateien nach >>/Library/*<< kopieren. \\ === Contents === **(Bild 07)** Im nächsten Register >>Contents<< werden die Zugriffsrechte, der Besitzer und die Gruppe der einzelnen Elemente eingestellt. Hier ist es uA ratsam die Elemente abzuwählen, die Sie nicht im Installations Paket haben möchten; zB sind die >>.DS_Store<< Dateien nicht notwendig und deaktivieren Sie ebenfalls die Checkbox bei >>include root in package<<, dadurch wird verhindert das die Ordner, in denen die Konfigurationsdateien liegen, ebenfalls mit installiert werden, was in unserem Beispiel nicht nur nicht notwendig ist, sondern gar eine Fehlkonfiguration darstellen würde. In anderen Szenarien können hier natürlich andere Einstellungen sinnvoll sein. Bei den Berechtigungen habe ich mich dazu entschlossen, den Eigentümer der Dateien auf >>root<< zu setzen und die Gruppe auf >>staff<<, andernfalls würde der derzeitige Benutzer als Eigentümer eingetragen, der aber uU nicht auf der Zielmaschine vorhanden ist. Dafür sorgen die Berechtigungen der Gruppe >>staff<< dafür, dass jeder Benutzer auf dem Zielsystem alle Rechte an den Dateien hat, weil in dieser Gruppe standardmäßig jeder angelegte User auf dem System ist. \\ === Build Package === **(Bild 08)** Nachdem die Konfiguration des Installer Pakets abgeschlossen ist, kompilieren wir es mit einem Klick auf den >>Build<<-Button oben links. Dadurch wird ein fertiges PKG-Paket erzeugt, welches sich wie gewohnt installieren lässt. Sollten Sie ggf Warnungen erhalten, lösen Sie die Konflikte bzw. habe ich bei den .DS_Store Dateien Warnungen bzgl. eines Group-ID Konflikts erhalten, die ich ignoriert habe und ich auch offen eingestehen muss, dass ich im Moment keine Ahnung habe, woher die kommen. Aber da ich die .DS_Store Dateien eh nicht mit in das Installations-Paket übernommen habe, bin ich nicht allzu besorgt, hier einen Fehler mit in das System zu installieren... \\ === Install Package === **(Bild 09)** Wenn Sie jetzt das Installer Paket ausführen, wird Ihnen zB bei >>Zielvolume auswählen<< schon gar keine Möglichkeit mehr gegeben, eines auszuwählen, weil wir dies in der Konfiguration mit dem Abwählen der Option >>allow custom location<< so eingestellt haben und unter Anpassen beim Installationstyp ist das Paket >>Customer_Settings<< erwartungsgemäß standardmäßig abgewählt. \\ --- //pronto 2011/06/10 23:04// {{keywords>package maker mac osx}}