Ich habe eine spannende Aufgabe, die ich nicht gut lösen kann.
Aufgrund verschiedenster Probleme hab ich mich durchgerungen mpd doch als user-Prozess laufen zu lassen.
Dies möchte ich mit eine möglichst allgemeinen Konfiguration einrichten.
Mpd ist ja leider für eine statische Konfiguration optimiert (sprich in /etc/mpd.conf kann man keine Platzhalter für z. B. Den Usernamen zu zeroconf-Geschichte verwenden) und arbeiter mit systemd und pulseaudio nur bedingt zusammen.
Das Problem ist, in mpd.socket wird der Port 6600 fix vergeben. Das passt für einen systemweit laufenden mpd gut, oder wenn es nur einen eingeloggten User gibt.
Aber ein systemweit laufender mpd bringt das Konzept von pulseaudio als User-Service vollkommen durcheinander.
Setze ich mpd nun als Userprozess auf, benötige ich verschiedene Ports, sonst läuft wieder nur ein mpd, und die weiteren starten nicht.
Was hingegen funktioniert ist /etc/systemd/user/mpd.socket folgendes zu verfüttern
ListenStream = 6%U
Dann bekommt jeder mpd der Users den Port 6000+UID
Also 61000,61001, 61002
Auch die Sockets kann man so angeben /run/user/%U/mpd.socket
Aber dann brauch ich für ncmpcpp und mpc eine entsprechende Umgebungsvariable.
Die kann ich in /etc/profile setzen.
Starte ich z. B. mpDris2 mittels systemd --user fehlt mir die Umgebungsvariable.
Starte ich es per xdg-autostart läuft es im scope und beendet sich nicht nach dem letzten logout. Meine session lebt halb weiter.
Setzte ich das Environment mittels pam, hätt ich damit systemd-user und die shell mit dem Environment erwischt, jedoch versteht pam die numerische uid nicht. Der Platzhalter wird leer gesetzt, der MPD_PORT ist 6, MPD_HOST ist /run/user//mpd.socket.
Ich weiß nicht, wo ich sonst noch schrauben kann, um an einer einzigen Stelle dynamisch ein Environment für die shell, das Terminal und system-user setzen kann, das auch die numerische UID kennt...
Lg scientific
Umgebungsvariablen wie am besten setzen
-
- Beiträge: 3022
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Umgebungsvariablen wie am besten setzen
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
-
- Beiträge: 3022
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Umgebungsvariablen wie am besten setzen
Korrektur
Wenn ich die Variablen in /etc/environment setze,
dann ist sie auch genau so in der Shell. Also ${UID} wird nicht aufgelöst...
lg scientific
Wenn ich die Variablen in /etc/environment setze,
Code: Alles auswählen
MPD_PORT=6${UID}
lg scientific
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Re: Umgebungsvariablen wie am besten setzen
Vielleicht verstehe ich dein Problem nicht ganz, aber der Port lässt sich doch in der mpd.conf einstellen. Wenn jeder User seine eigene hat (~/.mpd.conf) sollte das eigentlich gehen.
-
- Beiträge: 3022
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Umgebungsvariablen wie am besten setzen
Genau das möchte ich ja vermeiden... Jedem User eine eigene mpd.conf geben zu *MÜSSEN*, nur damit es funktioniert... mpd als User gestartet nimmt die /etc/mpd.conf, wenn keine User-config-Datei existiert. Dort kann ich einen Port angeben, muss aber nicht. Wenn ich keinen angebe, wird jener genommen, den ich mit mpd.socket vorgebe. Was auch prinzipiell ok ist.CH777 hat geschrieben:Vielleicht verstehe ich dein Problem nicht ganz, aber der Port lässt sich doch in der mpd.conf einstellen. Wenn jeder User seine eigene hat (~/.mpd.conf) sollte das eigentlich gehen.
Aber wenn ich nur eine einzige Datei /etc/systemd/user/mpd.socket habe, wo wiederum nur ein Port vorgegeben ist, dann wollen wieder alle User-Prozesse am selben Port lauschen, was nicht funktioniert.
Wenn ich dann jedem mpd-Prozess manuell einen eigenen Port vorgebe (über eine individuelle mpd.conf im Userverzeichnis), dann muss ich den selben Port als Environment $MPD_PORT exportieren, damit ihn Anwendungen wie mpc oder ncmpcpp und auch mpDris2 übernehmen. Gebe ich keinen Port im Environment oder als Startparameter vor, versucht jedes dieser Programme auf 6600 Kontakt aufzunehmen - was aber fehlschlägt, weil da ja kein mpd lauscht.
mpDris2 über systemd gestartet reißt sogar die ganze User-Session in die Tiefe, wenn es keinen lauschenden mpd am angegebenen Port (Standard eben 6600) vorfindet...
Daher möchte ich gerne über pam_env an einer stelle MPD_HOST und MPD_PORT festlegen. Das geschieht dann sowohl im Shell-Environment, als auch im systemd-User-Prozess...
Nur kann pam_env leider nur @{PAM_USER}, was den USernamen ausspuckt, aber nicht die UID, welche ich für /run/user/$UID/ bzw. den Port 6$UID benötigen würde...
Oder hat jemand eine Idee, wie ich pam die UID und nicht nur den Usernamen entlocken kann?
lg scientific
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
-
- Beiträge: 3022
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Umgebungsvariablen wie am besten setzen
Ein paar neue Erkenntnisse hab ich gewonnen.
Die Zeile in /etc/security/pam_env.conf
wird in der Shell tatsächlich korrekt aufgelöst zu /run/user/1000/mpd.socket
Hänge ich aber ein "OVERRIDE=localhost" an, so hab ich in der Shell dann localhost als MPD_HOST.
Der Mechanismus scheint so zu sein, dass pam prüft, ob ${VARIABLENNAME} vorhanden ist, und wenn nicht, dann kommt OVERRIDE zum Zug.
Gibt es kein OVERRIDE, so wird DEFAULT verwendet, welches dann in der SHELL korrekt aufgelöst wird.
Allerdings bei ${UID} funktioniert das schon wieder nicht mehr. Es funktioniert auch ${USER} nicht, hingegen @{PAM_USER} schon.
Und...
für systemd als Userprozess gestartet von user@1000.service werden diese Werte ebenfalls nicht übernommen...
Also muss ich doch das Environment auf anderem Weg in die user-services für mpd & Co (mpDris2) bringen.
lg scientific
Die Zeile in /etc/security/pam_env.conf
Code: Alles auswählen
MPD_HOST DEFAULT=${XDG_RUNTIME_DIR}/mpd.socket
Hänge ich aber ein "OVERRIDE=localhost" an, so hab ich in der Shell dann localhost als MPD_HOST.
Der Mechanismus scheint so zu sein, dass pam prüft, ob ${VARIABLENNAME} vorhanden ist, und wenn nicht, dann kommt OVERRIDE zum Zug.
Gibt es kein OVERRIDE, so wird DEFAULT verwendet, welches dann in der SHELL korrekt aufgelöst wird.
Allerdings bei ${UID} funktioniert das schon wieder nicht mehr. Es funktioniert auch ${USER} nicht, hingegen @{PAM_USER} schon.
Und...
für systemd als Userprozess gestartet von user@1000.service werden diese Werte ebenfalls nicht übernommen...
Also muss ich doch das Environment auf anderem Weg in die user-services für mpd & Co (mpDris2) bringen.
lg scientific
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main