Software/Programme für mehrere Benutzer installieren

Weil beim einfachen gedankenlosen Installieren die Installation "zentral" für alle erfolgt- und nicht wie man gemeinhin glauben könnte, nur für den User, der die Installation ausführt.
Mir ist schleierhaft, wie man denken könnte, daß Programme als Standardfall nur für einen einzelnen Benutzer installiert würde. Warum liegen die Programme dann dann außerhalb des Benutzerordners in einem eigenen Programmordner?
 
Eventuell könnte man sich sowas bauen. Z.B. könnte man mit Hazel /Applications überwachen. Wenn eine neue App installiert wurde, das Bundle nach ~/Applications des installierenden (= des aktuellen aktiven) Nutzers verschieben. Es müsste dann diese Hazel-Action bei jedem Nutzer-Account aktiv sein. Und für den Admin lässt man es. So könnte man dann Apps via Admin-User für alle installieren.

Ich hab das noch nicht ausprobiert. Aber das wäre mein erster Gedanke dazu.
 
  • Gefällt mir
Reaktionen: lunchbreak
Hallo @thorstenhirsch :

Leider geht das so sorgenfrei nicht. Denn wenn immer individuelle User drauf los installieren, müllen sie sich nicht ihren eigenen Account zu - sondern im Endeffekt alle Accounts. Weil beim einfachen gedankenlosen Installieren die Installation "zentral" für alle erfolgt- und nicht wie man gemeinhin glauben könnte, nur für den User, der die Installation ausführt. Insofern ist das leider Wunchdenken, ... und geht leider so direkt und aufwandsarm nicht.

Heißt: User x installiert -> alle sehen es / haben es. Leider.

Bedauerlich. Ist mir schon aufgefallen, besonders da Windows fragt, wenn mehrere Benutzer vorhanden sind: Nur für diesen Benutzer oder für alle Benutzer installieren.

Mir ist schleierhaft, wie man denken könnte, daß Programme als Standardfall nur für einen einzelnen Benutzer installiert würde. Warum liegen die Programme dann dann außerhalb des Benutzerordners in einem eigenen Programmordner?

Mir ist schleierhaft warum die Logik sagt, wenn ich unter Benutzer A was installiere, Benutzer B davon betroffen ist. Noch schleierhafter ist mir, dass es im Umkehrschluss, keine Abfrage dazu gibt.
 
  • Gefällt mir
Reaktionen: lunchbreak
Bedauerlich. Ist mir schon aufgefallen, besonders da Windows fragt, wenn mehrere Benutzer vorhanden sind: Nur für diesen Benutzer oder für alle Benutzer installieren.
Macht Mac OS auch.
 
  • Gefällt mir
  • Wow
Reaktionen: lunchbreak und gishmo
Kommt drauf an ob es einen Installer gibt oder ob es nur per drag&drop "installiert" wird.
 
Warum haben nicht alle dann einen Installer? Das ist ja gelinde gesagt, Schrott.
 
Weil viele Apps keinen brauchen? Da kann man doch das Programm hinziehen wo man möchte. 🤷‍♂️
 
Warum haben nicht alle dann einen Installer? Das ist ja gelinde gesagt, Schrott.
Nö, denn in 95% aller Fälle besteht das, was du da installiert haben willst, aus einem App-Bundle. Wenn man sich mal anschaut, was ein PKG mitbringt, dann wird man feststellen, daß auch hier überwiegend nur ein App-Bundle nach /Applications kopiert wird.

Erst wenn Dateien an mehrere Orte installiert werden sollen, lohnt sich der Einsatz eines Installers. Z.B. wenn neben dem App-Bundle auch noch Dateien nach /Library kopiert werden sollen. Wie z.B. Templates, Symbolbibliotheken und dergleichen. Also Dinge, die für alle Nutzer, aber unabhängig von der eigentlichen Applikation installiert werden sollen. Programm-Updates betreffen nur das App-Bundle und so muß nur das App-Bundle erneuert werden, nicht aber die ganzen Support-Dateien, die schon mal in die Gigabytes gehen können.

