Adresse der CGI-Shell auf dem Server: www.example.com/somedir/cgi-shell-server.pl Lokal muss man sich den entsprechenden Client installieren, dazu verwende man das Paket binaervarianz.de/projekte/programmieren/cgi-shell/cgi-shell-0.17a-de.tar.gz . Neuere Versionen lassen sich auf Shared Hosting Webservern normalerweise nicht verwenden, da keine eigenen Client-Server-Anwendungen (mit eigenen Ports) zugelassen sind.

Zur Installation ist das Perl-Modul TermReadKey-2.2.1 notwendig. Download unter search.cpan.org/~jstowe/TermReadKey/ . Compilieren und installieren nach beiliegendem README. Die Passwortsicherung geschieht mit einer .htaccess-Datei im Verzeichnis von cgi-shell-server.pl. Diese kann von cgi-shell selbst generiert werden, siehe dazu die Optionen.

Kennt man den notwendigen Login nicht, so benenne man die .htaccess-Datei um und lasse von cgi-shell eine neue generieren mit wählbarem Benutzernamen und Passwort durch:

cgi-shell -c <your-url-to-cgi-shell>

Danach die beiden lokal erzeugten Dateien .htaccess und .htusers hochladen in das Verzeichnis, in dem auch cgi-shell-server.pl liegt.

Ein Fehler in der verwendeten Version cgi-shell 1.17a ist, dass $HOME nicht gesetzt ist und damit das Startverzeichnis “~” nicht ausgewertet werden kann. Auch Wechseln in ein beliebiges Verzeichnis außer / ist dann nicht möglich. Umgehung:

cd /;
cd /path-to-web-root/;

How to reproduce this error: Use phpgroupware 0.9.16.000, her with PHP 4.2.3; register_globals = on for all apps except notes, projects, qmailldap, stocks, todo.

1. Install phpGroupWare correctly, including the apps
2. Point your browser to /setup below your phpGroupware Installation URL
3. Choose “Click here to setup an admin account and (optionally) 3 demo accounts.*” Then only setup the admin account. This is how to recover from the phpgw crash (step 6), too.
4. Login as admin user into phpgw and choose “Preferences > Change Your Settings > Your Preferences”. Or, choose “… > Default Preferences > Your Preferences”.
5. Choose these Options and then “Save”: Language: German and Show number of current users: Yes
6. Now, phpGroupWare outputs approx some 100 kB of error messages. This is reproducible for me. See below for the kind of error messages I get, all the time jumping between lines 208, 209, 210 in the specified script.
7. Workaround: use a Forced Preference for language or number of current user information that prohibits the above mentioned combination of settings to be done by your users.

Here are the error messages that are generated:

Warning: fopen("/tmp/sess_66bb6b04ba1ddd84eec30c9665360181", "r") - Permission denied in /homepages/24/d70284365/htdocs/www.ansorgs.de/groups.ansorgs.de/phpgwapi/inc/class.sessions_php4.inc.php on line 208
Warning: fread(): supplied argument is not a valid File-Handle resource in /homepages/24/d70284365/htdocs/www.ansorgs.de/groups.ansorgs.de/phpgwapi/inc/class.sessions_php4.inc.php on line 209
Warning: fclose(): supplied argument is not a valid File-Handle resource in /homepages/24/d70284365/htdocs/www.ansorgs.de/groups.ansorgs.de/phpgwapi/inc/class.sessions_php4.inc.php on line 210
Warning: fopen("/tmp/sess_e46ac33657b1d69993c7fc104a9cf71a", "r") - Permission denied in /homepages/24/d70284365/htdocs/www.ansorgs.de/groups.ansorgs.de/phpgwapi/inc/class.sessions_php4.inc.php on line 208
Warning: fread(): supplied argument is not a valid File-Handle resource in /homepages/24/d70284365/htdocs/www.ansorgs.de/groups.ansorgs.de/phpgwapi/inc/class.sessions_php4.inc.php on line 209
Warning: fclose(): supplied argument is not a valid File-Handle resource in /homepages/24/d70284365/htdocs/www.ansorgs.de/groups.ansorgs.de/phpgwapi/inc/class.sessions_php4.inc.php on line 2101.
Install phpGroupWare correctly, including the apps

And now, something about the same error when installing.

Problematisch ist: in der Konfiguration von PHP4 (php.ini an unbekanntem Ort) steht session.save_path = /tmp . Das gilt für alle User. Der Webserver läuft aus der Sicht jedes Users unter seinem eigenen Benutzernamen, etwa p3002017. Es ist nun möglich, dass phpGroupWare-Installationen verschiedener Benutzer in /tmp Session-Dateien mit gleichem Namen anlegen, also einander überschreiben. Sie beginnen mit sess_ und haben danach eine lange hexadezimale Zeichenkette. Wenn dies ein Hashwert ist, könnte es das Überschreiben erklären. Somit werden Session-Dateien also ungültig. Erkennbar ist das daran, dass sie für den eigenen Benutzer nicht mehr lesbar ist und phpGroupWare etwa folgende Meldungen ausgibt:

