2
Wo werden die Umgebungsvariabeln generiert?
Umgebungsvariablen beibringen
Grundsätzlich möchte ich wissen, wie ich Linux beim Hochfahren neue,
persistente Umgebungsvariablen beibringen kann, die dann jedem Service (also
z.B. Apache) oder sofort in der Shell zur Verfügung stehen. Damit meine ich
NICHT die Modifikation von .profile o.ä., welche ja immer benutzerabhängig
ist. Im Folgenden erkläre ich kurz, wofür ich das brauche...
Ich hab nen Webserver, auf dem ich für bestimmte Zeichenroutinen einen
Xserver brauche. Nun ist es ja ein bißchen übertrieben, dafür XFree86 zu
starten. Statt dessen fahre ich den mit XFree86 mitgelieferten virtuellen
Service Xvfb über /etc/inittab mit
Xvfb:4:wait:/usr/X11R6/bin/Xvfb :0 -screen 0 1024x768x6
in Runlevel 4 hoch. Nun möchte ich aber, daß alle Prozesse über
setenv DISPLAY=":0.0"
von diesem Service unterrichtet werden, insbesondere auch die von Apache
getriggerten CGI-Scripte. D.h., ich muß die richtige Stelle finden im
Linux-Bootprozess, um diesen Befehl so zu platzieren, daß er allen clients
automatisch zur Verfügung steht. Im Moment setze ich diese Variable im
Script immer manuell, bevor ich die Zeichnungsbefehle ausführe. Das klappt
bisweilen auch gut, doch bei jeder anderen Serverkonfiguration müßte ich das
Script ändern, und das kann es ja nicht sein. Im Moment finde ich z.B. über
einen entsprechenden Befehl im CGI-Script (mod_python) folgende
Umgebungsvariablen:
TERM=linux
CONSOLE=/dev/console
SHLVL=2
RUNLEVEL=2
PREVLEVEL=N
PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin
PWD=/
runlevel=2
BOOT_IMAGE=Linux
INIT_VERSION=sysvinit-2.84
_=/usr/sbin/httpd
previous=N
Wo zum Teufel werden die denn generiert? Wenn ich das weiß, könnte ich ja
theoretisch meine eigenen einfach dazu schreiben und wäre raus aus der
Nummer. Komischerweise sagt die RUNLEVEL-Variable, daß der Rechner auf
Runlevel 2 läuft, obwohl er tatsächlich auf Runlevel 4 hochgefahren ist.
Naja..
bin dankbar für jede Hilfe.
Grundsätzlich möchte ich wissen, wie ich Linux beim Hochfahren neue,
persistente Umgebungsvariablen beibringen kann, die dann jedem Service (also
z.B. Apache) oder sofort in der Shell zur Verfügung stehen. Damit meine ich
NICHT die Modifikation von .profile o.ä., welche ja immer benutzerabhängig
ist. Im Folgenden erkläre ich kurz, wofür ich das brauche...
Ich hab nen Webserver, auf dem ich für bestimmte Zeichenroutinen einen
Xserver brauche. Nun ist es ja ein bißchen übertrieben, dafür XFree86 zu
starten. Statt dessen fahre ich den mit XFree86 mitgelieferten virtuellen
Service Xvfb über /etc/inittab mit
Xvfb:4:wait:/usr/X11R6/bin/Xvfb :0 -screen 0 1024x768x6
in Runlevel 4 hoch. Nun möchte ich aber, daß alle Prozesse über
setenv DISPLAY=":0.0"
von diesem Service unterrichtet werden, insbesondere auch die von Apache
getriggerten CGI-Scripte. D.h., ich muß die richtige Stelle finden im
Linux-Bootprozess, um diesen Befehl so zu platzieren, daß er allen clients
automatisch zur Verfügung steht. Im Moment setze ich diese Variable im
Script immer manuell, bevor ich die Zeichnungsbefehle ausführe. Das klappt
bisweilen auch gut, doch bei jeder anderen Serverkonfiguration müßte ich das
Script ändern, und das kann es ja nicht sein. Im Moment finde ich z.B. über
einen entsprechenden Befehl im CGI-Script (mod_python) folgende
Umgebungsvariablen:
TERM=linux
CONSOLE=/dev/console
SHLVL=2
RUNLEVEL=2
PREVLEVEL=N
PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin
PWD=/
runlevel=2
BOOT_IMAGE=Linux
INIT_VERSION=sysvinit-2.84
_=/usr/sbin/httpd
previous=N
Wo zum Teufel werden die denn generiert? Wenn ich das weiß, könnte ich ja
theoretisch meine eigenen einfach dazu schreiben und wäre raus aus der
Nummer. Komischerweise sagt die RUNLEVEL-Variable, daß der Rechner auf
Runlevel 2 läuft, obwohl er tatsächlich auf Runlevel 4 hochgefahren ist.
Naja..
bin dankbar für jede Hilfe.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2113
Url: https://administrator.de/forum/wo-werden-die-umgebungsvariabeln-generiert-2113.html
Ausgedruckt am: 11.01.2025 um 10:01 Uhr
2 Kommentare
Neuester Kommentar
hmm, da gibt es viele Möglichkeiten (hier Debain 3).
1) das globale "/etc/profile File", das für alle User gilt.
2) das globale Bash "/etc/bash.bashrc" File, was für alle Bash Umgebungen gilt
3) die einzelnen Runlevels (z.B. /etc/rc2.d/) , dort könntest Du ein eigens Script laufen lassen, das die Variablen setzt (z.B. S99setvar oder öhnlich)
4) dann gibt es och die Console allgemein (/etc/console-tools/config)
5) und zu guter letzt noch das Globale X11 File (/etc/X11/Xsession)
Ich hoffe ich konnte Dir weiterhelfen
Gruß
Frank
1) das globale "/etc/profile File", das für alle User gilt.
2) das globale Bash "/etc/bash.bashrc" File, was für alle Bash Umgebungen gilt
3) die einzelnen Runlevels (z.B. /etc/rc2.d/) , dort könntest Du ein eigens Script laufen lassen, das die Variablen setzt (z.B. S99setvar oder öhnlich)
4) dann gibt es och die Console allgemein (/etc/console-tools/config)
5) und zu guter letzt noch das Globale X11 File (/etc/X11/Xsession)
Ich hoffe ich konnte Dir weiterhelfen
Gruß
Frank
Tja, es hilft alles nix. Einige der Punkte hatte ich noch nicht ausprobiert,
doch zielen alle mehr oder weniger auf die Umgebung der Shell und nicht die
der Prozesse ab. Nicht mal das Einbinden eines Scripts in rc2345.d mit nur
einem einzigen export-call hatte den gewünschten Effekt, im Gegenteil: der
Export aus dem Script erschien noch nichtmal in der Shell.
Keine Ahnung, wie mod_python an diese Variablen kommt, aber es ist jetzt
auch schon zu viel Zeit mit diesem Tinnef verflogen, so daß wir das Ganze
erstmal Quick&Dirty lösen müssen.
doch zielen alle mehr oder weniger auf die Umgebung der Shell und nicht die
der Prozesse ab. Nicht mal das Einbinden eines Scripts in rc2345.d mit nur
einem einzigen export-call hatte den gewünschten Effekt, im Gegenteil: der
Export aus dem Script erschien noch nichtmal in der Shell.
Keine Ahnung, wie mod_python an diese Variablen kommt, aber es ist jetzt
auch schon zu viel Zeit mit diesem Tinnef verflogen, so daß wir das Ganze
erstmal Quick&Dirty lösen müssen.
