Erweiterung Verzeichnisbaum

[Thomas Quast]

Hallo,

mir geht es gerade um ein grundsaetzliches Verstaendnis.

Entsprechend der Doku auf eisfair.org ...

www.eisfair.org/fileadmin/eisfair/devdoc/development-basics.html#2

2.1. Die Plattform eisfair (zweiter Abschnit)

[zitat]
Bei der Entwicklung von eisfair wird darauf geachtet, daß das System
schlank und schnell bleibt.
Übermäßige Verzeichnisbaum-Erweiterungen (/opt , /srv , /usr/local/sbin)
werden vermieden.
[/zitat]

... sollte es diese Verzeichnisse nicht geben.

Nun ist es aber so, das vereinzelte Pakete per default eben doch (z.B.)
das Verzeichnis /srv verwenden.

Wie verhaelt es sich denn nun?
- Kann ich die Doku in die Tonne treten und meinen Sorens ablegen wo ich will?

- Ist die Doku nur ein grober Wegweiser, an welche man sich halten kann, aber
nicht muss?

- Werden die Pakete, welche begonnen haben in /srv abzuelegen, wieder
umgeschrieben?

- Gilt die Doku nur fuer Pakete von externen Entwicklern, nicht aber fuer
Pakete vom Team?

- Wird die Doku jetzt umgeschrieben und angepasst?


Mochte nur wissen, wo ich was ablegen kann/soll. Nicht das ich spaeter wieder
Teile/Alles umziehen muss.

btw: http://www.eisfair.org/fileadmin/eisfair/devdoc/devdoc.pdf fuehrt ins leere.
Dieses PDF gibt es nicht.

Gruss,
Thomas

[Marcus Röckrath]

Hallo Thomas,

Post by Thomas Quast
Entsprechend der Doku auf eisfair.org ...
www.eisfair.org/fileadmin/eisfair/devdoc/development-basics.html#2
2.1. Die Plattform eisfair (zweiter Abschnit)
[zitat]
Bei der Entwicklung von eisfair wird darauf geachtet, daß das System
schlank und schnell bleibt.
Übermäßige Verzeichnisbaum-Erweiterungen (/opt , /srv , /usr/local/sbin)
werden vermieden.
[/zitat]

Da wird einiges veraltet sein.

In /usr/local sollen keine Daten von eisfair-Paketen liegen; dieser
Verzeichnisbaum ist für die Ablage von manuell kompilierten Programmen
vorgesehen.

Post by Thomas Quast
... sollte es diese Verzeichnisse nicht geben.
Nun ist es aber so, das vereinzelte Pakete per default eben doch (z.B.)
das Verzeichnis /srv verwenden.

Das hat sich in letzter Zeit so ergeben und ist in vielen Distris üblich,
dort Daten von Serverdiensten (Datenbanken, WWW, FTP) abzulegen.

Für eisgraph wäre es dann sinnvoll, /srv/www/eisgraph für die Webseite zu
nutzen.

Die rrdtool-DBs könnten auch unter /srv/eisgraph liegen oder Holger, was
sagst du dazu.

Die Skripte selbst sollten von /usr/local nach /usr/lib umziehen.

[Kay Martinen]

Hallo

Sorry wenn ich da mal nachfrage.

Post by Marcus Röckrath

Post by Thomas Quast
Nun ist es aber so, das vereinzelte Pakete per default eben doch (z.B.)
das Verzeichnis /srv verwenden.

Das hat sich in letzter Zeit so ergeben und ist in vielen Distris üblich,
dort Daten von Serverdiensten (Datenbanken, WWW, FTP) abzulegen.

Macht das Nutzen dieser Verzeichnisbäume das portieren/Paketieren nur
einfacher - entgegen der eigenen Dev Doku? Ich stecke da nicht so drin
aber ich glaubte immer solche Pfade werden als Optionen oder fest im
makefile angegeben, das man; vermute ich; eh bearbeiten muß wenn man ein
Paket für Eisfair macht. So wie für jede andere Distri.

