Anwendungs- / HTTP-Dienste unter "/ srv" installieren?

Ich habe mit einem Team zusammengearbeitet, das alle Anwendungs- und HTTP-Dienste wie Apache oder Tomcat im Verzeichnis '/ srv' installiert hat. Ich vermute meistens, um die installierten Dienste so weit wie möglich vom Betriebssystem zu trennen. Für meine eigenen Projekte habe ich diese Praxis beibehalten. Im Laufe der Zeit sah es jedoch immer mehr so ​​aus, als wäre dies keine sehr gute Idee: Es hindert Sie daran, verteilungsspezifische Pakete zu verwenden (sie hatten in diesem Team einen sehr schlechten Ruf, daher handelte es sich meistens nur um benutzerdefinierte Installationen), und ich bemerkte dies Ich hatte einige Probleme, als ich versuchte, Kochbücher zu verwenden, die bereits verfügbar sind.

In letzter Zeit war ich versucht, auf die Verwendung verteilungsspezifischer Pakete umzusteigen, anstatt zu versuchen, benutzerdefinierte Installationen zu erstellen, die in diese Verzeichnisstruktur passen. Ich habe mich gefragt, ob es etwas gibt, das ich übersehen könnte. Gibt es tatsächlich einen guten Grund, alles in ein '/ srv'-Verzeichnis zu stellen, oder einen guten Grund, die verteilungsspezifischen Pakete nicht zu verwenden?

Was ich derzeit in meinem Stack benötige, ist: nginx , Tomcat (Oracle JDK ) und MongoDB .

Der FHS - konform Pfad zu installieren Software von Drittanbietern ist nicht /srv, aber /opt. Überprüfen Sie hier und hier .

In Bezug darauf, ob vorkompilierte Pakete verwendet werden sollen oder nicht, haben Sie zwei Möglichkeiten:

• Verwenden Sie sie, wenn Sie dem Anbieter in Bezug auf Sicherheitsupdates und Bugfixes vertrauen. Ich würde, sie haben sicherlich mehr Arbeitskräfte und Ressourcen für diese Aufgabe als Ihr Unternehmen. Sie können weiterhin die Standard-Repositorys und die Paketinfrastruktur des Betriebssystems verwenden. Sie können mit der vom Anbieter bereitgestellten Version (plus Backport-Fixes) leben.
• Verwenden Sie sie nicht, und Patch Ihre selbstgebrautes Installation jedes Mal eine neue Schwachstelle wird öffentlich gemacht . Sie müssen Ihre privaten Repositorys verwalten (Sie können alles auch jedes Mal manuell installieren). Sie können neuere Versionen der Software verwenden.

Wenn Sie nur 5-10 Maschinen warten müssen, /optist es machbar, alles unterzubringen. Wenn Sie jedoch eine Farm von mehr als ein paar Hundert unterhalten, würden Sie es falsch machen

Meiner Meinung nach besteht der professionelle Weg darin, die vom Hersteller bereitgestellten vorkompilierten Pakete zu verwenden, es sei denn, es gibt einen zwingenden Grund, dies nicht zu tun.

Ich denke nicht, dass /srves jemals eine gute Idee war. Für diesen Fall ist es /usr/localoder /optVerzeichnis, während /srvfür die ortsspezifische Daten, die durch das System bedient werden.

Dies wird durch den Dateisystem-Heararchy-Standard definiert. Beachten Sie, dass nicht in allen Distributionen 100% folgen. FHS schlägt dies vor:

• /srv - Standortspezifische Daten, die vom System bereitgestellt werden.
• /opt - Optionale Anwendungssoftwarepakete.

In Bezug auf Distribution-spezifische Pakete sollten Sie diese im Allgemeinen verwenden, es sei denn, es gibt einen sehr guten Grund, dies nicht zu tun. Es kann zu schwierig sein, alles auf dem neuesten Stand zu halten und sicherzustellen, dass Sie über die neuesten Patches verfügen, und das System kann zusätzlichen Sicherheitsrisiken ausgesetzt sein. Selbst in den Fällen, in denen der Paketmanager Ihrer Linux-Distribution eine ältere als die erforderliche Version bereitstellt, finden Sie in der Regel von der Community verwaltete Repositorys für neuere Versionen bestimmter Pakete, die einfacher zu warten sind als Ihre eigenen Pakete. Dies ist normalerweise bei populäreren Paketen der Fall, wie nginxbei Verteilungen wie CentOS(persönliche Erfahrung).

Was ich /srvstattdessen behalten würde (denken Sie daran, dies ist eine persönliche Präferenz):

• http vhost-basierte Verzeichnisse (zB /srv/http/example.com)
• ftpsites (zB /srv/ftp/example.com)
• Postfächer (zB /srv/mail/example.com/user)

Dies hilft mir, /srv/mit normalerweise verwalteten Daten organisiert zu bleiben , während die meisten Distributionen diese Dateien behalten würden. /varIch verwende dies, damit ich dieselbe Verzeichnisstruktur für gemeinsame standortspezifische Daten über verschiedene Distributionen hinweg haben kann.

Dieses spezielle Beispiel, bei dem jedes Paket auf / srv ausgerichtet wird, obwohl es eine Form der Arbeitsplatzsicherheit darstellt, erscheint aus geschäftlicher Sicht einzigartig kurzsichtig und unproduktiv (wobei produktiv bedeutet, die Benutzerfreundlichkeit / Rentabilität / Sicherheit / etc. Der Arbeitsumgebung, für die diese Anwendungen eingesetzt werden, zu verbessern). .

Wenn Sie damit leben können, was ein Distributionspaket mit Ihrem System macht, nutzen Sie die Entwicklung und testen das Team, das das Paket erstellt, jetzt und mit den Updates. Wenn Sie nicht mit dem leben können, was das Distributionspaket mit Ihrem System macht, suchen Sie ein anderes Paket oder überzeugen Sie die Entwicklungsgruppe, Dinge "auf Ihre Weise" zu tun (oder machen Sie es zumindest einfacher, es "auf Ihre Weise" zu tun). ) oder kapseln Sie es in eine virtuelle Maschine. Oder setzen Sie den geringsten Aufwand ein, um das tatsächliche / wahrgenommene Problem zu beheben und die Bereitstellung und das Konfigurationsmanagement mit Ihrem bevorzugten Toolset zu automatisieren. Um Dijkstra zu paraphrasieren: Einfachheit und Wiederholbarkeit sind Voraussetzungen für Zuverlässigkeit.