[linux-l] Re: DB's im www

[Volker Grabsch]

On Tue, Dec 26, 2006 at 03:15:29AM +0100, Steffen Dettmer wrote:
> Richtig cool ist ein Script, was noch ausgibt
> "PostgreSQL-Sicherheitsverbindung aktiv" oder so (echo, cat), damit die
> Benutzer nicht nachher noch Fenster wegklicken und sich wundern, warum
> dann immer auch die DB weg ist lol

Das wollte ich vermeiden, indem ich das SSH *richtig* in den Hintergrund
schicke, wie einen System-Daemon. Wie schon in meiner ursprünglichen
Antwort beschrieben, gehe ich von einem Firmennetz aus, in dem mind. ein
Linux-Rechner steht, der die Datenbank bei sich "spiegelt", d.h. den
SSH-Tunnel aufbaut und über offenen PostgreSQL-Port den anderen Rechnern
im Netz zur Verfügung geht.

Aus dem Zusammenhang gerissen ist meine Empfehlung natürlich unsinnig.
Wenn jede Client-Anwendung auf ihrem eigenen Windows-Rechner ihr eigenes
SSH-Tunneling machen soll, dürfte das SSH nicht einfach blind im
Hintergrund liegen.

Außerdem müsste das SSH-Kommando auch anders aussehen, da mein Kommando
den Port 5432 nach außen freigibt. Stattdessen dürfte der Port nur lokal
erreichbar sein:

    ssh -L localhost:5432:localhost:5432 ...

oder kürzer:

    ssh -L 5432:localhost:5432 ...

> Normalerweise ist SSH auch so schlau, offene Verbindungen über forwards
> nicht zu schliessen, wenn die interaktive Session geschlossen wird (kann
> gut oder schlecht sein, wie mans sieht :)).

Auch das hatte ich in meiner ursprünglichen Antwort bereits erklärt.

> VPNs hingegen (IPSec) baut ja ggf. den Tunnel neu auf etc,

Unter Windows: Ja. Zumal man dort u.U. schon mit Boardmitteln auskommt.
Das ist natürlich da zu bevorzugen.

> > >     * In die .ssh/authorized_keys eintragen:
> > >             command="sleep 365000d" Public-Key-von-psql.vlan
> > 
> > Dankeschoen Euch beiden. sleep.. haette ich auch drauf kommen
> > koennen..  vielleicht ein bisschen zu wenig davon bekommen in den
> > letzten Wochen..
> 
> mmm... Warum sleep? Hätte eher ein "cat" oder "wc" vorgeschlagen

Wenn ich SSH im Vordergrund laufen lasse, dann ja. Das ist billig. Dann
tut's aber auch eine Shell oder *irgendwas*.

Willst du hingegen SSH im Hintergrund haben, *ohne* irgendwelche
Kommunikation, so nimmst du sicherheitshalber die Option -f oder
zumindest -n. Das stellt sicher, dass SSH keinerlei Eingabe entgegen
nimmt. Auf Server-Seite jedoch wirkt es wie ein geschlossenes stdin
(was es genaugenommen ja auch ist). Daher beenden sich Tools wie bash,
cat, wc, ... sofort.

Du brauchst also ein Tool, das auch dann weiter läuft, wenn die
Standardeingabe zuende ist. Und da sind mir nur "sleep" und "tail -f"
eingefallen.

> (kann
> man mit EOF beenden und macht input queue leer, damit nix blockt - aber
> vermutlich ist SSH eh schlau genug, dass portforwarding auch geht, wenn
> input queue voll ist).

Da ist doch klar. Darum geht es gar nicht. Es geht darum, dass du eben
*nicht* mit EOF beenden willst, sondern es noch weiter laufen soll, im
Hintergrund. Am besten über ein Script in /etc/init.d startbar.

Und da kannst du eben alles vergessen, das von stdin lesen will. Deshalb
darf SSH nicht von stdin lesen. Deshalb kriegen die Programme, die SSH
auf Serverseite aufruft, gleich ein EOF. Deshalb suchte ich Programme,
die trotz EOF weiterlaufen.

Ich hoffe, die Problematik ist nun klar geworden.


Viele Grüße,

    Volker, dessen Aussagen bitte nicht aus dem Zusammenhang
            gerissen werden. Danke.

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR