Was ist der Unterschied zwischen / etc und / usr / local / etc?

24

Ich entwickle einen Daemon, der viele Anwendungsdaten speichern muss, und habe festgestellt, dass sich auf meinem System (Fedora 15) ein /usr/local/etcVerzeichnis befindet.

Ich habe beschlossen, meinen Daemon auf zu installieren /usr/local/bin, und ich benötige einen Speicherort für meine Konfigurationsdateien.

Das habe ich auf Wikipedia nicht gesehen . Ist dies nicht der Standard oder ist dies der Standardort für Programme, die /usr/local/binzum Speichern von Konfigurationsdateien installiert wurden ?

Grund dafür ist, dass ich dies an Systemadministratoren vermarkten möchte, und es ist kein gutes Verkaufsargument, so etwas falsch zu machen ...

directory-structure fhs

— Beatgammit
quelle

2

Gibt es einen Grund, es nicht direkt darunter zu stellen /etc/myapp? Wenn ich eine Konfiguration ändern wollte, wäre dies der erste Ort, an dem ich nachsehen würde.

— new123456

@ new123456- Ich persönlich mag die Idee, Konfigurationsdateien nahe an der Binärdatei zu halten (zB /usr/local/bin-> /usr/local/etc), aber Konventionen gewinnen in diesem Fall.

— Beatgammit

24

