Hi! Michael Gengenbach wrote:

...

Was habe ich zu tun, um die Umgebungsvariable REMOTEHOST von meinem System belegen zu lassen?

Ich möchte in einem Skript die DISPLAY-Variable setzen, muß aber irgendwie rausfinden, vor welchem host der Benutzer sitzt.

ich verstehe zwar nicht ganz, was Du damit meinst, "die Umgebungsvariable REMOTEHOST von meinem System belegen zu lassen", aber der nächste Absatz klingt so, als ob Du X11-Applikationen bequem in einem Netzwerk verwenden willst.

Ich meine, wenn ich mich via ssh -X auf dem Rechner anmelde und mir die Variablen mittels # env anzeigen lasse, dann steht da nichts von REMOTEHOST. Vielleicht war "nicht belegt" etwas umständlich ausgedrückt.

Und hierfür kann ich ein schönes Script empfehlen: xrsh

Das ist wie rsh, nur daß es sich gleichzeitig auch um die DISPLAY-Variable und um die Authentisierung (z.B. xhost) kümmert.

Man verwendet das so:

xrsh remotehost xterm

Ich würde das gerne mit Bordmitteln lösen. Der Benutzer soll mit ssh auf den Rechner zugreifen. Das Skript ist ganz nett aber leider nicht ganz das was ich suche :( CU Martin

Thorsten Haude wrote:

Moin,

* Martin Oehler [02-04-16 08:39]:

...

Ich meine, wenn ich mich via ssh -X auf dem Rechner anmelde und mir die Variablen mittels # env anzeigen lasse, dann steht da nichts von REMOTEHOST. Vielleicht war "nicht belegt" etwas umständlich ausgedrückt. Wofür soll dieses $REMOTEHOST denn gut sein? Für X brauchst Du nur $DISPLAY.

Ich setze die DISPLAY-Variable mit # export DISPLAY=<remotehost>:0 Dann klappt alles mit xcdroast. root wie user. Als root brauche ich das nichtmal, da reicht ssh -X. Als "normaler User" haben einige buttons des Programms keinen Text, wenn man nur ssh -X benutzt. Das ist sehr seltsam, aber nach setzen der DISPLAY- Variablen ist alles in Ordnung. Ich dachte an eine Lösung ala (nu im Skript) export DISPLAY=$REMOTEHOST:0

...

Ich würde das gerne mit Bordmitteln lösen. Der Benutzer soll mit ssh auf den Rechner zugreifen. Woran scheitert das?

s.o., die Benutzer brauchen die DISPLAY-Variable, damit xcdroast richtig funktioniert. CU Martin P.S.: natürlich alles aktuelle Pakete. -- You're either against me, or you will be!

Hi! Thorsten Haude wrote:

* Martin Oehler [02-04-16 08:11]:

...

Ich möchte in einem Skript die DISPLAY-Variable setzen, muß aber irgendwie rausfinden, vor welchem host der Benutzer sitzt.

Warum läßt Du das nicht den Benutzer machen? Noch besser: Verbiete alles außer ssh.

Ok, ich muß wohl etwas länger ausholen... :) Ich will Linux für meine Benutzer attraktiv machen. Leider beschränken sich deren Kenntnisse im Moment sich darauf, sich einzuloggen und den Citrix ICA-Client zu starten :( Wenn ich von denen verlange, die DISPLAY-Variable selbst zu setzen, benutzt das keiner und die Leute brennen wieder unter Windows. Diese extrem geschulten (*verzweifel*) Anwender sollen sich nun auf einem kleinen Rechner einloggen (aus Sicherheitsgründen per ssh) und dort einfach # brenner eintippen (vergessen wir das "&"). So wirds in der motd stehen. Dann soll xcdroast starten. Das ganze ist schon soweit, dass nur noch das setzen der DISPLAY-Variablen fehlt. Dafür brauche ich aber den remote host. Habe ich aber irgendwie nicht. CU Martin

Hi! Thorsten Haude wrote:

* Martin Oehler [02-04-16 08:49]:

...

Dafür brauche ich aber den remote host. Habe ich aber irgendwie nicht.

Ich denke doch, daß ssh weiß, auf welchem Rechner es gestartet wird. Hast Du schon versucht, $DISPLAY auf dem Client zu setzen? (Einen X-Server gibt es doch, oder?)

Jo, X-Server ist vorhanden (brauchte ich allein schon wegen xauth). Nach dem Setzen von $DISPLAY ist die Welt in Ordnung (siehe andere mail). Nach dem einloggen ist $DISPLAY aber auch nicht gesetzt (genau wie $REMOTEHOST).

echo $DISPLAY DISPLAY: Undefined variable.

CU Martin -- You're either against me, or you will be!

Hallo! Thorsten Haude wrote:

Ist $DISPLAY auf dem Client gesetzt, bevor Du ssh aufrufst?

// auf irgendeinem lokalen Unix/Linux-Rechner

echo $DISPLAY :0.0

ssh -X vulcan // das ist der Brenner-Rechner [...] echo $DISPLAY vulcan:10.0

DISPLAY ist also auf dem client gesetzt. Ich suche jetzt mal bei den Unix-Kisten, wie da REMOTEHOST gesetzt wird. Das muß dann ja für Linux anpassbar sein. Wenn nicht habe ich ja das gepostete Skript. CU Martin

Thorsten Haude wrote:

Moin,

* Martin Oehler [02-04-16 13:49]:

...

Thorsten Haude wrote:

...

Ist $DISPLAY auf dem Client gesetzt, bevor Du ssh aufrufst? // auf irgendeinem lokalen Unix/Linux-Rechner echo $DISPLAY :0.0

...

ssh -X vulcan // das ist der Brenner-Rechner [...] echo $DISPLAY vulcan:10.0

DISPLAY ist also auf dem client gesetzt. Offensichtlich doch auch auf der remote Box. Warum klappt das nicht?

Das klappt nur gescheit, wenn da steht <REMOTEHOST>:0 statt vulcan:10.0 also irgendein Rechner:0 Wobei in obigem Beispiel <REMOTEHOST> entweder eine Linux-oder Unix-Kiste ist. Mit "vulcan:10.0" vertragen sich die untersten zwei Buttons vom xcdroast nicht (so traurig oder witzig das auch sein mag). Man kommt nach einer Auswahl nicht mehr ins Hauptmenü 8( CU Martin

Hi! Thorsten Haude wrote:

* Martin Oehler [02-04-16 14:20]:

...

...

...

...

echo $DISPLAY vulcan:10.0

DISPLAY ist also auf dem client gesetzt. Offensichtlich doch auch auf der remote Box. Warum klappt das nicht? Das klappt nur gescheit, wenn da steht <REMOTEHOST>:0 statt vulcan:10.0 Dann ist etwas an Deiner ssh-Installation schief. $DISPLAY wird von ssh auf einen *lokalen* Schirm gesetzt und dann geforwardet.

Jo klar, ich sitze z.B. an foo (lokaler Schirm). Der Rechner mit dem Brenner ist vulcan. Per ssh auf den vulcan, dann sollte da stehen foo:0 statt vulcan:0 Denn foo ist der lokale Rechner und vulcan steht ohne Monitor im Schrank. Oder bin ich jetzt verdreht?

...

Mit "vulcan:10.0" vertragen sich die untersten zwei Buttons vom xcdroast nicht (so traurig oder witzig das auch sein mag). Man kommt nach einer Auswahl nicht mehr ins Hauptmenü 8( Oder es liegt an xcdroast, das kann ich mir aber kaum vorstellen. Hast Du mal gegoogelt?

Ja, das Problem scheint neu. xcdroast tut ja schon seiner Versions- nummer nach immer unschuldig... CU Martin -- You're either against me, or you will be!

Am Die, 2002-04-16 um 15.33 schrieb Thorsten Haude:

Moin,

* Martin Oehler [02-04-16 15:06]:

...

Thorsten Haude wrote:

...

* Martin Oehler [02-04-16 14:20]:

...

...

...

> echo $DISPLAY vulcan:10.0

DISPLAY ist also auf dem client gesetzt. Offensichtlich doch auch auf der remote Box. Warum klappt das nicht? Das klappt nur gescheit, wenn da steht <REMOTEHOST>:0 statt vulcan:10.0 Dann ist etwas an Deiner ssh-Installation schief. $DISPLAY wird von ssh auf einen *lokalen* Schirm gesetzt und dann geforwardet. Jo klar, ich sitze z.B. an foo (lokaler Schirm). Der Rechner mit dem Brenner ist vulcan. Per ssh auf den vulcan, dann sollte da stehen foo:0 statt vulcan:0 Denn foo ist der lokale Rechner und vulcan steht ohne Monitor im Schrank. Oder bin ich jetzt verdreht? Jetzt machst Du mich auch unsicher. Wenn ich mich recht erinnere, zeigt $DISPLAY auf einen lokalen virtuellen Schirm, also auf vulcan:0.

Mein Buch ist leider im Büro.

machen wirs doch einfach: du hast eine workstation und ein server => server$ DISPLAY=workstation:0.0 dann leitet der server die darstellung von X auf die workstation um. -- mfg alex ------------------------------------------------------------------------ I am chaos. I am the substance from which your artists and scientists build rhythms. I am the spirit with which your children and clowns laugh in happy anarchy. I am chaos. I am alive, and tell you that you are free

Am Die, 2002-04-16 um 16.04 schrieb Thorsten Haude:

Moin,

* Alexander Thoma [02-04-16 15:49]:

...

machen wirs doch einfach: du hast eine workstation und ein server

=> server$ DISPLAY=workstation:0.0

dann leitet der server die darstellung von X auf die workstation um. So einfach ist das bei ssh IIRC nicht.

wenn du sshd mit XForwarding gestartet hast und deine ssh sessin mit -X startest, was willst du noch machen ???? das ist alles. mehr gibt's nicht. auserdem war eure letzte diskusion in diesem zweig, was in display aif dem server stehen muss. aber hol mal dein buch.

Thorsten -- Das Briefgeheimnis sowie das Post- und Fernmeldegeheimnis sind unverletzlich. - Grundgesetz, Artikel 10, Abs. 1

-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com -- mfg alex

------------------------------------------------------------------------ I am chaos. I am the substance from which your artists and scientists build rhythms. I am the spirit with which your children and clowns laugh in happy anarchy. I am chaos. I am alive, and tell you that you are free

Am Die, 2002-04-16 um 16.25 schrieb Thorsten Haude:

Hi,

* Alexander Thoma [02-04-16 16:17]:

...

wenn du sshd mit XForwarding gestartet hast und deine ssh sessin mit -X startest, was willst du noch machen ???? das ist alles. mehr gibt's nicht. auserdem war eure letzte diskusion in diesem zweig, was in display aif dem server stehen muss. aber hol mal dein buch. Das wird mir jetzt zu anstrengend, benutz mal bitte vernünftige Groß- und Kleinschreibung.

wenns daran liegt. ausser uns deutschen hat diesen scheiss keine sau. vieleicht gibts gross- und kleingeschriebene japanische schriftzeichen. aber wenns an sowas scheitert .... -- mfg alex ------------------------------------------------------------------------ I am chaos. I am the substance from which your artists and scientists build rhythms. I am the spirit with which your children and clowns laugh in happy anarchy. I am chaos. I am alive, and tell you that you are free

Am Die, 2002-04-16 um 09.22 schrieb Martin Oehler:

Hi!

Genau sowas suche ich - dankeschön! Allerdings würde mich trotzdem interessieren, warum REMOTEHOST nicht gesetzt wird. Bei meinen Unix-Kisten ist das anders... trotz gleicher ssh-Version.

CU Martin

das wird nicht von ssh gemacht. such mal in den scripten deiner aunderen unices die beim einloggen durchlaufen werden. ich tippe das wird dort irgendwo so aehnlich gemacht. kommt halt auf die schell des unix an auf dem du nachschaust. es sollte aber beim einloggen passieren. -- mfg alex ------------------------------------------------------------------------ I am chaos. I am the substance from which your artists and scientists build rhythms. I am the spirit with which your children and clowns laugh in happy anarchy. I am chaos. I am alive, and tell you that you are free

Moin, * Bernd Brodesser [02-04-16 09:34]:

Du kanst keine Umgebungsvariable auf Dein ganzes System setzen. Du kanst nur einen Prozeß und all dessen Kindprozesse eine Umgebungsvariable geben. Wenn wirklich alle Prozesse diese Umgebungsvariable haben sollen, dann müßtest Du schon init selber umprogrammieren. Garantiert init(8) den gettys nicht eine leere Umgebung? Dann würde es garnicht gehen.

Thorsten -- Fear leads to anger. Anger leads to hate. Hate leads to using Windows for mission-critical applications.

Moin, * Bernd Brodesser [02-04-16 10:42]:

* Thorsten Haude schrieb am 16.Apr.2002:

...

* Bernd Brodesser [02-04-16 09:34]:

...

Du kanst keine Umgebungsvariable auf Dein ganzes System setzen. Du kanst nur einen Prozeß und all dessen Kindprozesse eine Umgebungsvariable geben. Wenn wirklich alle Prozesse diese Umgebungsvariable haben sollen, dann müßtest Du schon init selber umprogrammieren. Garantiert init(8) den gettys nicht eine leere Umgebung? Dann würde es garnicht gehen. Ich glaube, init setzt auch schon was. $HOME, $LOGIN, $SHELL, $TERM usw. werden von getty und Nachfolgeprogramme gesetzt, aber was it mit $PATH, $IFS und andere? Hört sich an, als wären das Jobs für die Shell.

Thorsten -- Denn ein Tyrann ist nicht, wenn die Masse nicht geduldig stillhält. - Kurt Tucholsky

Moin, * Bernd Brodesser [02-04-16 13:02]:

* Thorsten Haude schrieb am 16.Apr.2002:

...

* Bernd Brodesser [02-04-16 10:42]:

...

* Thorsten Haude schrieb am 16.Apr.2002:

...

* Bernd Brodesser [02-04-16 09:34]:

...

Du kanst keine Umgebungsvariable auf Dein ganzes System setzen. Du kanst nur einen Prozeß und all dessen Kindprozesse eine Umgebungsvariable geben. Wenn wirklich alle Prozesse diese Umgebungsvariable haben sollen, dann müßtest Du schon init selber umprogrammieren. Garantiert init(8) den gettys nicht eine leere Umgebung? Dann würde es garnicht gehen. Ich glaube, init setzt auch schon was. $HOME, $LOGIN, $SHELL, $TERM usw. werden von getty und Nachfolgeprogramme gesetzt, aber was it mit $PATH, $IFS und andere? Hört sich an, als wären das Jobs für die Shell. $IFS ja, ziehe ich hiermit zurück. Aber was ist mit $PATH? Ich meine nicht das, was in /etc/profile gesetzt wird. Auch bei den initskripten, bei cron und ip-up, die ja nicht /etc/profile durchlaufen gibt es ein rudimentären Pfad. Kann ja trotzdem die Shell erledigen.

Ich kenne keine Details, ist also alles Spekulation. Thorsten -- Kaufen, was einem die Kartelle vorwerfen; lesen, was einem die Zensoren erlauben; glauben, was einem die Kirche und Partei gebieten. Beinkleider werden zur Zeit mittelweit getragen. Freiheit gar nicht. - Kurt Tucholsky