Software/Programme für mehrere Benutzer installieren

Ne, das ist zuviel des Guten. Irgendwann reicht es. Das höchste der Gefühle ist einen User-abhängigen Ordner Applications zu erstellen, ihm die Rechte wie beschrieben zu stutzen und dorthinein die App/das Programm zu installieren.
Du sollst es auch nicht machen. Ich hab nur versucht zu erklären, wozu die unterschiedlichen Library-Ordner sind und daß sie einer klaren Hierarchie folgen. Und was die Reihenfolge ist, wenn eine App Dateien öffnen will. :)
 
Naja. Etwa die Aktivierungsdaten der Software bzw. des Softwarepakets liegen zentral (was es ja auch wohl verunmöglicht, mehrere verschiedene Lizenzen ggf. verschiedener User auf dem gleichen Rechner zu betreiben).
...
Dann ist das vorher Geschriebene/Diskutierte alles für die Tonne. Die Idee war, eine 100%-ige "User-only-Installation" herbeizuführen, ohne Hinweise, Reste, Spuren auf zentraler Ebene.

...
Und falls der MSO-Ordner oder das individuelle Programmpaket nach der Installation von /Programme nach etwa ~/Programme verschoben wird, wird die Installation zwar funktionieren, nicht aber die (Auto–)Updates, die dann ihr Ziel nicht mehr f{i|ä}nden.
...
In meiner Variante wird er nicht ex post verschoben. Sondern während der Installation erst gar nicht dorthin installiert, sondern sofort in das User-spezifische Applications-Verzeichnis. => Siehe mein Hinweis bei "Fensterlein" (besser/akademisch korrekter kann ich es nicht beschrieben, aber ich denke Ihr wißt was ich meine).
Ob das aber eine Rolle spielt, daß es nicht tverschoeben wird, sondern gleich dort landet, weiß ich nicht.

Wen das dennoch stimmt/zutrifft
...
Vermutlich legt MSO nach wie vor (ich vergleiche hier mit dem v2011-Stand) noch Installationsquittungen nach /private/var/db/receipts, wo das Update dann vergeblich nachliest, wo sich sein Ziel befindet.
...
... dann funktioniert es halt nicht, egal wie man es dreht.

...
Wenn also standardmäßig nach ~/Programme installiert wird, muss also ein Admin dafür sorgen, festzulegen, welcher (Nichtadmin–)User auf welche Software zugreifen darf. ...
Das wäre dann, wie schon gesagt, deutlich zu viel des Guten. Dann steht wirklich Aufwand und Nutzen in gar keinem Verhältnis mehr.

PS:
Warum aber schreibst Du jetzt "standardmäßig", während in Deiner vorherigen Ausführung das Szenario beschrieben wurde, wonach es erst nach der (Standard-)Installation manuell verschoben wird, und eben nicht "standardmäßig" im User-spezifischen Zielverzeichnis erfolgt. Das verwirrt jetzt etwas von der Begriffwahl her imho.
 
Zuletzt bearbeitet:
Davon abgesehen muß ich gestehen, ich habe bis jetzt noch nicht kapiert, was Du mit App-Bundles meinst.
Die Apps, die du in /Applications siehst sind sogenannte App-Bundles. Das sind Ordner, die auf .app enden und speziell behandelt werden. Sie werden dir in den höheren Systemebenen, wie dem Finder, nicht als Ordner, sondern als einzelnes Objekt angezeigt.

Wenn du mal das Kontextmenü auf einem App-Bundle öffnest, kannst du "Paketinhalt anzeigen" klicken. Dann siehst du die Ordnerstruktur in so einem Bundle. Auch hier gibt es eine klare Struktur, an die sich alle halten.

Wenn du eine SW startest, lädt es aus diesem Ordner seine Ressourcen, aber auch aus den Libraries. Genaugenommen liegt dieses App-Bundle in der Suchhierarchie ganz am Ende.

Aber ich will dich nicht verwirren, falls dich das nicht wirklich in dieser Tiefe interessiert. Aber ich hoffe aber, daß du vielleicht etwas davon gebrauchen kannst.
 
  • Gefällt mir
Reaktionen: lunchbreak und dg2rbf
Super danke. Ja, ich kann folgen.

PS:
Dieses App-Bundle schiebe ich während der Installation (also wenn das Fenster mit "Quelle >> Ziel" auftaucht) nicht in den vorgeschlagenen zentralen Standard-Zielordner, sondern halte es mit der Maus solange auf dem App-Ordner bis der sich auftut und ich von dort in den zuvor erstellten und rechtebefreiten User-App-Ordner navigiert habe - und dann "droppe" ich es. Funktioniert prima. Ist aber vergebens, wenn sich trotzdem Ressourcen an anderer, zentraler, Stelle einnisten.
 
In meiner Variante wird er nicht ex post verschoben
Klar. Dann hilft aber auch nur ein eigenes Installationsskript (wie weiland die MSI-Skripte für das zentrale Deploiment von Software im Netzwerk) das den gewünschten Installationsort beschreibt. Solche Tools gibt’s auch für Entwickler und Netzwerkverwalter für macOS. Die richten sich freilich nicht an den Endnutzer von Software.

Mit MSO2011 wird ja noch das macOS-Installationsprogramm zum Abspulen des Installationsskriptes verwendet. Dieses nutzt im Installationsdialog nicht die grundsätzlich mögliche Option zur Auswahl eines eigenem Installationsortes. Da Installationsprogramm und das Format des Installationsskriptes hier von Apple (und seinen Entwicklertools) vorgegeben ist, kann es also nicht per se unmöglich sein, für eine angepasste Installation auch den Zielort auswählen zu lassen.

Mein Verdacht ist, dass MS bei einer Software wie Word et al. gar nicht auf die Idee kommt, dass man deren Nutzung nur bestimmten Nutzern erlauben wolle. Und so nebenbei auch etwaigen Versions- und Lizenz-Komplikationen aus dem Weg geht (sonst bräuchte man ja auch noch eine Lizenzverwaltungssoftware auf dem Rechner).

dann funktioniert es halt nicht, egal wie man es dreht.
… es sei denn, die Installationsquittung verzeichnete den geänderten Installationsort. Genau das täte ja Installationsprogramm, wenn das MSO-Installationsskript einen geänderten Ort abfrüge.

Warum aber schreibst Du jetzt "standardmäßig"
Das Risiko bei der Verwendung eines Wortes wie »standardmäßig« (wie auch bei »eigentlich« oder »normalerweise«) ist eines des Fokusses – also worauf es sich gerade mit welchem Bedeutungsumfang bezieht. Wenn dieser Fokus in diesem Thead von Beitrag zu Beitrag – oder gar innerhalb eines Beitrags wechselt, wird’s für den Adressaten tatsächlich verwirrend, was der Verfasser aber nicht zwingend beim Schreiben bemerkt.

»Standardmäßig« für Installationen ist /Programme (weils Apple ganz offenbar so vorgesehen hat). MS wählt aber nur diesen Ort. »Standardmäßig« impliziert aber auch (und Apple verhindert das ja nicht), wenn es zum Standard Alternativen gibt. Sei es als Auswahl im Installationsprogramm, sei es als manuelles Irgendwo-Hinziehen aus einem DMG o.ä.
 
  • Gefällt mir
Reaktionen: dg2rbf
Das
...
... DPI zeigt, dass MS versucht sich da wirklich ganz, ganz tief im System einzunisten - was hier aufgrund eines hier sehr scharf eingestellten Pi-Hole + IPS nicht funktioniert.

Ich möchte mal so zusammenfassen - die Versuche sind ganz kurz auf Rasierklinge vor "Intruder Alert" und "Krieg gegen Microsoft".
bestärkt mich in meiner Vermutung, daß das hier im Thread diskutierte Vorhaben, MS365 userspezifisch sauber und trennscharf zu installieren und v.a. störungs- und auch rückwirkungsfrei auf das Gesamtsystem auf Dauer zu betreiben, nicht von Erfolg gekrönt ist - um nicht zu sagen zum Scheitern verurteilt...
 
Das

bestärkt mich in meiner Vermutung, daß das hier im Thread diskutierte Vorhaben, MS365 userspezifisch sauber und trennscharf zu installieren und v.a. störungs- und auch rückwirkungsfrei auf das Gesamtsystem auf Dauer zu betreiben, nicht von Erfolg gekrönt ist - um nicht zu sagen zum Scheitern verurteilt...
Das ist allerdings eine seit den Urzeiten von Microsoft Office auf Personal Computern geführte Diskussion. Ja, sauber und trennscharf und MS war bislang immer eher die Ausnahme als die Regel - ist aber inzwischen schon deutlich besser geworden, schlimm waren die Zeiten als MS ihre Win-Registry basierten Programmierungen versucht haben einfach 1:1 auf dem Mac mit Crosscompiler zu installieren ... die Älteren werden die Schnitzeljagd durch die Ordner auf der Suche nach MS-Schnipseln noch erinnern ;-).
 
