Guten Morgen, auf ein paar PCs soll nur ein einziges GTK-Programm laufen. Das kann bei Bedarf qpdfview und pcmanfm starten, deshalb läuft unten drunter noch openbox, aber mehr Desktop gibt es nicht. Im Hintergrund laufen noch 2 bis 3 Programme für die Verbindung zur Außenwelt. Die Installation soll mit wenig manuellen Einstellungen funktionieren. Also ein netinst-iso booten, Sprache wählen, Desktop abwählen und ssh ankreuzen. Anschließend soll ein Eigenbaupaket installiert werden, das den ganzen Rest konfiguriert. Der Inhalt ist minimal, nur ein daemon, der X11 und das GTK-Programm startet. Aber die Depends-Liste würde extrem lang, gibt's da eigentlich eine Grenze? Der spannende Teil: / soll read-only gemountet werden und /tmp und /var/log/ als tmpfs. Das "ro" für / muss in die /etc/fstab und für tmp wäre eigentlich /etc/default/tmpfs zuständig. Wie macht man das, wenn man die Debian-Spielregeln einhalten will? Sehe ich das richtig, dass die fstab (und /etc/default/*) nur vom Admin geändert werden darf und nicht vom postinst-Script? Eine Änderung per Script dürfte auch sehr fehleranfällig sein. Das nächste Rätsel: das Package ist ja rein lokal und bleibt im Haus. Von daher gehört alles nach /usr/local/, aber genau da darf ein Package nichts installieren. Momentan würde ich den daemon in /usr/sbin/ und alles andere unter /home/user/ installieren. $HOME wird für ein paar configs sowieso gebraucht und $HOME/bin/ ist ja nicht so unüblich. Schon mal vielen Dank für sachdienliche Hinweise.
:
Bearbeitet durch User
Für ein eigenes Package brauchst du dich nicht an die Debian-Spielregeln halten, du willst es dort ja auch nicht veröffentlichen. Und so lange wird die dependency-List auch nicht, wenn du dich auf die Top-Level-dependencies beschränkst.
:
Bearbeitet durch User
Bauform B. schrieb: > und alles andere unter /home/user/ installieren. Also in home hat ein Package nun wirklich nichts verloren.
Bauform B. schrieb: > Der spannende Teil: / soll read-only gemountet werden und /tmp und > /var/log/ als tmpfs. Das "ro" für / muss in die /etc/fstab und für tmp > wäre eigentlich /etc/default/tmpfs zuständig. Wie macht man das, wenn > man die Debian-Spielregeln einhalten will? Sehe ich das richtig, dass > die fstab (und /etc/default/*) nur vom Admin geändert werden darf und > nicht vom postinst-Script? Eine Änderung per Script dürfte auch sehr > fehleranfällig sein. Pakete installieren darf eh nur root, und damit ist das kein Problem. > Das nächste Rätsel: das Package ist ja rein lokal und bleibt im Haus. > Von daher gehört alles nach /usr/local/ Nö. Ich würde das Zeugst nach /opt/bauformb/... schieben. fchk
Bauform B. schrieb: > Das nächste Rätsel: das Package ist ja rein lokal und bleibt im Haus. > Von daher gehört alles nach /usr/local/, aber genau da darf ein Package > nichts installieren. Momentan würde ich den daemon in /usr/sbin/ und > alles andere unter /home/user/ installieren. $HOME wird für ein paar > configs sowieso gebraucht und $HOME/bin/ ist ja nicht so unüblich. Die Dateien Deines Paketes finden unter opt ein würdiges Zuhause, und die Konfigurationsdateien dafür sind unter /etc/opt/ gut aufgehoben, für weiteres dazu siehe unter [1,2]. Unter opt können Pakete auf zwei Weisen installiert werden, nämlich als /opt/<provider>/ -- also: wenn der Provider, sprich: das Unternehmen bei der Linux Assigned Names And Numbers Authority (LANANA) [3] registriert ist -- oder unter /opt/<package>/, sofern das nicht der Fall ist. [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html [2] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.html#etcoptConfigurationFilesForOpt [3] https://www.lanana.org/
Hier wird vermutlich jeder seine eigene Meinung haben. Nachdem es deine Systeme sind und du das nirgendwo verteilst: mach wie es für dich am besten klappt. Vermutlich setzt du Kiosk-Systeme auf und hast ein paar eigene Skripte die im Hintergrund laufen sollen? Ich persönlich würde das Zeugs nicht so weit verteilen und möglichst nicht mit Anwendungen aus den regulären Paketquellen mischen. Also entweder alles (Executables + Konfig) nach /home/bauformb/mykiosk oder Executables und Konfig trennen (/opt/mykiosk und /home/bauformb/.mykiosk). Aber, wie gesagt, nur meine persönliche Meinung.
Εrnst B. schrieb: > Für ein eigenes Package brauchst du dich nicht an die > Debian-Spielregeln halten naja, solange es trotzdem funktioniert, wäre das kein Nachteil. Vielleicht kenne ich mich dann auch in einem Jahr noch aus ;) Le X. schrieb: > Vermutlich setzt du Kiosk-Systeme auf und hast ein paar eigene Skripte > die im Hintergrund laufen sollen? Ja, so ähnlich. > Ich persönlich würde das Zeugs nicht so weit verteilen und möglichst > nicht mit Anwendungen aus den regulären Paketquellen mischen. > (...) > Executables und Konfig trennen > (/opt/mykiosk und /home/bauformb/.mykiosk). /opt statt /sbin ist auf jeden Fall viel besser/sauberer. Dann macht mir der Rest in /home garkein schlechtes Gewissen, danke. > Aber, wie gesagt, nur meine persönliche Meinung. Anscheinend nicht nur deine, und jetzt verstehe ich auch endlich /opt, weil: Sheeva P. schrieb: > Die Dateien Deines Paketes finden unter opt ein würdiges Zuhause, und > die Konfigurationsdateien dafür sind unter /etc/opt/ gut aufgehoben. > Unter opt können Pakete auf zwei Weisen installiert werden, nämlich > als /opt/<provider>/ -- also: wenn der Provider, sprich: das Unternehmen > bei der Linux Assigned Names And Numbers Authority (LANANA) [3] > registriert ist -- oder unter /opt/<package>/, sofern das nicht der Fall > ist.
Le X. schrieb: > Hier wird vermutlich jeder seine eigene Meinung haben. > Nachdem es deine Systeme sind und du das nirgendwo verteilst: mach wie > es für dich am besten klappt. Nunja, es gibt einen Filesystem Hierarchy Standard, und es sicherlich keine schlechte Idee, sich daran zu orientieren. Denn wenn -- aus welchen Gründen auch immer -- mal ein anderer Sysop was mit dem System machen soll, wird ihm die Orientierung dann wesentlich leichter fallen. > Ich persönlich würde das Zeugs nicht so weit verteilen und möglichst > nicht mit Anwendungen aus den regulären Paketquellen mischen. Haargenau für solche Fälle sieht der FHS die Verzeichnisse /usr/local/ und /opt/<provider> oder /opt/<package> vor: damit die Installation von Paketen aus den Distributionsquellen an diesen Orten nichts überschreibt. > Also entweder alles (Executables + Konfig) nach /home/bauformb/mykiosk > oder Executables und Konfig trennen (/opt/mykiosk und > /home/bauformb/.mykiosk). Unter /home/<user> hat so etwas allerdings nichts zu suchen, nicht einmal, wenn es den betreffenden User zuvor anlegt. In /home/<user> kann natürlich trotzdem Software installiert werden, für diesen einen Benutzer -- und auch dann ist das meistens keine gute Idee, wenn wir nochmal über unseren fremden Sysop aus dem ersten Absatz nachdenken.
Sheeva P. schrieb: > Unter /home/<user> hat so etwas allerdings nichts zu suchen, Was in meinem home was zu suchen hat bestimme allein ich.
/opt verwende ich für Programme, die ihre eigene Verzeichnisstruktur mitbringen, so wie man das von den meisten Windows Programmen auch kennt. Also z.b. /opt/arduino-1.8.19/... In /usr erwarte ich die allermeisten Pakete der Linux Distribution. Da sie aufeinander abgestimmt sind und Konflikte mit doppelten Dateinamen nicht zu erwarten sind, kann der Linux Distributor hier alles zusammen schmeißen. In /usr/local erwarte ich "fremde" Programme, die kein separates Verzeichnis unter /opt haben. Allerdings besteht hier ein relativ hohes Risiko für Konflikte mit doppelten Dateinamen.
Le X. schrieb: > Sheeva P. schrieb: >> Unter /home/<user> hat so etwas allerdings nichts zu suchen, > > Was in meinem home was zu suchen hat bestimme allein ich. Das bestreitet auch niemand. Aber wenn wir über eine saubere Lösung reden, ist es sinnvoller, sich an die einschlägigen Standards zu halten. Dies gilt vor allem auch im professionellen Bereich, wo zukünftig möglicherweise auch mal jemand anders mit der Maschine arbeiten muß und dann mitunter keine Zeit hat, sich in irgendwelche hingebastelten Sonderlösungen hinein zu fuchsen. Sowas sind immer auch heimtückische Fehlerquellen -- und was genau spricht dagegen, sich einfach an die Standards zu halten?
Sheeva P. schrieb: > [3] https://www.lanana.org/ Ist die überhaupt noch aktiv ("Site Last Modified: 06 Feb 2018")? Teilweise führen die Links auf der Seite ins Nichts. Das sieht alles recht verwaist aus. Le X. schrieb: > Sheeva P. schrieb: >> Unter /home/<user> hat so etwas allerdings nichts zu suchen, > > Was in meinem home was zu suchen hat bestimme allein ich. Klar, du kannst natürlich frei gegen die üblichen Gepflogenheiten arbeiten. Das hat zwar keinen Vorteil, aber du kannst dich zumindest wie der King fühlen.
:
Bearbeitet durch User
Sheeva P. schrieb: > Aber wenn wir über eine saubere Lösung > reden, ist es sinnvoller, sich an die einschlägigen Standards zu halten. > Dies gilt vor allem auch im professionellen Bereich, wo zukünftig > möglicherweise auch mal jemand anders mit der Maschine arbeiten muß und > dann mitunter keine Zeit hat, sich in irgendwelche hingebastelten > Sonderlösungen hinein zu fuchsen. Sowas sind immer auch heimtückische > Fehlerquellen -- Der imaginäre "andere Sysop" ist bestimmt dankbar wenn er die ganzen Skripte und Gluecode, die den Eigenbau-Kiosk zusammenhalten, sowie etwaige Log- und Konfigfiles an einem zentralen Ort, z.B. /home/mykisok, findet. Die alternative wäre nämlich dass er sich die Dateien anhand der nicht vorhandenen Doku selber zusammensammeln muss. > und was genau spricht dagegen, sich einfach an die > Standards zu halten? Es gibt keinen Standard der mir verbieten würde meine Skripte und Executables im home des passenden Service-Users reinzulegen. Übrigens, eine kurze Suche im Netz zeigt schon dass der Fall nicht so eindeutig ist wie du es hier darstellst. Es gibt auch Distributionen die bringen ein ~/bin oder ~/.local/bin mit. Und nu? Das ist aber auch der Grund für mich, hier auszusteigen. Eine Diskussion die seit Jahren im Netz stattfindet muss man nicht nochmal aufwärmen.
:
Bearbeitet durch User
home ist für normale Benutzer gedacht, und Packages sind nicht dazu gedacht, in Benutzerverzeichnissen Änderungen vorzunehmen. Will man ein Programm nur für einen einzelnen Benutzer, statt systemweit, installiert haben, dann sind Packages dafür der falsche weg, die sind für Systemweite Sachen gedacht. Le X. schrieb: > Es gibt auch Distributionen die > bringen ein ~/bin oder ~/.local/bin mit. Und nu? Nein, die gibt es nicht. Es kann sein, dass einige in /etc/profile.d oder per pam_env den $PATH setzen, und es kann sein, das so ein Ordner per pam_mkhomedir beim Login erstellt wird, oder beim erstellen des Benutzers durch adduser. Aber ein Paket, das eine Datei in dem Ordner direkt besitzt oder erstellt, gibt es nicht, alleine schon deshalb, weil es nie DAS eine Home gibt.
Le X. schrieb: > Es gibt auch Distributionen die > bringen ein ~/bin oder ~/.local/bin mit. Und nu? Geht hier ja um Debian, und da lässt sich das leicht nachschauen:
1 | # dpkg -S /home |
2 | base-files: /home |
--> /home wird von "base-files" angelegt, sonst hat da kein Package was drinnen. Falls neue User automatisch was in ihr $HOME kriegen, kommt das üblicherweise aus /etc/skel/ Da kannst du auch per dpkg nachschauen, welches Package da was hinterlegt hat.
Daniel A. schrieb: > Will man ein Programm nur für einen einzelnen Benutzer, statt systemweit, > installiert haben, dann sind Packages dafür der falsche weg, die sind für > Systemweite Sachen gedacht. Das sehe ich auch so. Programme, die nur ein einzelner User in seinem Home Verzeichnis haben soll werden üblicherweise als zip oder tar.gz (oder ähnlich) verteilt.
Le X. schrieb: > Der imaginäre "andere Sysop" ist bestimmt dankbar wenn er die ganzen > Skripte und Gluecode, die den Eigenbau-Kiosk zusammenhalten, sowie > etwaige Log- und Konfigfiles an einem zentralen Ort, z.B. /home/mykisok, > findet. Sag, liest Du meine Beiträge nicht oder willst Du sie nicht verstehen? Unter /opt/<provider> und /opt/<paketname> ist das gegeben, nur die Konfiguration befindet sich unter /etc/opt/, wie es sich für gut gepflegte Systeme gehört. > Die alternative wäre nämlich dass er sich die Dateien anhand der nicht > vorhandenen Doku selber zusammensammeln muss. Für so etwas haben moderne Linux-Systeme einen sogenannten Paketmanager, den man befragen kann, wo er die Dateien eines Paketes installiert hat. > Es gibt keinen Standard der mir verbieten würde meine Skripte und > Executables im home des passenden Service-Users reinzulegen. Doch. Den gibt es. Ich habe ihn oben sogar verlinkt. Es ist der Filesystem Hierarchy Standard, oft kurz FHS genannt und auf gut gepflegten Linuxsystemen auch als Manual Page hier(7) installiert. Dort findest Du auch einen Verweis auf die Manual Page file-hierarchy(7), die auf weitere solche Standards wie die XDG Base Directory Specification, die XDG User Directories und obendrein auf IEEE Std 1003.1 verweist. Daß Du Standards trotz meines Links darauf entweder nicht kennst oder sie trotz ihrer Kenntnis ignorierst, ändert ja nichts daran, daß sie vorhanden sind. Bei Deinem vehementen Insistieren beschleicht mich aber langsam eine Idee, warum manche Menschen behaupten, Linux sei ein "Frickelsystem". > Übrigens, eine kurze Suche im Netz zeigt schon dass der Fall nicht so > eindeutig ist wie du es hier darstellst. Es gibt auch Distributionen die > bringen ein ~/bin oder ~/.local/bin mit. Und nu? In der Tat, ~/.local/bin/ wird von Python-Programmen verwendet, die der Benutzer mit dem Python-Paketmanager pip installiert hat. ~/bin hingegen... wer macht sowas, und: installiert der Paketmanager dort etwa was hinein?
Sheeva P. schrieb: > ~/bin hingegen... wer macht sowas Da habe ich persönliche Scripte abgelegt, die mir die tägliche Arbeit erleichtern.
Steve van de Grens schrieb: > Sheeva P. schrieb: >> ~/bin hingegen... wer macht sowas > > Da habe ich persönliche Scripte abgelegt, die mir die tägliche Arbeit > erleichtern. Da habe ich mich mißverständlich ausgedrückt, denn so etwas ist ja vollkommen legitim und so ähnlich mache ich das auch: diese Skripte sind ja Deine eigenen Skripte und nur für Dich. Was ich aber oben gemeint habe, ist etwas anderes, nämlich: ich kenne keine Distribution, die ein bin-Verzeichnis im Homedir des Benutzers anlegen und schon gleich gar keine, deren Paketmanager etwas in die Homedirectories der Benutzer installiert.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.