summaryrefslogtreecommitdiffstats
path: root/doc/LaTeX/devel/0500-pvs-client.tex
diff options
context:
space:
mode:
Diffstat (limited to 'doc/LaTeX/devel/0500-pvs-client.tex')
-rw-r--r--doc/LaTeX/devel/0500-pvs-client.tex30
1 files changed, 21 insertions, 9 deletions
diff --git a/doc/LaTeX/devel/0500-pvs-client.tex b/doc/LaTeX/devel/0500-pvs-client.tex
index 9c0b572..bbca766 100644
--- a/doc/LaTeX/devel/0500-pvs-client.tex
+++ b/doc/LaTeX/devel/0500-pvs-client.tex
@@ -113,21 +113,23 @@ Es gibt zwei Arten von VNC Servern. Server, die eine laufende Sitzung bzw. ein v
Motivation für den eigentlichen Vergleich ist die Integration mancher VNC Server in die Desktopumgebung. Hier müsste der x11vnc nicht extra installiert werden. Wichtig für den Einsatz im PVS ist vor allem die Unterstützung von Shared Modus, d.h. mehrere VNC Viewer können sich gleichzeitig mit dem VNC Server verbinden, und Forever Modus, d.h. der VNC Server wird nicht nach Trennung des letzten Clients beendet. Sicherheitsoptionen wie die Vergabe von Passwörtern und die Unterscheidung von RW und Viewonly Modus sind ebenso nicht zu vernachlässigen.
\paragraph{Vino}
+\begin{sloppypar}
~\\
Vino ist der VNC Server der Gnome Desktopumgebung.
Er wird standardmäßig über die graphische Oberfläche \textbf{vino-preferences} konfiguriert. Über die Kommandozeile ist Vino entweder über \textbf{gconftool-2} oder über direktes editieren der Datei \\
\textit{\~{}/.gconf/desktop/gnome/remote\_access/\%gconf.xml} konfigurierbar.
Parameter können nicht übergeben werden, was die Verwendbarkeit im PVS einschränkt.
-Vino benutzt standardmäßig den Port 5900, um auf eingehende Verbindungen zu warten. Dieser Port kann nur durch \\
-\small \texttt{gconftool-2 -s -t int /desktop/gnome/remote\_access/alternative\_port <portnumber>} bzw. das Einfügen von z.B. \\
-\small \verb|<entry name="alternative_port" mtime="1259858032" type="int" value="<portnumber>"/>|
-in die entsprechende \%gconf.xml Datei geändert werden. Hierbei ist zu beachten, dass nicht überprüft wird, ob der entsprechende Port schon belegt ist. Dementsprechend wird auch kein anderer freier Port gewählt. %TODO Formulierung.
+Vino benutzt standardmäßig den Port 5900, um auf eingehende Verbindungen zu warten. Dieser Port kann nur durch
+\texttt{gconftool-2 -s -t int \/desktop/gnome/remote\_access/alternative\_port <portnumber>} bzw. das Einfügen von z.B.
+\texttt{<entry name=``alternative\_port'' mtime=``1259858032'' type= ``int'' value=``<portnumber>''/>}
+in die entsprechende \%gconf.xml Datei geändert werden. Hierbei ist zu beachten, dass nicht überprüft wird, ob der entsprechende Port schon belegt ist. Dementsprechend wird auch kein anderer freier Port gewählt.
Außerdem wird eine Änderung des Ports erst nach dem Neustart der grafischen Oberfläche aktiv.
Vino unterstützt die Vergabe eines Passworts, welches base64 kodiert in der gconf Datei abgelegt wird. Ebenso kann man den Zugriff auf den Viewonly Modus beschränken. Unterschiedliche Passwörter für den RW Modus und den Viewonly Modus können jedoch nicht vergeben werden. Der Shared und Forever Modus sind standardmäßig aktiv.
+\end{sloppypar}
\paragraph{Krfb}
~\\
-Krfb ist das Pendant zu Vino der KDE Desktopumgebung und kann entweder über eine Konfigurationsdatei oder über die grafische Oberfläche konfiguriert werden. Es kann entweder das Einladungssystem verwendet werden, bei dem eine Einladung mit einem Einmalpasswort generiert wird, oder man erlaubt uneingeladene Verbindungen und vergibt ein eigenes Passwort. Um Krfb über eine Konfigurationsdatei mit einem selbstgewählten Passwort für uneingeladene Verbindungen zu konfigurieren, erstellt man die Datei wie in \ref{pvs-client-krfbconfig} angegeben und übergibt sie an krfb mit \texttt{krfb --config <Pfad> } bzw überschreibt oder bearbeitet die eigentliche Konfigurationsdatei in \textit{~/.kde/share/config/krfbrc}.
+Krfb ist das Pendant zu Vino der KDE Desktopumgebung und kann entweder über eine Konfigurationsdatei oder über die grafische Oberfläche konfiguriert werden. Es kann entweder das Einladungssystem verwendet werden, bei dem eine Einladung mit einem Einmalpasswort generiert wird, oder man erlaubt uneingeladene Verbindungen und vergibt ein eigenes Passwort. Um Krfb über eine Konfigurationsdatei mit einem selbstgewählten Passwort für uneingeladene Verbindungen zu konfigurieren, erstellt man die Datei wie im folgenden angegeben und übergibt sie an krfb mit \texttt{krfb --config <Pfad> } bzw überschreibt oder bearbeitet die eigentliche Konfigurationsdatei in \textit{~/.kde/share/config/krfbrc}.
%\label{pvs-client-krfbconfig}
\begin{verbatim}
[Security]
@@ -190,8 +192,11 @@ Um einen Mehrfachstart des VNC Servers zu verhindern, wird zunächst immer ein \
Der VNC Viewer ist, wie in der \ref{pvsclient-datenstrom} Darstellung von VNC-Datenströmen beschrieben, implementiert.
Die direkte Integration des Viewers im Gegensatz zum Einsatz eines externen VNC Servers bietet sich hier wegen der Integrationsmöglichkeiten in die GUI an (der VNC-Server ist GUI unabhängig). Jedoch muss der VNC-Viewer zur Unterstützung des RW-Modus des VNC-Servers noch verändert werden.
\subsection{Tastatur und Maussteuerung}
-Um die Maus- und Tastatureingaben an den VNC-Server weiterzuleiten, müssen zunächst die Eingaben in der Klasse \texttt{ClientVNCViewer} abgefangen und verarbeitet werden. Dies kann durch Überschreiben der geerbten Methode \texttt{event} erreicht werden \verb|bool ClientVNCViewer::event(QEvent *event)|. Hier kann durch \verb|event->type()| der Typ des Events herausgefunden werden.
+\label{pvsclient-remotehelp}
+\begin{sloppypar}
+Um die Maus- und Tastatureingaben an den VNC-Server weiterzuleiten, müssen zunächst die Eingaben in der Klasse \texttt{ClientVNCViewer} abgefangen und verarbeitet werden. Dies kann durch Überschreiben der geerbten Methode \texttt{event} erreicht werden \texttt{bool ClientVNCViewer::event(QEvent *event)}. Hier kann durch \texttt{event->type()} der Typ des Events herausgefunden werden.
Zu behandelnde Eventtypen sind:
+\end{sloppypar}
\begin{itemize}
\item QEvent:KeyPress - Eine Taste wurde gedrückt
@@ -215,17 +220,24 @@ Werte sind dabei:
\item 0xfd = mittlere Maustaste losgelassen
\item 0xfb = rechte Maustaste losgelassen
\end{itemize}
-\texttt{KeyEvents} bestehen aus einem hexadezimalen Wert, der die Taste repräsentiert, und True oder False je nachdem, ob die Taste gedrückt wurde oder nicht. Die hexadezimalen Werte entsprechen den Werten in einem X Window System und können in der Headerdatei \texttt{<X11/keysymdef.h>} nachgeschlagen werden (siehe hierzu auch \url{http://www.realvnc.com/docs/rfbproto.pdf} - RFB Protokollspezifikation, Abschnitt KeyEvent). Beim Leeren der Queue werden die Methoden der rfbclient Klasse der libvnc Bibliothek \verb|SendPointerEvent(cl, _x, _y, _buttonMask)| und \verb|SendKeyEvent(cl, _key, _pressed)| mit den entsprechenden Werten aufgerufen (cl entspricht dabei einem Pointer auf die eigentliche rfbClient Instanz).
+\begin{sloppypar}
+\texttt{KeyEvents} bestehen aus einem hexadezimalen Wert, der die Taste repräsentiert, und True oder False je nachdem, ob die Taste gedrückt wurde oder nicht. Die hexadezimalen Werte entsprechen den Werten in einem X Window System und können in der Headerdatei \texttt{<X11/keysymdef.h>} nachgeschlagen werden (siehe hierzu auch \url{http://www.realvnc.com/docs/rfbproto.pdf} - RFB Protokollspezifikation, Abschnitt KeyEvent). Beim Leeren der Queue werden die Methoden der rfbclient Klasse der libvnc Bibliothek \texttt{SendPointerEvent(cl, \_x, \_y, \_buttonMask)} und \texttt{SendKeyEvent(cl, \_key, \_pressed)} mit den entsprechenden Werten aufgerufen (cl entspricht dabei einem Pointer auf die eigentliche rfbClient Instanz).
+\end{sloppypar}
\section{Signalbehandlung}
+\begin{sloppypar}
Um zu gewährleisten, dass bei einer Terminierung des PVS-Clients auch der gegebenenfalls gestartete VNC-Server gestoppt wird, werden Sigterm, Sighup, Sigquit und Sigint Signale abgefangen und weiterbehandelt.
Um die Signale behandeln zu können, muss die C Bibliothek \texttt{signals.h} eingebunden werden und ein sigaction Objekt erstellt werden. Das Feld sa\_handler des sigaction Objektes gibt dabei die aufzurufende Funktion an (Pointer auf die Funktion). Diese Funktion (in der Klasse \texttt{pvs} die Funktion \texttt{signalHandler}) muss dabei vom Typ void sein und die Signalnummer als Parameter erwarten (\texttt{void PVS::signalHandler(int signal)}).
+\end{sloppypar}
+
\begin{verbatim}
struct sigaction act;
act.sa_handler = &PVS::signalHandler;
\end{verbatim}
-Um Signale abfangen zu können, muss nun noch das sigaction Objekt durch \verb|sigaction(SIGTERM, &act, 0)| mit den entsprechenden Signalen (hier SIGTERM) verknüpft werden (muss für alle zu behandelnde Signale durchgeführt werden).
+\begin{sloppypar}
+Um Signale abfangen zu können, muss nun noch das sigaction Objekt durch \texttt{sigaction(SIGTERM, \&act, 0)} mit den entsprechenden Signalen (hier SIGTERM) verknüpft werden (muss für alle zu behandelnde Signale durchgeführt werden).
Danach wird, sobald ein entsprechendes Signal erhalten wird, die Funktion aufgerufen und die Signalnummer übergeben.
-Für alle Signale kann die gleiche Funktion aufgerufen werden, hier kann die Unterscheidung dann mittels der in \texttt{signal.h} vorhandenen Konstanten SIGHUP, SIGTERM, SIGQUIT usw. erfolgen. Zu beachten ist hierbei, dass ein SIGKILL nicht abgefangen werden kann. \ No newline at end of file
+Für alle Signale kann die gleiche Funktion aufgerufen werden, hier kann die Unterscheidung dann mittels der in \texttt{signal.h} vorhandenen Konstanten SIGHUP, SIGTERM, SIGQUIT usw. erfolgen. Zu beachten ist hierbei, dass ein SIGKILL nicht abgefangen werden kann.
+\end{sloppypar} \ No newline at end of file