Das bestärkt mich in meiner Vermutung, daß das hier im Thread diskutierte Vorhaben, MS365 userspezifisch sauber und trennscharf zu installieren und v.a. störungs- und auch rückwirkungsfrei auf das Gesamtsystem auf Dauer zu betreiben, nicht von Erfolg gekrönt ist - um nicht zu sagen zum Scheitern verurteilt...
Nein. Das Vorgehen ist exakt das richtige. Die Apps gehören nach /Applications oder ~/Applications und die dazugehörigen Supportdateien gehören nach /Library. Und das, was der/die NutzerIn anlegt, gehört nach ~/Library/ bzw. ~/Documents. Das ergibt eine ganz saubere Trennung.

WAS man MS vorwerfen könnte ist, daß man bei der Installation nicht den User-Ordner als Installationsziel auswählen kann (*). Und auch in diesem Fall wäre es legitim und IMHO auch korrekt, die Support-Daten nach /Library zu schreiben, da sie nunmal nicht nutzerspezifisch sind.

(*) Allgemein gibt es kaum SW, die man über den Installer per User installieren kann. Irgendwie hat sich das nie durchgesetzt. Es ist IMHO auch in 99% aller Fälle überhaupt nicht nötig dies zu wollen, abgesehen von der Recht-zur-Installation-Frage.
 
  • Gefällt mir
Reaktionen: dg2rbf
OK. Nachvollziehbar. Allerdings auch ein klares Statement dafür, daß 100%-trennscharf nicht geht. Es landen wohl immer Dinge im zentralen Bereich, wenn man userspezifisch (so gut man das manuell eben kann) installiert. Diese würden dort nicht landen, wenn man (gar) nicht installiert. Sie sind also eine direkte Folge der usperspezifsichen Installation. Anders ausgedrückt: rückwirkungsfrei auf das Gesamtsystem, 100% trennscharf installieren geht nicht.
 
  • Gefällt mir
Reaktionen: dg2rbf
Ja, sauber und trennscharf und MS war bislang immer eher die Ausnahme als die Regel
Wovon genau redest du genau? Für die Trennschärfe sorgt doch das System selbst.
Die aktuellen Anwendungen tun dank Versandkastung ziemlich genau das, was macOS ihnen erlaubt.
Alle von MSO installierten Komponenten landen da, wo das macOS-Betriebssystemkonzept sie hinzuhaben vorsieht.

Im wesentlichen sind das /Applications alias /Programme; unterhalb /Library für User-übergreifende Komponenten; ~/Library/Application Support und mittlerweile über den Umweg ~/Library/Group Containers; ~/Library/Preferences, sowie eben, aber immer weniger, nach ~/Do{c|k}ument{s|e}.
Alles für Softwareinstallationen normale und vorgesehene Orte. Und auch die schon genannten Installationsquittungen für und von Installationsprogramm in /private/var/db/receipts sind keine Ausnahme.

MSO schreibt auch nichts nach /System, wozu auch? Es gibt keine .kext, die sich »tief ins System« eingrüben; anders übrigens, als so’n poleliger Druckertreiber. ./Launch Agents und ./Launch Daemons von MSO operieren nur auf der Ebenen von /Library, nicht in /System/Library.
 
Wovon genau redest du genau? Für die Trennschärfe sorgt doch das System selbst.
...
Ich kann es nich besser erklären, als in den mehreren hier geposteten Beiträgen.

Letzter Versuch mit meinen Worten:
User installiert ein Programm auf einem Mac und möchte, daß es auf dem Mac auch nur für sich (den installierenden Nutzer) sehbar/ausführbar/updatebar ist. Andere User sollen das Programm nicht sehen und auch nicht starten / nutzen können. Zudem sollen sich keine Hinweise auf die Existenz dieses Programms für andere als den installierenden Nutzer finden lassen. Lupenreine Trennung und rückwirkungsfrei auf andere User was Betrieb und Updates angeht.
 
Letzter Versuch mit meinen Worten:
Jaja – das habe ich schon verstanden. Nur dàs ist nicht das Betriebskonzept irgendeines aktuellen präemptiven Mehrbenutzerbetriebssystems.
Spätestens Root würde wissen können, was da bei Usern läuft. Schließlich ist sie Herrin im undemokratischen Haus des Betriebssystems. Was immer die achso private Software da treibt, sie muss sich beim Betriebssystem anmelden und um Prozess(or)zeit und Arbeitspeicher bitten. Da bleibt schon bauartbedingt nix privat.
 
  • Gefällt mir