/usr/localwird normalerweise für Anwendungen verwendet, die aus dem Quellcode erstellt wurden. Dh ich installiere die meisten meiner Pakete mit etwas wie apt, aber wenn ich eine neuere Version von etwas oder einer Software herunterlade, die nicht Teil meiner Distribution ist, würde ich sie aus dem Quellcode erstellen und alles in die Hierarchie `/ usr / local 'einfügen.

Dies ermöglicht eine Trennung vom Rest der Verteilung.

Wenn Sie ein Stück Software für andere entwickeln, sollten Sie es so gestalten , dass sie überall installiert werden können Leute wollen, aber es sollte zu den regulären Standard FHS angegebenen Systemverzeichnisse , wenn sie das Präfix angeben sein /usr( /etc, /usr/binusw.)

Das heißt, es /usr/localist für Ihren persönlichen Gebrauch und sollte nicht der einzige Ort sein, an dem Sie Ihre Software installieren können.

Lesen Sie sich die FHS genau durch und verwenden Sie die Standard-Linux-Tools, damit Ihre Quelle an einem beliebigen Ort erstellt und installiert werden kann, damit Paketbauer für die verschiedenen Distributionen sie nach Bedarf für ihre Distribution konfigurieren und die Benutzer sie nach /usr/local Belieben einfügen können oder die regulären Systemverzeichnisse, wenn sie es wünschen.

— EightBitTony
quelle

Ja, ich denke, die Anpassung ist gut, aber ich habe mich gefragt, ob /usr/local/etcKonfigurationsdateien für diese Art von Programmen Standard sind.

— Beatgammit

/ usr / local / etc ist etwas, das ich wählen könnte, wenn ich Ihren Daemon aus dem Quellcode baue, aber / etc ist der Ort, den jemand wählen würde, wenn er Ihren Daemon mit Debian oder Ubuntu verpackt.

— EightBitTony

4

Tatsächlich verlangen GNU-Standards, dass das Paket standardmäßig den lokalen Pfad verwendet, da die Leute, die es aus dem Quellcode erstellen, normalerweise nicht angeben, wo. Distributionen ändern es in den nicht lokalen Pfad, wenn sie es packen / erstellen.

— Psusi

@ psusi- Guter Punkt, ich werde sicherstellen, dass dies der Standard ist. Vielleicht werde ich feststellen, wenn mein make install als root oder normaler Benutzer ausgeführt wird. Wenn ich root bin, gehe ich standardmäßig zu / usr / local, wenn ich user bin, zum Home-Verzeichnis des Benutzers. Ich werde auch Konfigurationseinstellungen hinzufügen.

— Beatgammit

@ EightBitTony- Gibt es noch andere Plattformen, die andere Konventionen haben? Ich mache bereits verschiedene Startskripte für die verschiedenen Plattformen (upstart, systemd, init).

— Beatgammit

7

Eine sehr kurze Antwort

/ etc wird von Ihrem Betriebssystem für die Konfigurationsdateien verwendet

/ usr / local / etc kann von Ihnen und Ihrer zusätzlich installierten Software für Ihre Konfigurationsdateien verwendet werden

— AndyM
quelle

4

/usr/local/etcwird in der Linux-Welt selten verwendet. Die Entscheidung, ob Konfigurationsdateien in oder an einem anderen Speicherort gespeichert werden sollen /etc, /usr/local/etcwird im Allgemeinen zur Kompilierungszeit getroffen (und kann häufig über eine Befehlszeilenoption oder eine Umgebungsvariable überschrieben werden). Es spielt keine Rolle, welche Standardeinstellung beim Kompilieren verwendet wird. Stellen Sie lediglich sicher, dass die Einstellung einfach ist (normalerweise eine Option nach --sysconfdirautoconf). Wenn Ihr Daemon für eine Distribution gepackt ist, wird die ausführbare Datei in /usr/sbin(die Standardeinstellung beim Erstellen aus der Quelle sollte sein /usr/local/sbin) und die Konfiguration unter /etc.

Beachten Sie, dass dies /etcnicht der Ort für „viele Anwendungsdaten“ ist. Das geht in /var. Der Standardwert beim Erstellen aus dem Quellcode könnte /var/local/mydaemonoder sein /var/lib/mydaemon. Auch hier gibt es keine strengen Konventionen für die Standardeinstellung beim Erstellen aus dem Quellcode. Es sollte eine Möglichkeit geben, sowohl den Kompilierungsstandard (normalerweise mit configure --localstatedir) als auch den Laufzeitstandard (mit einer Einstellung in einer Konfigurationsdatei, möglicherweise mit einer Befehlszeilenoption oder einer Umgebungsvariablen) zu ändern .

— Gilles 'SO - hör auf böse zu sein'
quelle

Gibt es einen Grund, warum /usr/local/etcnicht sehr oft verwendet wird? Mir gefällt die Idee, die Konfigurationsdateien auf der gleichen Ebene des Dateisystems wie die Binärdateien zu belassen.

— Beatgammit

1

@tjameson Ich weiß nicht, ob es einen weit verbreiteten Grund gibt. BSD macht das so. Als Admin, ich mag , dass alle Konfigurationsdateien (die gesichert und Wechsel kontrolliert werden muss, anders als die Sachen in binund libleben in der gleichen Stelle und so weiter , die neu installiert werden kann).

— Gilles 'SO - hör auf, böse zu sein'

1

Als Arch-Benutzer würde ich / usr / local insgesamt vermeiden und nur / etc für die Konfiguration verwenden. Bei der Installation aus dem Quellcode schreibe ich lieber eine kleine PKGBUILD-Datei, während ich gerade dabei bin, und lade sie möglicherweise in das Arch User Repository (AUR) hoch, und zwar für andere und für mich selbst auf einem anderen Computer in der Zukunft. Gemessen an der Anzahl der Pakete in AUR und der Geschwindigkeit, mit der sie erstellt werden, bin ich nicht allein, wenn ich so denke. Dies erhöht die Wahrscheinlichkeit für alle, dass ein Paket verfügbar ist, anstatt es von der Quelle aus installieren zu müssen, und dass veraltete Speicherorte wie / usr / local vermieden werden.

Debian scheint auch die Idee zu gefallen, ein Paket der Quelle zu erstellen, anstatt irgendetwas in / usr / local zu installieren, daher Dienstprogramme wie checkinstall .

Das Erstellen eines Pakets der Quelle, die Sie installieren möchten, ist eine gute Möglichkeit, um den Speicherort der Dateien zu ermitteln und sicherzustellen, dass einige von ihnen nicht inkonsistent durch ein anderes Paket oder eine andere "make install" -Version überschrieben werden. Die Deinstallation mit "make uninstall" ist keine gute Lösung. Informationen darüber, welche Version installiert ist, können moderne Paketmanager ebenfalls gut nachverfolgen.

Ich würde einfach komplett auf / usr / local verzichten. Es ist kein guter Ort, um etwas abzulegen, nicht um Pakete zu installieren (die systemweiten Verzeichnisse sind geeigneter) und nicht für Benutzer.

— Alexander
quelle