In diesem Zusammenhang baut Apple IMHO großen Mist, wenn sie in ihre SW (Garage-Band, Pages, Keynote, etc.) diese Daten alle ins App-Bundle integrieren. In /Applications sollten ausschliesslich App-Bundles liegen, die nur das essenzielle enthalten. Templates und Irgendwas-Bibliotheken (Muster, Werkzeuge, Symbole etc.) sind streng genommen eher Nutzerdaten. Sei es systemweit oder für einzelnutzer. Wenn ich zum Beispiel aus Gründen bestimmte Templates oder Bibliotheken entfernt haben möchte, dann lösche ich sie halt aus den entsprechenden /Library/Application Support bzw. ~/Library/Application Support Ordnern heraus. Und wenn die SW updates bekommt, ändert sich an diesen Daten nicht.

Wenn ich aber diese (eigentlich Nutzerdaten) im App-Bundle liegen habe, MUSS ich sie streng genommen behalten, weil App-Bundles EIGENTLICH nicht vom Nutzer angefasst werden SOLLTEN. Ich KÖNNTE mir dann also die Mühe machen, diese ungewollten Dateien aus dem Bundle zu entfernen, hab aber dann das Problem, daß sie nach jedem Update wieder da sind.

Das mag für die allermeisten vielleicht unsinnig erscheinen dies tun zu wollen, aber es gibt Situationen, wo man genau das aber gerne wollen würde. Ein Grund wäre z.B., bestimmten Personen nur speziell angefertigte Templates oder Bibliotheken zur Verfügung zu stellen uns sie nicht ständig mit den unnützen Templates zu konfrontieren.

Im Übrighen ist daß, was ich in Windows ständig zu sehen bekomme absoluter Schrott. Wieso zur Hölle wird niemand gesteinigt, wenn er echte Nutzerdaten in den Programmeordner schreibt? Wie z.B. dieser furchtbare Sophos-VPN, der die Profile in seinem Anwendungsordner ablegt?!? Was ist denn das bitte für ein Murks?!? Eine SW, die das unter macOS versuchen würde, wäre sofort wieder von der Platte geputzt. Und auch unter Windows wäre diese Sophos-VPN von mir direkt wieder gelöscht worden. Wenn schon an so elementaren Strukturen gepfuscht wird, möchte ich NICHT deren Programmierarbeit sehen.
 
  • Gefällt mir
Reaktionen: lunchbreak, pk2061, Mister79 und eine weitere Person
Erst wenn Dateien an mehrere Orte installiert werden sollen, lohnt sich der Einsatz eines Installers. Z.B. wenn neben dem App-Bundle auch noch Dateien nach /Library kopiert werden sollen
… wobei auch diese App-Bundles bei Erststart durch den jeweiligen User Objekte nach ~/ und darunter kopieren (also etwa nach unterhalb./Documents oder ./Library). Auch das ist das Ergebnis eines Installationsskriptes im Programmpaket.

Und ja…
Da kann man doch das Programm hinziehen wo man möchte.
… was üblicherweise ausreicht, um Anwendungen, die nur éin User nutzen soll, in einem Ordner im Benutzerverzeichnis zu installieren; praktischerweise ist niemand gehindert, in ~/ einen Ordner namens ./Programme (oder so) anzulegen.

Und bezüglich des Thread-Titels »Programme für mehrere Benutzer installieren« ist’s ja gerade die Ablage eines Programms in /Programme alias /Applications durch den dafür Berechtigten, dass diese Anwendungen dann standardmäßig allen Nutzern bereitstehen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Macs Pain
Bei Installationen über Installationsprogramm.app ohne Zielpfadauswahl könnte man formvollendet das Installationsskript aus dem Installationspaket ziehen, darin den Installationspfad anpassen, das gepatchte Skipt zurück ins Installationspaket legen, dann installieren lassen.
Macht man damit nicht eine eventuell vorhandene Signatur des Pakets ungültig?
 
Ich beschreibe nur das Prinzip.
Letztlich passiert da nichts anderes, als wenn ein Admin zentral Anwendungen oder Updates im Netz distribuieren will und dazu das Installationsskript seinen Bedürfnissen (oder denjenigen der betroffenen User) nach anpasst.
 
Nö, denn in 95% aller Fälle besteht das, was du da installiert haben willst, aus einem App-Bundle. Wenn man sich mal anschaut, was ein PKG mitbringt, dann wird man feststellen, daß auch hier überwiegend nur ein App-Bundle nach /Applications kopiert wird.