Reaktionen: lunchbreak
Es geht erst mal nur um Office (MS365), das nur ein User soll nutzen können.

VG
 
Wenn ich ein Programm für nur einen bestimmten User (sagen wir User1 - dieser soll kein Admin sein und keine Admin-Rechte habe) auf der Maschine haben - installieren möchte, ...

... und wenn ich außerdem erreichen will, daß kein anderer Nutzer auf der Maschine dieses Programm "sieht" und "aufrufen" kann, ...
... und wenn ich weiterhin erreichen will, daß dieses Programm im Launchpad des User1 erscheint, ...

... dann gehe ich wie folgt vor:
  1. Ich logge mich als User1 ein.
  2. Ich erstelle im Homeverzeichnis von User1 ein Verzeichnis namens 'Applications'. Das mache ich im Terminal mit dem Befehl "md Applications".
  3. Ich switche in das Verzeichnis 'Applications'. Das mache ich im Terminal mit dem Befehl "cd Applications".
  4. Danach tippe im Terminal ein "touch .localized" und schaue mit "ls -la" ob eine Datei names ".localized" in 'Applications"' angelegt wurde.
Danach gebe/entziehe ich dem Verzeichnis 'Applications' via Finder / rechte Maus-Aktion Rechte gemäß dieser Aufstellung (dazu benötige ich/der User1 Kenntnis über die Adminkennung und das Admin-PW).

Nun kann ich als User1 Programme installieren, und zwar in das User1-spezifische Verzeichnis 'Applications', das sich im Finder unterhalb des User1-Homeverzeichnis als 'Programme' kenntlich macht. Hier muß man ein wenig aufpassen, wenn man eine *dmg-Installation ausführt, daß man das Programm auch wirklich das richtige Zielverzeichnis 'User1/Programme' "schiebt".

Ergebnis:
  • Nur user1 kann das Programm sheen/ausführen. Andere Nutzer auf der Maschine nicht. :)
  • Das Programm kann über das Dock/das Launchpad geöffnet werden (wenn User1 eingeloggt ist, klar). :)
Finde ich gut.

PS:
Jetzt bleibt nur noch abzuwarten und zu beobachten, ob die automatischen Update-Routinen von Programmen mit der so angelegten Logik auch "automatisch" zurecht kommen. Ich hoffe aber schon.
 
  • Gefällt mir
Reaktionen: agrajag
Ich würde hier gern nochmal eine Frage zum Thema "Programme nur für bestimmte Nutzer installieren" stellen. Im Vorpost #74 habe ich ja beschrieben, wie man da vorgehen kann. Das Szenario bezieht sich aber auf die klassische Installation über ein *.dmg-File.

=>
Was ist nun aber, wenn ich auf einem Rechner 3 User habe

1 x Admin ohne Apple-ID "A",
1 x Standard ohne Apple-ID "S1",
1 x Standard mit Apple-ID "S2")

... und S2 bezieht ein Programm über den App Store?

Folgende Fragen:
  1. Kann man in diesem Szenario auch steuern, ähnlich wie in #74 beschrieben, wo die App/das Programm "hin"installiert wird, oder landet es automatisch im übergeordneten "Programme"-Verzeichnis für alle User?

  2. Wenn sie (die App) im übergeordneten "Programme"-Verzeichnis für alle User landen sollte, kann A und S1 die App dann nutzen, obwohl A und S1 gänzlich ohne Apple-ID auf dem Rechner arbeiten?

  3. Falls 2. zutrifft, wie kann man es schaffen, analog zu #74, daß die App wirklich nur für S2 sichtbar und aufrufbar ist?
macOS = Monterey.

Danke für den richtigen Denkanstoß.

VG
 
Zuletzt bearbeitet:
Ich würde hier gern nochmal eine Frage zum Thema "Programme nur für bestimmte Nutzer installieren" stellen. Im Vorpost #74 habe ich ja beschrieben, wie man da vorgehen kann. Das Szenario bezieht sich aber auf die klassische Installation über ein *.dmg-File.

=>
Was ist nun aber, wenn ich auf einem Rechner 3 User habe

1 x Admin ohne Apple-ID "A",
1 x Standard ohne Apple-ID "S1",
1 x Standard mit Apple-ID "S2"

