PackageMaker und Zugriffsrechte

[Tekl]

Hi,

ich möchte gerne einen Installer bereitstellen, wo man wählen kann ob etwas nach "/Library/Dictionaries" oder "~/Library/Dictionaries" installiert werden soll. Damit es unter "/Library/Dictionaries" klappt, muss ich im PackageMaker ankreuzen, dass Admin-Rechte nötig sind.

Doch durch die Admin-Rechte klappt das dann nicht mehr im Benutzerordner (~/Library/Dictionaries) wenn unter ~/Library der Unterordner Dictionaries noch gar nicht existiert. Dieser wird dann zwar automatisch angelegt, aber mit flaschen (System-) Rechten, so dass die Installation fehlschlägt.

Weiß jemand wie man den Ordner Dictionaries mit Benutzerrechten anlegen kann, obwohl man dem Installer Admin-Rechte gegeben hat?

 

[Tekl]

Ein weiteres Problem sind die Failure Messages unter Requirements, da kann ich nur in einer Sprache was angeben, aber ich hätte es gerne auf nicht deutschen System auf Englisch.

 

[MacMark]

Das sollte der OS X-Installer können. Mach ein passendes Installerpaket für diesen und bleib mir bloß weg mit einem "eigenem Installer".

 

[Tekl]

Äh? Ich will ja einen OS-X-Installer erstellen, oder wie darf ich deine Aussage verstehen?

 

[MacMark]

Installer.app kann beliebige Pakete installieren. Auch Deine. Du benötigst keinen eigenen Installer.

 

[Tekl]

Ich meine ja so Pakete, eben das Dinger die der PackageMaker erstellt. Ich will ein Paket erstellen, wo ich wählen kann, ob's für alle Benutzer oder nur für den aktuellen Benutzer installiert wird. Prinzipiell ist es ja möglich, doch macht Installer.app da ja Murks oder ich habe das Paket eben falsch erstellt, deswegen ja auch meine Frage, wie ich das Paket erstellen muss.

 

[MacMark]

Wenn Du es "relocateable" machst, kann der User bestimmen, wo es hin kommt. Doku dazu gibt es komplett bei Apple online.

 

[Tekl]

Der Anwender soll aber nicht nachträglich das Installierte Verzeichnis verschieben (Zitat Apple zu relocatable: "A relocatable component is one that may be moved by the user after it’s installed."), sondern im Vorfeld einfach nur zwischen /Library oder ~/Library auswählen können. Das klappt ja auch so weit, nur gibt es da mit den Rechten Probleme.

Also es soll eigentlich wie im Screenshot sein, nur funktioniert das nicht. Die Doku von Apple ist nicht hilfreich, sonst müsste ich hier auch nicht fragen.

 

[MacMark]

Die Benutzerrechte definierst Du auch in Deinem Paket, das dem Installer gefüttert wird. Im schlimmsten Fall definierst Du noch ein PostFlight-/PostInstall-Skript, das es einstellt

 

[Tekl]

Nun, die Rechte sind in beiden Fällen ja unterschiedlich. Das Problem mit den falschen Rechten des automatische angelegten Dictionaries-Ordners konnte ich auch mit einem PreInstall-Skript beheben.

Ich möchte aber, dass bei der Installation in den Benutzer-Ordner nicht nach dem Admin-Rechten gefragt wird, was ja auch nicht nötig ist. Deaktiviere ich aber die Option "Require Admin authentication", klappt die Installation nicht mehr im /Library-Verzeichnis auch wenn ich Admin-User bin.

 

[MacMark]

Vielleicht ein Bug im PackageMaker/Installer. Schreib es mal hier rein:
http://bugreport.apple.com

 

[Tekl]

Wenn's wirklich ein Bug in Installer.app ist und der in 10.5.6 gefixt würde, müssten ja alle auf 10.5.6 updaten, um das Paket nutzen zu können.

Ich habe schon öfter mal Bugs bei Apple gemeldet, ohne Erfolg. Auch in deren Foren bekommt man keine Antworten. Dann muss ich wohl zwei Pakete bereitstellen oder die Anwender müssen unbedingt ein Admin-Kennwort eingeben.

 

[sedna]

Hallo Tekl!

Nein, das ist kein Bug im PackageMaker!

In der "Doku" ist das doch beschrieben. (Die gibt es übrigens auch "offline": /Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.DeveloperTools.docset/Contents/Resources/Documents/documentation/DeveloperTools/Conceptual/PackageMakerUserGuide)

Administrator-authentication requirement (Require admin authorization): Specifies whether the user must authenticate as an administrator of the computer before performing the install. This is needed when the user can install a product in one of the privileged file-system domains, such as the local domain (for example, /Applications). You don’t need to select this option when the user can install your package only on their home directory (see “Product Package Configuration Pane” for more information).
Install effect: The Installer application displays the Mac OS X Authentication dialog. If the user who authenticates is not an administrator of the computer, the installation process does not proceed.

Link

Auf deutsch: Wenn man dem User die Wahl zwischen Local Domain und Home Directory läßt, muß das Passwort in beiden Fällen eingegeben werden.
Ich finde übrigens, dass nichts gegen einen netten selbstgestrickten Installer spricht, auch wenn MacMark anderer Meinung ist.
Es scheint hier auch nicht ganz klar zu sein, was "relocatable" bedeutet.