Erst wenn Dateien an mehrere Orte installiert werden sollen, lohnt sich der Einsatz eines Installers. Z.B. wenn neben dem App-Bundle auch noch Dateien nach /Library kopiert werden sollen. Wie z.B. Templates, Symbolbibliotheken und dergleichen. Also Dinge, die für alle Nutzer, aber unabhängig von der eigentlichen Applikation installiert werden sollen. Programm-Updates betreffen nur das App-Bundle und so muß nur das App-Bundle erneuert werden, nicht aber die ganzen Support-Dateien, die schon mal in die Gigabytes gehen können.
...
Wie verhält es sich denn mit den Office-Programmen?

Also jene, die man als MS365-Abonnent von Microsoft runterladen kann, um sie dann zu installieren? (Ihr seht, ich spreche explizit nicht von der Installation über den Apple App-Store, sondern von dem Weg sich nach Login auf sein MS-Konto die Installationsdateien von MS herunterzuladen).

=>
Würde denn für die Installation von Office in ein "User-spezifisches " Verzeichnis (also z.B. in einen Ordner names Applications unterhalb des Home-Verzeichnisses, dem man dann die staff-Rechte entzieht damit wirklich nur der besagte User das Programm nutzen kann) funktionieren?

=>
Und würden die Updates "sauber" (sprich: für den User only) durchlaufen? Oder käme es spätestens dann zu Konflikten (z.B. weil MS dann automatisch wieder in den allgemeinen Programme-Ordner hinein versucht upzudaten?)

Sind ernst gemeinte Fragen. Ziel der Aktion (wie zu erwarten): MS365 restriktiv nur für einen Nutzer der Maschine zugänglich zu haben. Andere Nutzer sollen das MS nicht nur nicht nutzen, sie sollen es gar nicht erst sehen.
 
...

Und bezüglich des Thread-Titels »Programme für mehrere Benutzer installieren« ist’s ja gerade die Ablage eines Programms in /Programme alias /Applications durch den dafür Berechtigten, dass diese Anwendungen dann standardmäßig allen Nutzern bereitstehen.
Ja, das stimmt. Wobei im weiteren Verlauf des Threads (vom Ausgangspost und ein paar weiteren mal abgesehen) es eher um das genaue Gegenteil ging/geht. Nämlich Programme User-spezifisch so zu installieren, daß sie eben nur und ausschließlich von dem installierenden User gesehen und benutzt werden können.

Meine Frage in #54 ist deshalb, am konkreten Beispiel von MS365, ob dieses Vorgehen rückstands- und rückwirkungsfrei funktioniert.

dieses Vorgehen = Installation in ein Verzeichnis "Applications" hinein, welches extra im User-Ordner angelegt wurde und dem danach der staff-Eintrag entzogen (weggelöscht) wurde und der everyone-Eintrag (den kann man nicht löschen) von Nur Lesen auf Keine Rechte abgeändert wurde.
 
Wie verhält es sich denn mit den Office-Programmen?
Der Installer im wesentlichen nach
  • Applications
  • Library
    • Application Support
      • Microsoft
    • LaunchDaemons
    • PriviledgedHelperTools
Die App-Bundles könntest du auch nach ~/Applications verschieben, wenn es nur für ein Nutzer sichbar sein soll (unabhängig von der Frage der Sinnhaftigkeit).

Programme, die ihren eigenen Updater mitbringen (meist nutzen sie dann das Sparkle Framework), lassen sich ohne Probleme updaten, egal an welchem Pfad sie liegen. Mir fallen gerade nur zwei Programme (BusyCal und BusyContacts) ein, die den System-Paketinstaller zum Updaten benutzen und hier werden die Updates immer nach /Applications geschrieben. Keine Ahnung, ob das am System-Paketinstaller liegt.

In diesem konkreten Fall bringt MS Office seinen eigenen Updater mit, von dem ich dir leider auch nicht sagen kann, ob der Apps an einem beliebigen Pfad updaten kann. Im Zweifel infach ausprobieren. Wenn du das austestest, gib bitte mal eine Rückmeldung. Das würde mich auch interessieren.
 
  • Gefällt mir
Reaktionen: dg2rbf
Ich bin mir noch nicht sicher, ob ich wagen soll.

Wenn ich das hier lese, dann scheint es nicht so einfach zu sein. Demnach fuchtelt MS365 immer in den zentralen Ordnern (Library und so) herum. Und das tut es (oder versucht es) dann bestimmt auch, wenn ich es in einen lokalen "User-Unterordner" namens Applications mit entzogenen Rechten installiere. Was ich ja, wie oben in #54 geschrieben, befürchtet habe und so halt einfach nicht möchte. Mal sehen.
 