Post by Marcus Röckrath
Die Skripte selbst sollten von /usr/local nach /usr/lib umziehen.

Das /usr/local frei bleibt finde ich auch sinnvoll. Aber zu /usr/lib
(und allg. auch zu /var/lib) hätte ich mal ne (theoretische?)
Grundsatzfrage. Wieso scripte? Oder auch Daten?

Ich meine, der Verzeichnisast sagt LIB und das sehe ich als Library,
also als Ort für linux-bibliotheksdateien. Scripte passen da nach meinem
Verständnis ebenso wenig rein wie z.B. die dhcpd-leases unter /var/lib

Müßten dort nicht nur libs liegen von Programmen die in /usr/bin liegen
und diese Brauchen? Das wäre zumindest unmittelbar nachvollziehbar. Und
früher war es wohl auch mal möglich z.b. /usr/* per nfs an diskless
hosts zu vergeben damit diese die Programme dort nutzen können.

Okay, scripte sind ausführbar. Bibliotheken gewiß auch. Aber doch erst
wenn sie in den Speicher geladen wurden oder? Und ich weiß ehrlich
gesagt nicht ob eine Bibliothek selbst Daten anlegen kann. Ich glaubte
bisher das tut nur ein Programm - Mithilfe von Funktionen die es aus der
Bibliothek lädt wenn beides im Speicher liegt.

Kay

[Marcus Röckrath]

Hallo Kay,

Post by Kay Martinen
Das /usr/local frei bleibt finde ich auch sinnvoll. Aber zu /usr/lib
(und allg. auch zu /var/lib) hätte ich mal ne (theoretische?)
Grundsatzfrage. Wieso scripte? Oder auch Daten?

Daten IMHO nicht; prinzipiell ist /usr/local das Pedant zu /usr für lokal
vom Anwender am Paketsystem vorbei eingerichtete Programme, also z. B.
währen vergleichbar:

/usr/lib und /usr/local/lib
/usr/bin und /usr/local/bin
...

Daten gehören mE z. B. nach /var/lib; DBs aber auch nach /srv , ...

Post by Kay Martinen
Ich meine, der Verzeichnisast sagt LIB und das sehe ich als Library,
also als Ort für linux-bibliotheksdateien. Scripte passen da nach meinem
Verständnis ebenso wenig rein wie z.B. die dhcpd-leases unter /var/lib

Die dhcp-leases ist doch keine Lib, oder habe ich dich jetzt hier völlig
falsch vestanden.

Echte Libs gehören
nach /usr/lib, /usr/lib64, /usr/local/lib; /usr/local/lib64, ...

Post by Kay Martinen
Okay, scripte sind ausführbar. Bibliotheken gewiß auch. Aber doch erst
wenn sie in den Speicher geladen wurden oder?

Jedes Binary muss doch erst in den RAM geladen zu werden, um gestartet zu
werden; auch Daten werden zur Verarbeitung in den Speicher geladen.

[Alexander Dahl]

Hallo Kay,

Post by Kay Martinen
Sorry wenn ich da mal nachfrage.

Passt schon, ich finde es zumindest aus akademischer Sicht auch
interessant.

Post by Kay Martinen

Post by Marcus Röckrath

Post by Thomas Quast
Nun ist es aber so, das vereinzelte Pakete per default eben doch (z.B.)
das Verzeichnis /srv verwenden.

Das hat sich in letzter Zeit so ergeben und ist in vielen Distris üblich,
dort Daten von Serverdiensten (Datenbanken, WWW, FTP) abzulegen.

Ich hätte aus dem Bauch raus gesagt, dass /opt und /srv Pfade sind, wo
die Distri nix zu suchen hat. /opt wird in meinere Wahrnehmung von third
party software zur Installation genutzt und nach /srv packt der
Administrator Daten, auf denen irgendein Serverdienst operiert. Ich
installiere bspw. gern Webanwendungen nach /srv

Post by Kay Martinen
Macht das Nutzen dieser Verzeichnisbäume das portieren/Paketieren nur
einfacher - entgegen der eigenen Dev Doku? Ich stecke da nicht so drin
aber ich glaubte immer solche Pfade werden als Optionen oder fest im
makefile angegeben, das man; vermute ich; eh bearbeiten muß wenn man ein
Paket für Eisfair macht. So wie für jede andere Distri.

Naja Makefile hast Du ja nur beim Kompilieren und einige Pfade werden
erst zur Laufzeit ausgewertet, insbesondere solche, die irgendwo
unterhalb von /etc in irgendeinem Config-File stehen.

Post by Kay Martinen

Post by Marcus Röckrath
Die Skripte selbst sollten von /usr/local nach /usr/lib umziehen.

Das /usr/local frei bleibt finde ich auch sinnvoll. Aber zu /usr/lib
(und allg. auch zu /var/lib) hätte ich mal ne (theoretische?)
Grundsatzfrage. Wieso scripte? Oder auch Daten?

Fixe Scripte oder Binaries nach /usr (weil ggf. read only) und Daten
unterhalb von /var …

Post by Kay Martinen
Ich meine, der Verzeichnisast sagt LIB und das sehe ich als Library,
also als Ort für linux-bibliotheksdateien. Scripte passen da nach meinem
Verständnis ebenso wenig rein wie z.B. die dhcpd-leases unter /var/lib
Müßten dort nicht nur libs liegen von Programmen die in /usr/bin liegen
und diese Brauchen? Das wäre zumindest unmittelbar nachvollziehbar. Und
früher war es wohl auch mal möglich z.b. /usr/* per nfs an diskless
hosts zu vergeben damit diese die Programme dort nutzen können.
Okay, scripte sind ausführbar. Bibliotheken gewiß auch. Aber doch erst
wenn sie in den Speicher geladen wurden oder? Und ich weiß ehrlich
gesagt nicht ob eine Bibliothek selbst Daten anlegen kann. Ich glaubte
bisher das tut nur ein Programm - Mithilfe von Funktionen die es aus der
Bibliothek lädt wenn beides im Speicher liegt.

Die Nutzung von /var/lib hat IMHO ein grundsätzliches Problem: die
Benamsung ist unglücklich. Laut Filesystem Hierarchy Standard (FHS)
gehört da folgendes rein:

"State information. Persistent data modified by programs as they run,
e.g., databases, packaging system metadata, etc. "

Aber eisfair selbst ist ja auch nicht ganz frei von historisch
gewachsenen komischen Dingen. Bspw. der ganze Kram unterhalb von
/var/install der in großen Teilen gar nicht so "variabel" ist. ;-)

Letztlich sollte es aber so sein, dass es eine aktuelle Dokumentation
geben sollte, was wo hin kommt bei eisfair und die Devs halten sich an
genau diese Dokumentation, unabhängig davon ob jede einzelne das
sinnvoll findet oder was irgendein anderer Standard sagt. Sich an
letzteres zu halten ist nett, aber hier schlägt Konsitenz auf dem System
dann doch Einhaltung eines übergeordneten Standards.

Grüße
Alex

[Marcus Röckrath]

Hallo Alexander,

Post by Alexander Dahl
Ich hätte aus dem Bauch raus gesagt, dass /opt und /srv Pfade sind,

/srv verwendet die SuSE schon seit Urzeiten für www und ftp.

[Alexander Dahl]

Hallo Marcus,

Post by Marcus Röckrath

Post by Alexander Dahl
Ich hätte aus dem Bauch raus gesagt, dass /opt und /srv Pfade sind,

/srv verwendet die SuSE schon seit Urzeiten für www und ftp.

Ja, weil Admin und Nutzer da _Daten_ hinkopieren, die Web- und
FTP-Server dann bereitstellen. Ich glaube nicht, dass SuSE da die
ausführbaren Binaries der Serversoftware hin packt. Da wird ein
Verzeichnisbaum erstellt zum Ablegen von Daten, oder?

Insofern ist es ggf. auch unglücklich, wenn ich da meine Webanwendungen
hin packe, in beiden Fällen ist es aber so, das das Betriebssystem da
keine Programme ablegt, richtig?

Grüße
Alex

[Kay Martinen]

Post by Alexander Dahl
Hallo Marcus,

Post by Marcus Röckrath

Post by Alexander Dahl
Ich hätte aus dem Bauch raus gesagt, dass /opt und /srv Pfade sind,

/srv verwendet die SuSE schon seit Urzeiten für www und ftp.

Ja, weil Admin und Nutzer da _Daten_ hinkopieren, die Web- und
FTP-Server dann bereitstellen. Ich glaube nicht, dass SuSE da die
ausführbaren Binaries der Serversoftware hin packt. Da wird ein
Verzeichnisbaum erstellt zum Ablegen von Daten, oder?

Die Supportsoftware für HP Server richtet sich auch in /opt ein, hier
auf einem Debian/Ubuntu. Suse ist wieder was anderes. Und Eisfair ist
nicht Suse.

Post by Alexander Dahl
Insofern ist es ggf. auch unglücklich, wenn ich da meine Webanwendungen
hin packe, in beiden Fällen ist es aber so, das das Betriebssystem da
keine Programme ablegt, richtig?

Was sind denn CGI's? Keine Programme? Müssen aber dennoch vom Browser
erreicht werden können also abrufbar sein. Wo steckt man die dann hin
wenn nicht per Alias o.ä. eh von woanders geholt.

Kay

[Marcus Röckrath]

Hallo Kay,

Post by Kay Martinen
Die Supportsoftware für HP Server richtet sich auch in /opt ein, hier
auf einem Debian/Ubuntu.

Kommt ja auch nicht von einem Debian/Ubuntu-Repository sondern vom einem
Hersteller, der da ein allgemeies Installationspaket für verschiedene
Distris bereitstellt, oder?

Post by Kay Martinen
Suse ist wieder was anderes. Und Eisfair ist nicht Suse.

Genau und wird machen das ja als Rolling-Release

Post by Kay Martinen

Post by Alexander Dahl
Insofern ist es ggf. auch unglücklich, wenn ich da meine Webanwendungen
hin packe, in beiden Fällen ist es aber so, das das Betriebssystem da
keine Programme ablegt, richtig?

Was sind denn CGI's? Keine Programme? Müssen aber dennoch vom Browser
erreicht werden können also abrufbar sein. Wo steckt man die dann hin
wenn nicht per Alias o.ä. eh von woanders geholt.

Statt in /var/www/cgi-bin, können sie auch unter /srv/www/cgi-bin.

[Alexander Dahl]

Moin,

Post by Kay Martinen

Post by Alexander Dahl
Insofern ist es ggf. auch unglücklich, wenn ich da meine Webanwendungen
hin packe, in beiden Fällen ist es aber so, das das Betriebssystem da
keine Programme ablegt, richtig?

Was sind denn CGI's? Keine Programme? Müssen aber dennoch vom Browser
erreicht werden können also abrufbar sein. Wo steckt man die dann hin
wenn nicht per Alias o.ä. eh von woanders geholt.

Nein, CGI müssen vom Webserver erreichbar sein. Ebenso wie bspw.
PHP-Skripte werden nicht an den Client/Browser übertragen, sondern vom
Server ausgeführt und nur der Output des Skripts wird über's Netz
geschickt. Was Webanwendungen hier speziell macht, ist, dass ich direkt
neben ein CGI oder .php eine Datei packen kann, die direkt vom Webserver
ausgeliefert wird. Aber klassischerweise sind das beides Dinge, die vom
Nutzer bspw. über ftp auf den Webserver geladen wurden, insofern passt
das schon mit /srv

Es gibt aber auch "fertige" Webanwendungen, die bspw. Distributionen wie
Debian auch mal unterhalb von /usr installieren und dann wird im
Webserver halt mit irgendwelchen Aliasen konfiguriert.

Und weil das alles nicht kompliziert genug ist, kann man ja nochmal
überlegen, wo denn die Konfiguration einer Webanwendung hingehört? Mit
in den selben Ordner oder irgendwie doch nach /etc …? ;-)

Grüße
Alex

[Marcus Röckrath]

Hallo Alexander,

Post by Alexander Dahl

Post by Marcus Röckrath
/srv verwendet die SuSE schon seit Urzeiten für www und ftp.

Ja, weil Admin und Nutzer da _Daten_ hinkopieren, die Web- und
FTP-Server dann bereitstellen. Ich glaube nicht, dass SuSE da die
ausführbaren Binaries der Serversoftware hin packt. Da wird ein
Verzeichnisbaum erstellt zum Ablegen von Daten, oder?

Klar, ich meinte auch nie, dass dort die Software selbst hinkommt.

Statt /var/www wird halt /srv/www usw. benutzt, was auf der SuSE schon lange
wohl Standard ist.

Post by Alexander Dahl
Insofern ist es ggf. auch unglücklich, wenn ich da meine Webanwendungen

Du meinst eine php-Webanwendung wie z. B. phpsysinfo?

Wieso nicht? Wo liegt sie jetzt?

[Thomas Quast]

Hallo Kay,

Post by Kay Martinen

Post by Marcus Röckrath

Post by Thomas Quast
Nun ist es aber so, das vereinzelte Pakete per default eben doch (z.B.)
das Verzeichnis /srv verwenden.

Das hat sich in letzter Zeit so ergeben und ist in vielen Distris üblich,
dort Daten von Serverdiensten (Datenbanken, WWW, FTP) abzulegen.

Macht das Nutzen dieser Verzeichnisbäume das portieren/Paketieren nur
einfacher - entgegen der eigenen Dev Doku? Ich stecke da nicht so drin
aber ich glaubte immer solche Pfade werden als Optionen oder fest im
makefile angegeben, das man; vermute ich; eh bearbeiten muß wenn man ein
Paket für Eisfair macht. So wie für jede andere Distri.

Post by Marcus Röckrath
Die Skripte selbst sollten von /usr/local nach /usr/lib umziehen.

Was aber eigentlich auch nicht richtig ist.

Im Prinzip kann kann jede Distri ihre Verzeichnisstruktur aufbauen, wie sie
moechte. Da gibt es keine Vorgaben. Man kann auch die Verzeichnisse a, b,
c, ... oder 1, 2, 3, ... oder bla, blub, foo, ... nennen. Aber das macht es
unuebersichtilich und fehlernafaellig.

Um das zu vermeiden, hat man hat sich darauf geeinigt, sich an FHS zu
orientieren.

Im groben kann man es in drei Ebenen unterteiĺen: /, /usr und /usr/local.

/ (ohne /usr, /home, /opt und /srv)
Enthaelt alles, was fuer den Betrieb des Systems notwendig ist.

/usr
Ein Abbild von / enthaelt alles fuer den/die User und den Anwendungen.

/usr/local
Lokal erzeugte Anwendungen (auch Komilate). Also keine von einem Paket
installierte Dateien.

/opt
Dort werden Pakete abgelegt, die sich eben nicht an eine Struktur halten
wollen/koennen. Wird gerne von Paketen verwendet, welche auf beinahe allen
Systemen laufen wollen, ohne sich an einer bestimmten Distributionsspezifischen
Struktur orientieren zu muessen.
Aber auch hier sollte einiges beachtet werden. Pakete sollten in der Form
/opt/<Paket> oder /opt/<Hersteller> abgelegt werden.

/opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, und /opt/man sind fuer
den lokalen Admin reserviert.

/srv
Hier werden Daten abgelegt, welche von Diensten, wie z.B. FTP oder Apache
angeboten werden. So z.B. auch /srv/www/html und /srv/www/cgi-bin.

Aber auch Datenbankanwendungen legen hier ihre Daten ab, nicht aber ihre
Konfigurationen und auch nicht ihre Binaries.

Post by Kay Martinen
Das /usr/local frei bleibt finde ich auch sinnvoll. Aber zu /usr/lib
(und allg. auch zu /var/lib) hätte ich mal ne (theoretische?)
Grundsatzfrage. Wieso scripte? Oder auch Daten?

Unter /usr/lib sollte nur Bibliotheken (Libraries) zum Programmieren und
fuer Pakete liegen. (Siehe oben). /usr/lib ist das Pendant zu /lib.

Post by Kay Martinen
Ich meine, der Verzeichnisast sagt LIB und das sehe ich als Library,
also als Ort für linux-bibliotheksdateien. Scripte passen da nach meinem
Verständnis ebenso wenig rein wie z.B. die dhcpd-leases unter /var/lib

/var/lib hat, obwohl es den Anschein erweckt, nichts mit Libraries zu tun.
Dort werden (nach FHS) variable Statusinformationen abgelegt, wie z.B. die
von Dir genannten dhcp-leases.

Gruss,
Thomas

[Alexander Dahl]

Moin,

Post by Thomas Quast
Im groben kann man es in drei Ebenen unterteiĺen: /, /usr und /usr/local.
/ (ohne /usr, /home, /opt und /srv)
Enthaelt alles, was fuer den Betrieb des Systems notwendig ist.
/usr
Ein Abbild von / enthaelt alles fuer den/die User und den Anwendungen.
/usr/local
Lokal erzeugte Anwendungen (auch Komilate). Also keine von einem Paket
installierte Dateien.

Wobei man dazu sagen muss, dass 'usr' in diesem Fall für Unix System
Resources steht und nicht wie oft fälschlich angenommen für etwas
anderes, was so ähnlich klingt. ;-)

Grüße
Alex

[Kay Martinen]

Post by Alexander Dahl

Post by Thomas Quast
/usr
Ein Abbild von / enthaelt alles fuer den/die User und den Anwendungen.

Wobei man dazu sagen muss, dass 'usr' in diesem Fall für Unix System
Resources steht und nicht wie oft fälschlich angenommen für etwas
anderes, was so ähnlich klingt. ;-)

Ach das wusste ich noch nicht aber da fehlte dann ja auch ein 'e'
zwischen. :-) Cool, dann kann man ja /usr per nfs exportieren und
schwupps hat ein unix system alles was es braucht(1). Wenn ich eines hätte.

Das für linux in /lsr um zu benennen ist wohl zu spät, oder? :-)=)

Ernsthaft: Okay da liegt auch ein sbin verzeichnis aber meistens stimmt
es doch das dort userland-programme liegen. root ist auch *nur* user.

Bootloader im MBR oder EFI, kernel unter /boot, der mountet sich sein
rootfs mit /etc und /lib und braucht dann meist noch ein /var. Dann ist
nur noch /sbin/init nötig. Was soll in /usr stecken das beim Hochfahren
WIRKLICH gebraucht würde? Ich vermute: Nichts essentielles, alles
optional. Darum kann man linux sogar auf kleinstgeräten betreiben - wenn
man alles abspeckt. z.B. /usr.


Kay

(1) DOS-basierend hab ich Remote boot; mit "exports" schon gemacht.
Nicht nfs sondern LanManager.

[Alexander Dahl]

Hallo Kay,

Post by Kay Martinen
Ernsthaft: Okay da liegt auch ein sbin verzeichnis aber meistens stimmt
es doch das dort userland-programme liegen. root ist auch *nur* user.
Bootloader im MBR oder EFI, kernel unter /boot, der mountet sich sein
rootfs mit /etc und /lib und braucht dann meist noch ein /var. Dann ist
nur noch /sbin/init nötig. Was soll in /usr stecken das beim Hochfahren
WIRKLICH gebraucht würde? Ich vermute: Nichts essentielles, alles
optional. Darum kann man linux sogar auf kleinstgeräten betreiben - wenn
man alles abspeckt. z.B. /usr.

Tja also was soll ich sagen, in modernen Linux-Systemen geht man davon
aus, dass der Kernel sehr früh auf /usr zugreifen kann, entweder weil es
eh Teil von / ist oder in initramfs o.ä. gemounted wird und um die
Komplexität zu verringern, soll es nur noch /usr/bin bzw. /usr/sbin
geben und /bin und /sbin werden perspektivisch wegfallen. Such mal in
$Suchmaschine nach usrmerge …

Grüße
Alex

[Thomas Quast]

Post by Marcus Röckrath

Post by Thomas Quast
Entsprechend der Doku auf eisfair.org ...
www.eisfair.org/fileadmin/eisfair/devdoc/development-basics.html#2
2.1. Die Plattform eisfair (zweiter Abschnit)
[zitat]
Bei der Entwicklung von eisfair wird darauf geachtet, daß das System
schlank und schnell bleibt.
Übermäßige Verzeichnisbaum-Erweiterungen (/opt , /srv , /usr/local/sbin)
werden vermieden.
[/zitat]

Da wird einiges veraltet sein.

Um es mal mit eben dieser Doku zu beschreiben:

[zitat]
Eine der wichtigsten Säulen von eisfair ist die Dokumentation.
[/zitat]

Quelle: http://www.eisfair.org/fileadmin/eisfair/devdoc/charta.html
(letzter Absatz)

Post by Marcus Röckrath
In /usr/local sollen keine Daten von eisfair-Paketen liegen; dieser
Verzeichnisbaum ist für die Ablage von manuell kompilierten Programmen
vorgesehen.

Gerne halte ich mich an den Filesystem Hierarchy Standard der Linux Foundation.

Das sorgt fuer Klarheit.

Aber entgegen eben diesem ...

Post by Marcus Röckrath
Für eisgraph wäre es dann sinnvoll, /srv/www/eisgraph für die Webseite zu
nutzen.

... wurde mir vor einiger Zeit nahe gelegt, eben diese Dateien unter
/var/lib/eisgraph abzulegen.

Post by Marcus Röckrath
Die rrdtool-DBs könnten auch unter /srv/eisgraph liegen oder Holger, was
sagst du dazu.

Die bleiben erstmal wo sie sind. Mal sehen, wenn ich Zeit eruebrigen kann,
vielleicht dann.

Post by Marcus Röckrath
Die Skripte selbst sollten von /usr/local nach /usr/lib umziehen.

Ueberfluessiger Kommentar. Du liest hier mit und weisst also, das dies bereits
in Planung ist.

Fuer alle, die mehr zu FHS (Filesystem Hierarchy Standard) wissen moechten:

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

Auf Deutsch (nicht so ausfuehrlich, trotzdem informativ):

https://de.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Gruss,
Thomas

[Holger Bruenjes]

Hallo Thomas

Post by Thomas Quast
2.1. Die Plattform eisfair (zweiter Abschnit)
[zitat]
Bei der Entwicklung von eisfair wird darauf geachtet, daß das System
schlank und schnell bleibt.
Übermäßige Verzeichnisbaum-Erweiterungen (/opt , /srv , /usr/local/sbin)
werden vermieden.
[/zitat]
... sollte es diese Verzeichnisse nicht geben.

Danke fuer den Hinweis, ich habs korrigiert, diese Stelle hatte ich
uebersehen.

Holger