When the user installs a relocatable component a second time on
the same computer, the Installer application searches for the component’s existing files in additional locations in the file system, not just the location at which the component was installed, according to the Installer package database).

Sedna

 

[Tekl]

Hallo Sedna,

Danke für die Klarstellung, so eindeutig habe ich die Doku allerdings nicht interpretiert. Dir ist nicht zufällig ein Trick bekannt, das zu umgehen? Ich bekam nämlich schon öfter mal Anfragen, ob man meine Plugins nicht auch für Benutzer installierbar machen könnte, die keinen Zugang zu einem Admin-Account haben. Ich dachte das müsste doch in einem Package gehen. Komisch finde ich, wenn ich den Haken bei "Require admin ..." weglasse und dann als Admin was installiere, dass es dann trotz Eingabe des Kennworts fehlschlägt.

Das mit dem Relocateable habe ich jetzt begriffen, bislang hatte es halt nie funktioniert, weswegen ich dachte, dass ich da was missverstehe. Ich musste erst mit Exhaustive search arbeiten, damit es klappt.

Hast du eigentlich eine Idee, wie ich mit xattr das Bundle Bit setze? Ich konnte dazu nix finden.

 

[MacMark]

… Ich finde übrigens, dass nichts gegen einen netten selbstgestrickten Installer spricht, auch wenn MacMark anderer Meinung ist.
Es scheint hier auch nicht ganz klar zu sein, was "relocatable" bedeutet.…

Gegen selbstgestrickte Installer spricht, daß sie nicht Apples Empfehlung entsprechen. Erste Wahl ist Drag & Drop-Installation; zweite Wahl ist, falls Dinge verteilt werden müssen, der OS X-Installer. Aus Sicherheitsgründen sind Drittinstaller nicht zu verwenden. Der OS X-Installer löst den Security-Agent für Paßwortabfragen aus, Drittinstaller mögen gerne das Paßwort selbst haben. Dann können sie es auch gleich speichern oder rausschicken.

Relocatable bedeutet, daß man das Programm verschieben darf nach der Installation und dabei eine erneute Installation nicht nur in an der vom Installer-Package angegebenen Stelle nach vorhandenen Dateien sucht, sondern auch woanders, also das verschobene Programm auch an nicht-angegebener Stelle findet.
Wenn die Installation nicht relocatable ist, dann wird bei erneuter Installation die verschobene alte Version nicht beachtet und an Standardstelle neu installiert.

 

[Pii]

Ich finde übrigens, dass nichts gegen einen netten selbstgestrickten Installer spricht, auch wenn MacMark anderer Meinung ist.

Selbstgestrickte Installer-Apps sind ein absolutes NoGo. Ganz besonders wenn so eine Installer-App höhere Rechte benötigt.

 

[Tekl]

Ich wäre eh nicht in der Lage mir einen zu basteln. Doof ist aber bei Apples Installer, dass er keine Möglichkeit bietet einen Uninstaller bereitzustellen, obwohl die Grundlagen mit den Receipts ja schon lange existieren.

 

[MacMark]

Wenn Du ein Dictionary ergänzt, dann muß der Benutzer auch nur dieses eine Verzeichnis beseitigen. Wozu ein Uninstaller dafür?

 

[Tekl]

Für die Dictionaries benötige es eigentlich nicht, aber trotzdem reicht es nicht aus, nur den Ordner zu löschen, da ja noch die unnötige Receipt-Datei und Einträge in einer plist liegen bleiben.

Ich meinte das mit der Uninstall-Möglichkeit eigentlich eher generell, da viele Programme ja noch etwas mehr Ballast durch die Gegen schleudern.

Erste Wahl ist Drag & Drop-Installation; zweite Wahl ist, falls Dinge verteilt werden müssen, der OS X-Installer.

Prinzipiell müsste in meinem Fall ja eine Drag'n'Drop-Installation reichen, doch dann müsste ich aufwändig erklären wie man die Hintergrundprozesse vom Lexikon abschießt, damit nicht ein Neustart nötig ist, um die Plugins verfügbar zu haben. Der Installer kann das ja automatisiert erledigen.

 

[sedna]

Oh, da habe ich ja eine kleine Diskussion losgetreten … das war gar nicht meine Absicht

Tekl!
Zu deiner Frage bezüglich xattr:
Da müßtest Du schon ein bisschen ausholen, damit man sich den Zusammenhang nicht selber zusammenreimen muß, was ich hiermit mal tue:

Du möchtest mit einem PostScript Bundle Bits verändern und kannst deshalb nicht SetFile nehmen (da es ja nicht zwangsweise auf dem betreffenden Mac installiert ist).
Warum? Was hast Du vor? Es geht bestimmt um eine "kosmetische" Anpassung, denn funktionieren sollten deine installierten Files auch so.
(f)setxattr ist meines Wissens nach nicht dafür geeignet. Das "pure" xattr wohl erst recht nicht.

Ich schreibe jetzt mal was, was durchaus angewandt wird, auch wenn es nicht im Sinn von Apple sein dürfte. Es gibt einige Programme, die still und heimlich SetFile mitbringen (mit verschleiertem Namen) und ihre Aufgaben damit erledigen...

Sedna