Warning: fopen("/tmp/sess_dc4886a4eec5f", "r") - Permission denied
in /somepath/phpgwapi/inc/class.sessions_php4.inc.php
on line 208

Diese Problemanalyse wird dadurch bestätigt, dass die Fehlermeldungen in phpGroupWare verschwinden, wenn man einen neuen Benutzer anlegt und sich als solcher einloggt: klar, denn es wurden neue Session-Dateien angelegt statt dass alte gesucht wurden, und es ist sehr unwahrscheinlich, dass die neuen Dateien bereits von anderen phpGroupWare-Installationen überschrieben wurden. Das Prefix sess_ wird von phpGroupWare generiert, so dass nur phpGroupWare-Installationen miteinander im Konflikt stehen. Das Problem tritt selten auf, wenn die Server wenig genutzt werden, z.B. nachts. Es ist möglich, dieses Problem durch eine eigene php.ini zu beheben. Man lege sie ins Webserver-Rootverzeichnis der Domain oder Subdomain. Sie enthalte den vollständigen Pfad zum persönlichen tmp-Verzeichnis (mit entspr. Zugriffsrechten). Beispielinhalt:

session.save_path = /somepath/mytmpdir

Das Problem wird nicht gelöst, indem man Einstellungen in »Admin :: Site configuration :: Use cookies to pass sessionid:« und »Admin :: Site configuration :: check ip address of all sessions:« macht.

Eine weitere Möglichkeit sind evtl. Einstellungen in der .htaccess wie beschrieben in phpGroupware Mailingliste, 2003-09, Nachricht 241.

Dort steht auch ein möglicher Grund des Folgeproblems »Your session could not be verified.«: Cookies werden neben phpGroupWare noch von sitemgr verwaltet und abgelegt in /tmp wie bisher. Das muss noch umgestellt werden.

Tatsächlich wird auch nach Umstellung des /tmp-Verzeichnisses sowohl dort als auch am neuen Ort eine sess_-Datei zur aktuellen Session angelegt. Die session-ID der aktuellen Session kann man im Source-Code der HTML-Seite nach dem Einloggen nachlesen.

Aber: das Problem mit nicht lesbaren sess_*-Dateien tritt nur auf (dann aber für alle Benutzer) wenn man als Admin die Default-Preferences (oder einen bestimmten Teil davon) ändert. Und zwar tritt es dann unabhängig von der Serverbenutzung auf. Bisher hilft dann nur, im Setup-Bereich alle Benutzer zu löschen und einen neuen Admin-Benutzer anzulegen. Löschen der Cookies hilft nur, um zum Login-Screen zu gelangen wenn man nur den Domain-Namen eingibt.

Dies ist z.B. praktisch, um auf effiziente Art einen Upload seiner persönlichen Homepage durchzuführen (wenn diese auch statischen HTML-Inhalten besteht die man lokal editiert).

Lösung: man verwendet das folgende Kommando:

find . -newer .lastupload \
  -path './path-to-local-website-copy/*' | \
  xargs -i \
  ncftpput -u username -p password -R example.com \
  /path-on-ftp-server {} \
  && touch .lastupload

Dabei bedeuten:

• -path './path-to-local-website-copy/*': Pfade, in dem die Dateien auf dem lokalen System liegen dürfen.
• -newer .lastupload .lastupload ist der Name einer Datei, deren Modifikationszeit die Zeit des letzten Uploads ist. Alle neueren Dateien sind also jetzt upzuloaden.

Um nur einige wenige Dateien per Hand hochzuladen (wobei lokalen Dateien / Verzeichnisse ohne Wildcards angegeben werden können):

ncftpput -u username -p password -R example.com \
  /path-on-ftp-server localfiles-1* localfiles-2*

Symptome: Wenn man versuche, in Netscape eine mit wwwoffle gespeicherte Seite aufzurufen, die ein cgi-Script mit Parametern ist, während man offline ist, so sagt wwwoffle, dass diese Seite zum Download vorgemerkt sei (obwohl das Anzeigen dieser Seiten mit konqueror möglich ist). Dies ist ebenfalls der Fall, wenn in der gewählten Seite eine zu ladende Referenz mit Parametern vorkommt (z.B. zu AudioMedien). Anschließend kann in Netscape keine einzige Seite mehr eingeladen werden, weder aus dem Internet noch vom lokalen System. Der Neustart von Netscape ist unmöglich: es wird keine Fehlermeldung angezeigt, es erscheint kein Fenster.