... und S2 bezieht ein Programm über den App Store?

Folgende Fragen:
  1. Kann man in diesem Szenario auch steuern, ähnlich wie in #74 beschrieben, wo die App/das Programm "hin"installiert wird, oder landet es automatisch im übergeordneten "Programme"-Verzeichnis für alle User?

  2. Wenn sie (die App) im übergeordneten "Programme"-Verzeichnis für alle User landen sollte, kann A und S1 die App dann nutzen, obwohl A und S1 gänzlich ohne Apple-ID auf dem Rechner arbeiten?

  3. Falls 2. zutrifft, wie kann man es schaffen, analog zu #74, daß die App wirklich nur für S2 sichtbar und aufrufbar ist?
macOS = Monterey.

Danke für den richtigen Denkanstoß.

VG

Kann da jemand was zu sagen?

Danke & VG
 
Das kannst du doch schnell selbst ausprobieren. Ich halte das Szenario für unwahrscheinlich, das Gerät wird entweder in einer Familie oder einer Firma genutzt. Dann ist es in der Regel an eine Apple-ID gebunden wegen MDM oder alle Anwender haben eine AppleID, um die Familien-"Vorteile" nutzen zu können.
Ich begreife aber auch den Ansatz "ich trau dir nicht, teile aber ein Gerät mit dir" nicht. Dann sollte jeder Anwender ein eigenes Gerät haben und gut ist...
Wenn ich ein Gerät an einen Gast verleihe (oder externen Berater im Firmenumfeld), dann darf der Gast da nix drauf installieren und ich mache es halt nach Rückgabe schnell wieder platt, dann ist auch alles in Butter.
Private Gäste brauchen normalerweise keinen Computerzugriff mehr, die haben eh alle mehr mobile Geräte dabei, als ich Rechner im Haus habe...
Und bei der klassischen LAN Party bringt je jeder seine Hardware mit (falls es sowas überhaupt noch gibt).
 
Danke für Deine Meinung. Es ging mir aber hier nur darum, ob jemand aus Erfahrung was zu den spezifischen Punkten sagen kann. Also ob und wie man Einfluß darauf nehmen kann, wo eine via App Store zu installierende Software hininstalliert wird. VG

...
=>
Was ist nun aber, wenn ich auf einem Rechner 3 User habe

1 x Admin ohne Apple-ID "A",
1 x Standard ohne Apple-ID "S1",
1 x Standard mit Apple-ID "S2"

... und S2 bezieht ein Programm über den App Store?

Folgende Fragen:
  1. Kann man in diesem Szenario auch steuern, ähnlich wie in #74 beschrieben, wo die App/das Programm "hin"installiert wird, oder landet es automatisch im übergeordneten "Programme"-Verzeichnis für alle User?

  2. Wenn sie (die App) im übergeordneten "Programme"-Verzeichnis für alle User landen sollte, kann A und S1 die App dann nutzen, obwohl A und S1 gänzlich ohne Apple-ID auf dem Rechner arbeiten?

  3. Falls 2. zutrifft, wie kann man es schaffen, analog zu #74, daß die App wirklich nur für S2 sichtbar und aufrufbar ist?
macOS = Monterey.
...
 
Korrektur:
...
  1. Ich logge mich als User1 ein.
  2. Ich erstelle im Homeverzeichnis von User1 ein Verzeichnis namens 'Applications'. Das mache ich im Terminal mit dem Befehl "md mkdir Applications".
  3. Ich switche in das Verzeichnis 'Applications'. Das mache ich im Terminal mit dem Befehl "cd Applications".
  4. Danach tippe im Terminal ein "touch .localized" und schaue mit "ls -la" ob eine Datei names ".localized" in 'Applications"' angelegt wurde.
...
 
Danach gebe/entziehe ich dem Verzeichnis 'Applications' via Finder / rechte Maus-Aktion Rechte gemäß dieser Aufstellung (dazu benötige ich/der User1 Kenntnis über die Adminkennung und das Admin-PW).
Nur damit ich es richtig verstehe und es auch an dieser Stelle der Vollständigkeit halber genannt wird: Dem von dir auf diese Weise erzeugten und lokalisierten Ordner „Programme“ im Ordner des Users1 müssen dann folgende Rechte zugewiesen werden:

(Ich): Lesen & Schreiben
staff: existiert nicht
everyone: Keine Rechte

[Edit: Rechtschreibung korrigiert]
 
Zurück
Oben Unten