Die Ordner in /Library und ~/Library sind unabhängig von der Position des App-Bundles.

macOS ist in mehrere Domänen aufgeteilt:
  • User: ~/Library/
  • Local: /Library/
  • Network: (hab ich real nie gesehen, keine Ahnung was der Pfad ist)
  • System: /System/Library/
Wenn eine App eine Ressource sucht, z.B. beim Start der App selbst, sucht sie bestimmte Ressourcen in den genennten Domänen in dieser Reihenfolge ab und nummt die, die sie zuerst findet. Auf diese Weise kannst du Daten per User oder für alle lokalen oder gar für alle innerhalb einer Netzwerkgruppe bereitstellen.

Du kannst auch eine Ressource aus /Library/ (für alle lokalen Nutzer) nehmen, ein Duplikat machen und an die entsprechende Stelle in deinem ~/Library/ ablegen und nach deinen Wünschen anpassen. Wenn du nun die dazugehörige App startest, wird deine modifizierte Ressource geladen, wenn an anderer User die App startet, nimmt es die aus /Library/.

Das ist das, was ich an macOS von Anfang an toll fand. Es gab eine relativ klare Struktur, wo was zu liegen hat. Leider hatte sich Apple selbst sehr gerne NICHT daran gehalten. Ok, die Adressbuchdaten, da kann man sich drüber streiten, ob sie nach ~/Library/Adressbook gehört hätten, aber die Mails waren für mich immer ein klarer Kandidat für ~/Library/Application Support/Mail.

dl;dr: ich würde im Fall von MS nicht mein Leben drauf verwetten, aber du solltest ohne Probleme die App-Bundles woandershin verschieben können und alles läuft wie gehabt. Lediglich bei den Updates müsstest du schauen, ob der sie in-place aktualisiert, oder sie wieder nach /Applications schreibt (dann hast du allerwahrscheinlichkeit nach jeweils 2 App-Bundles pro App – in /Applications und in ~/Applications.
 
Demnach fuchtelt MS365 immer in den zentralen Ordnern (Library und so) herum.
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).

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.

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.

Wenn also standardmäßig nach ~/Programme installiert wird, muss also ein Admin dafür sorgen, festzulegen, welcher (Nichtadmin–)User auf welche Software zugreifen darf. In wieweit dafür die Bordmittel (also solche außerhalb des Terminals – und ohne extra Netzwerkverwaltungstools) zur Verwaltung ausreichen, weiß ich mangels eigenem Bedarf nicht.
 
Die Ordner in /Library und ~/Library sind unabhängig von der Position des App-Bundles.

...

Du kannst auch eine Ressource aus /Library/ (für alle lokalen Nutzer) nehmen, ein Duplikat machen und an die entsprechende Stelle in deinem ~/Library/ ablegen und nach deinen Wünschen anpassen. ...
...
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.

Mehr Aufwand bin ich nicht bereit zu treiben. Wenn man jetzt noch zusätzlichen manuellen Aufwand betreiben müßte, nur um die Trennung herbeizuführen und aufrecht zu erhalten, steige ich aus. Von daher: nein, da an diesen Stellen und Ressourcen werde ich nicht rumfuchteln..
...
...

dl;dr: ich würde im Fall von MS nicht mein Leben drauf verwetten, aber du solltest ohne Probleme die App-Bundles woandershin verschieben können und alles läuft wie gehabt. Lediglich bei den Updates müsstest du schauen, ob der sie in-place aktualisiert, oder sie wieder nach /Applications schreibt (dann hast du allerwahrscheinlichkeit nach jeweils 2 App-Bundles pro App – in /Applications und in ~/Applications.
Wie gesagt, das ist ein No-Go für mich. Genau um dieses Szenario ging es mir in meiner Frage in #54.

Davon abgesehen muß ich gestehen, ich habe bis jetzt noch nicht kapiert, was Du mit App-Bundles meinst. Für mich gibt es nur eine dmg, die lade ich runter. Da klick ich drauf, es öffnet sich ein Fensterlein, in dem ich ein App-Symbol in einen Application-Ordner schieben soll. Das mache ich, schiebe es allerdings nicht in den im Fensterlein angezeigten App-Folder, sondern in jenen App-Folder, den ich vorher User-spezifisch erstellt habe. Siehe Vorposts. Was da an diesem Prozedere jetzt das "App-Bundle" ist, weiß ich nicht so recht. Aber so gehe ich vor.
 
Zurück
Oben Unten