Beispiel für Login

[Christian Kruse]

Hallo pl,

Hab ich Dir ja auch geschrieben: Da kannst Du Dir den Umweg über Globale Variablen auch sparen. MfG

Ich glaube, du hast es immer noch nicht verstanden. Man verwendet Umgebungsvariablen, damit man die Konfiguration einer einzelnen Installation nicht im Repository hat. Denn dann hätte man ja bei jeder Installation lokale Änderungen im Repository. Das ist unpraktisch, kann zu Problemen führen und nervt. Stattdessen verwendet man Umgebungsvariablen, die dann in z.B. der Service-File gesetzt werden. Die SystemD-Unit-File für die Produktiv-Installation einer meiner Services etwa sieht so aus:

[Unit]
Description=Automatic Call Distribution
After=network.target

[Service]
Type=simple
User=acd
Group=web-services
Restart=on-failure
RestartSec=5
Environment=MIX_ENV=prod
Environment=LANG=en_US.UTF-8
Environment=PORT=4000
Environment=DB_HOST=localhost
Environment=DB_USER=acd
Environment=DB_NAME=acd_prod
WorkingDirectory=/opt/acd
ExecStart=/opt/acd/bin/acd foreground
ExecStop=/opt/acd/bin/acd stop

[Install]
WantedBy=multi-user.target

Damit weiss SystemD alles, was es wissen muss und ich habe keine Konfigurationsdaten in meinem Repo. Dieses Vorgehen unterscheidet sich von deinem CLI-Argumente-Vorgehen nicht wesentlich, ausser dass die Argumente in einem einfachen ps einsehbar sind, das Environment eines Prozesses aber nicht.

LG,
CK