Pfad global für alle Benutzer ändern, auch in Cron

Question

Wir richten einen SGE-Cluster mit CentOS 6 ein. Mein Systemadministrator installiert Anwendungen, die nicht über RPM (also über andere Mittel wie make install) installiert werden, in ein nicht standardmäßiges Verzeichnis, in diesem Fall etwa /share/apps/install/bin/. Der Pfad hierfür wird derzeit den meisten Sitzungen (Login, Qlogin usw.) über hinzugefügt, /share/apps/etc/environment.shdas von aufgerufen wird /etc/bashrc. environment.shhängt auch einiges an die PERL5LIB an.

Das Problem, auf das ich stoße, ist, dass es /share/apps/install/bineinigen Instanzen nicht hinzugefügt wird, z. B. Dingen, die aus einer Crontab aufgerufen werden.

Ich weiß, dass ich dies manuell und explizit PATH=/bin:/usr/bin:/blah/blah:...in meiner persönlichen Crontab oder in jedem beliebigen Skript oder Crontab-Eintrag festlegen kann, aber ich hoffe, dass es irgendwo außerhalb eine Einstellung gibt /etc/profileoder /etc/bashrcdass diese das nicht standardmäßige Verzeichnis in alle PATHs für alle Benutzer einfügt .../bin.

Answer 1

Fügen Sie eine Datei mit dem gewünschten Wert PATHhinzu /etc/profile.d. Diese Dateien sind so eingerichtet, dass sie von Shells wie Bash, Csh, Zsh oder tcsh aufgerufen werden können.

Beispiel

Wir mussten unserem PATH den folgenden Wert hinzufügen.

/usr/local/share/bin

Daher haben wir eine Datei /etc/profile.d/ourstuff.shmit der folgenden Zeile erstellt:

export PATH=/usr/local/share/bin:$PATH

Dateien mit dieser Erweiterung .shstammen von Shells wie Bash und Zsh. Dateien mit dieser Erweiterung .cshstammen von Csh und tcsh.

BEARBEITEN #1 - Nachverfolgung

OP hat die folgende Folgefrage gestellt.

Ja, aber was ist mit Cron-Jobs? Gibt es eine Möglichkeit, den Pfad auch dort abzurufen? Cron scheint /etc/profile oder /etc/bashrc nicht aufzurufen.

Worauf ich antwortete:

Richtig, das tut es nicht und wird es auch nicht. Sie müssen SHELL=/bin/bashin Cron festlegen, um die Standard-Shell zu überschreiben (normalerweise /bin/sh). Sie können auch dies für Benutzer-Crons festlegen, BASH_ENV="$HOME/.bashrc", und dies für System-Crons, BASH_ENV="/root/.bashrc". Das wäre eine Möglichkeit, dies zu umgehen.

Ich rate Ihnen dringend davon ab, dies zu tun. Lassen Sie die Skripte, die eine bestimmte Umgebung benötigen, diese selbst einrichten. Versuchen Sie nicht, jedes Problem auf globaler Ebene zu lösen!

Answer 2

Sie können Umgebungsvariablendefinitionen einfügen /etc/environment(vorausgesetzt, Ihr System lädtpam_envfür alle Dienste, was auf allen modernen nicht eingebetteten Linux-Systemen die Standardeinstellung sein sollte).

Beachten Sie, dass Sie nur statische Umgebungsvariablendefinitionen in der Form VARIABLE=VALUEoder VARIABLE="VALUE"mit einer Definition pro Zeile eingeben können. Sie können keine beliebigen Shell-Befehle verwenden, Sie können nicht auf den Wert einer anderen Variable verweisen, indem Sie schreiben FOO=hello+$BAR(das setzt einen Literalwert $in den Wert von FOO), usw. Solange Sie sich an einfache Zuweisungen wie halten PATH=/usr/local/bin:/usr/bin:/bin:/share/apps/install/bin, ist alles in Ordnung (beachten Sie, dass Sie dort nicht das Home-Verzeichnis des Benutzers verwenden können: Der Wert muss für alle Benutzer derselbe sein).

Answer 3

Letztendlich haben wir eine mehrgleisige Lösung gewählt, um Pfadprobleme zu vermeiden. Je nach Anwendungsfall haben wir eine oder mehrere der folgenden Möglichkeiten genutzt:

• Verwendete absolute Pfade zu den an nicht standardmäßigen Orten installierten Binärdateien, anstatt zu erwarten, dass sich die Binärdatei im Pfad befindet. Dies wurde für Tools verwendet, die nur wenige oder gar keine nicht standardmäßigen externen Abhängigkeiten haben und/oder isoliert arbeiten.
• Erstellte und verwendete ein Wrapper-Skript für ein Tool, das die Umgebung nach Bedarf einrichtete; manuelles Festlegen PATH=... innerhalb dieses Skripts und/oder Ausführen source $HOME/.bashrcnach Bedarf. Dies wurde für Tools verwendet, die andere Tools benötigten, aber ansonsten auf unserem Cluster ausgeführt werden konnten.
• Erstellt einen Container (in unserem Fall Docker) einschließlich der Binärdateien und eines komplexeren Setups. Dies wurde für Tools verwendet, die eine Umgebung erfordern, die sich erheblich von unserem Standard-Cluster-Setup unterscheidet.