Workaround: nach dem Neustart von X kann Netscape zumindest wieder gestartet werden. Eine vollständige Problemlösung steht noch aus.

Die grundsätzliche Anleitung steht in openvpn.net/howto.html . Hier eine Anleitung für eine komfortable, stabile Konfiguration:

1. OpenVPN unter Windows auf Server und Clients installieren.
2. »Start -> Ausführen … -> “cmd”«
3. 1. cd c:\Programme\OpenVPN\easy-rsa\, init-config.bat

   ausführen.

4. vars.bat editieren mit dem Befehl
   1. edit vars.bat

   (in notepad Probleme mit Zeilenendezeichen!)

5. Firewall-Einstellungen, Erweitert, für TAP-Netzwerkgerät deaktiviern
6. Port-Forwarding beim Router einstellen
7. openvpn unter Linux als root / mit sudo starten; sonst gibt es Zugriffsprobleme mit dem Device
   /dev/net/tun, und, wenn man diese manuell korrigiert hat, evtl. die Fehlermeldung »Cannot allocate TUN/TAP dev dynamically«.
8. Auf Windows-Clients und Windows-Servern: OpenVPN GUI von openvpn.se/ installieren nach der Anleitung in openvpn.se/install.txt .
9. Als GUI für OpenVPN unter Linux verwenden: kvpnc oder kovpn.

Man verwende das Linux-Programm rdesktop und das GNOME-Frontend grdesktop (unterstützt nativ das RDP-Protokoll der Windows XP Remoteunterstützung). Einrichtung:

1. Unter »Systemsteuerung -> System -> Remote -> Remotedesktop« aktivieren: »Benutzern erlauben, eine Remotedesktopverbindung herzustellen.«. Remoteunterstützung zu aktivieren reicht hier nicht.
2. Auf dem Windows-Rechner muss TCP-Port 3389 für eingehende Verbindungen geöffnet werden. Das erfordert ggf. eine Umkonfiguration des Routers und der Windows Firewall (wenn eingeschaltet; siehe Windows Sicherheitscenter). Achtung: »Remotedesktop« und »Remoteunterstützung« sind in der Windows Firewall zwei verschiedene Punkte die beide als »Ausnahmen« eingerichtet sein müssen! Man kann die Windows Firewall auch zeitweise ausschalten um sicherzustellen dass sie nicht die Ursache eines Problems ist.
3. SeamlessRDP ( www.cendio.com/seamlessrdp/ ) wird nicht benötigt, es dient lediglich dazu Fenster einzeln zu erhalten statt den gesamten Desktop. (Was übrigens eine nette Idee zum Interfacing mit einer lokal laufenden virtuellen Maschine ist; siehe howtoforums.net/viewtopic.php?t=5 ). Achtung hierbei: ubuntuforums.org/showpost.php?p=1362687&postcount=35
4. Remote Desktop Verbindungen sind möglich zu Windows XP Rechnern (evtl. wird Windows XP Professional benötigt weil nur dort die notwendige Terminal Server Funktionalität implementiert ist). Jedoch kann RDP nur verwendet werden wenn kein (!) lokaler Benutzer auf der Maschine eingeloggt ist. Genauer: durch ein RDP-Login wird das Login eines lokalen Benutzers automatisch beendet. Es ist nicht einmal möglich, eine VNC- und eine Remote Desktop Sitzung gleichzeitig zu verwenden: startet man eine Remote Desktop Sitzung, werden alle anderen Benutzer ausgeloggt, inkl. dem Benutzer dessen Sitzung man über VNC sah. Deshalb endet die VNC-Sitzung dann. Um diese Beschränkung zu entfernen folge man der Anleitung auf sig9.com/articles/concurrent-remote-desktop .
   Achtung: im vorliegenden Fall funktionierte diese Anleitung nicht. Das System war Microsoft Windows XP Professional, Version 2002, Service Pack 2 (5.1, Build 2600). Resultat: direkt nach dem Hochfahren trat folgende Feglermeldung auf: »Generic Host Process hat ein Problem festgestellt und muss beendet werden«, danach automatisches Herunterfahren, ausgelöst von »NT-AUTORITÄT\SYSTEM«, Meldung »Windows muss heruntergefahren werden da der Dienst DCOM-Server-Prozessstart unerwartet beendet wure«.
   In den »Details« folgende Problemsignatur: szAppName: svchost.exe, szModName: termsrv.dll, szModVer:
   5.1.2600.2055. Vermutlich ein Kompatibilitätsproblem mit der »neuen« termsrv.dll das von irgendeiner Art Dateiüberwachungssystem erkannt wird. Das Problem tritt reproduzierbar bei jedem Systemstart auf. Es wird behoben indem man die gesichterte, originale termsrv.dll wieder zurück kopiert.
   Damit o.a. Anleitung (in anderen Fällen) funktioniert: zusätzlich muss man mehrere Benutzer auf dem System erstellt haben damit diese Anleitung funktioniert: »I have concurrent sessions working. Just be sure to have three different users on your Windows XP install – then you can run one remote session for each of them, up to a total of three at a time.« ( ubuntuforums.org/showpost.php?p=1868887&postcount=40 ).
5. Für den Benutzer mit dem man sich per Remote Desktop anmelden will darf kein leeres Kennwort eingestellt sein; siehe support.microsoft.com/kb/303846/de . Man erhält sonst per Remote Desktop zwar einen Login-Screen, aber beim versuchten Login die Meldung »Wegen einer Kontenbeschränkung dürfen Sie sich nicht anmelden.«
6. Kommando etwa:
   1. rdesktop -u User -p – -k de -x l 192.168.0.2

   Als Protokoll zur Kommunikation mit Windows XP Rechnern muss RDP RDP V5 verwendet werden; das geschieht durch o.a. Kommando standardmäßig. Ein optimiertes Kommando mit Kompression, Bitmap-Caching, Redirection des Server-Sounds und einer Größe die genau in den KDE-Desktop passt ist etwa folgendes. (Achtung: es sollte mind. 300-400 kbps Upload-Bandbreite zur Verfügung stehen damit Sound-Redirection flüssig funktioniert.)

   1. rdesktop -u <username> -p <password> -k de -P -z -x b -g 1016×710 -r sound:local 192.168.0.2

   Zumindest manche Video-Anzeigebereiche überlasten dabei die Verbindung so dass kein sinnvolles Arbeiten mehr möglich ist. Dann hilft ggf. »-a 8« (Einstellung von 256 Farben) denn dabei wird Video überhaupt nicht mehr
   übertragen.

7. Man kann auch eine GUI zu rdesktop verwenden: grdesktop, tsclient oder krdc. Windows XP enthält bereits einen Remote Desktop Client: »Start -> Programme -> Zubehör -> Kommunikation -> Remotedesktopverbindung«.

Alternativen sind:

• VNC (z.B. der freie Server von RealVNC)
• Citrix ICA (kommerziell; benötigt Software auf dem Windows-Rechner; kostenlose Ausgabe vorhanden)
• Tarantella (kommerziell)
• FreenNX (leider gibt es noch keinen NX Server für Windows; 2007-12-12)
• DameWare (nur unter einer virtuellen Maschine nutzbar)

»Generell kann man sagen, das freeNX so etwas ähnliches wie VNC ist, nur um einiges schneller! In etwa so, wie die Remotedesktopverbindung {de} von Windows oder Citrix Presentation Server {de} . Außerdem verursacht FreeNX auf dem Server wesentlich weniger CPU-Last als VNC.« (nach wiki.ubuntuusers.de/FreeNX ). Einen guten Überblick gibt der Artikel www.pro-linux.de/berichte/lt2004-nxartikel.html .

Das Problem ist dass es bisher keinen NX Server für Windows gibt. Denn NX basiert auf dem X Protokoll, das von Windows nicht verwendet wird. Man kann jedoch einen Linux-basierten NX Server als Gateway verwenden: www.nomachine.com/ar/view.php?ar_id=AR02D00349 .
Alternativ kann man versuchen, das Windows-eigene Remote Desktop Protocol (RDP) zu nutzen
(Anwendungen rdesktop, grdesktop, krdc).

Installation und Konfiguration: wird gut beschrieben unter

de.opensuse.org/FreeNX_Server_HOWTO

wiki.ubuntuusers.de/FreeNX

Download der Software (u.a. als Debian-Pakete) unter:

www.nomachine.com/download.php

1. VNC Server Free Edition 4.1 for Windows herunterladen von www.realvnc.com/products/download.html .
2. VNC Server installieren und dabei als Systemdienst starten lassen.
3. In Windows Firewall und der Firewall des Routers Ports TCP 5800 und TCP 5900 öffnen.
4. xvnc4viewer unter Linux installieren und eingeben:
   1. xvnc4viewer -LowColourLevel 2 192.168.1.3

   Optionen erhält man durch zweimaliges Drücken von F8. Für eine DSL 2000 Verbindung (300 kBit/s Upload) ergibt Fullscreen und 256 Farben eine angemessene Geschwindigkeit. Alternativ kann unter Linux auch krdc als Programm mit GUI verwendet werden.

5. Wenn außerdem ein VNC Client unter Windows verwendet werden soll: man verwende den von www.realvnc.com/products/download.html .

Man verwende nxserver (oder dessen aufgebohrte kommerzielle Variante). Im Gegensatz zu normalem X Forwarding
(EXPORT DISPLAY=…) ist es durch Kompression des X Protokolls wesentlich (!) schneller und damit für normales Arbeiten zu gebrauchen.