Hallo Liste! Da wir immer wieder Probleme mit einem NFS-Server haben und NFS allgemein die Unsicherheit in Person darstellt, suchen wir nach einer Alternative. Womit habt ihr Erfahrungen gemacht? Was könnt ihr empfehlen? Liefert SuSE so was mit? Gruß, Andreas
On Mon, 29 Oct 2001, Andreas Achtzehn wrote:
Da wir immer wieder Probleme mit einem NFS-Server haben und NFS allgemein die Unsicherheit in Person darstellt, suchen wir nach einer Alternative.
Welche Probleme? Und warum lassen sich diese nicht beheben=?
Womit habt ihr Erfahrungen gemacht? Was könnt ihr empfehlen?
Was willst Du denn genau machen? Datensicherung ueber's Netz beispielsweise? Habe ich lange auf rsync umgestellt. Was besseres kenne ich nicht. Oder was sonst? VPN ueber Internet? Gruss Peter Blancke -- Nachtwaechter ist der Wahnsinn, weil er wacht...
From: Peter Blancke [mailto:blancke@gmx.de]
On Mon, 29 Oct 2001, Andreas Achtzehn wrote:
Da wir immer wieder Probleme mit einem NFS-Server haben und NFS allgemein die Unsicherheit in Person darstellt, suchen wir nach einer Alternative.
Welche Probleme? Und warum lassen sich diese nicht beheben=? Wir hatten Probleme, als ein anderer Server nicht erreichbar war und die Verbindungen zwischen den Servern nicht getrennt werden konnte. Jedesmal, wenn man sich das Verzeichnis anschauen wollte, dauerte es fast eine Minute, bis eine "nicht erreichbar"-Meldung kam.
Zweite, wichtigere Sache: NFS ist UDP-basiert, daher ist es sehr leicht, es zu spoofen. Wir suchen da was besseres.
Womit habt ihr Erfahrungen gemacht? Was könnt ihr empfehlen?
Was willst Du denn genau machen?
Datensicherung ueber's Netz beispielsweise? Habe ich lange auf rsync umgestellt. Was besseres kenne ich nicht.
Nein, leider nicht. Wir müssen ein Verzeichnis für einen anderen Server freigeben, damit Daten ausgetauscht werden können. Die Workstations greifen auf das freigegebene Verzeichnis per Samba zu.
Oder was sonst? VPN ueber Internet? Wollte nicht gleich mit Kanonen auf Spatzen schießen. Nur endlich von NFS weg, da es zu viele Probleme macht, wenn ein Server mal nicht verfügbar ist.
Gruß, Andreas
Andreas Achtzehn schrieb:
From: Peter Blancke [mailto:blancke@gmx.de]
On Mon, 29 Oct 2001, Andreas Achtzehn wrote:
Da wir immer wieder Probleme mit einem NFS-Server haben und NFS allgemein die Unsicherheit in Person darstellt, suchen wir nach einer Alternative.
Welche Probleme? Und warum lassen sich diese nicht beheben=? Wir hatten Probleme, als ein anderer Server nicht erreichbar war und die Verbindungen zwischen den Servern nicht getrennt werden konnte. Jedesmal, wenn man sich das Verzeichnis anschauen wollte, dauerte es fast eine Minute, bis eine "nicht erreichbar"-Meldung kam.
<schuss ins blaue> 'dauerte fast eine Minute, bis eine "Nicht Erreichbar"- Meldung kam' riecht doch eigentlich immer nach Fehler bei der Namensauflösung... vorwärts wie rückwärts... Kann es das gewesen sein? -- Grüße, Bert
From: Bert Blümer [mailto:bert@bluemer.de]
Andreas Achtzehn schrieb:
From: Peter Blancke [mailto:blancke@gmx.de]
On Mon, 29 Oct 2001, Andreas Achtzehn wrote:
Da wir immer wieder Probleme mit einem NFS-Server haben und NFS allgemein die Unsicherheit in Person darstellt, suchen wir nach einer Alternative.
Welche Probleme? Und warum lassen sich diese nicht beheben=? Wir hatten Probleme, als ein anderer Server nicht erreichbar war und die Verbindungen zwischen den Servern nicht getrennt werden konnte. Jedesmal, wenn man sich das Verzeichnis anschauen wollte, dauerte es fast eine Minute, bis eine "nicht erreichbar"-Meldung kam.
<schuss ins blaue>
'dauerte fast eine Minute, bis eine "Nicht Erreichbar"- Meldung kam' riecht doch eigentlich immer nach Fehler bei der Namensauflösung... vorwärts wie rückwärts...
Kann es das gewesen sein?
Eigentlich nicht. Die Namensauflösung funktioniert vorwärts wie rückwärts. NFS basiert auf UDP, daher macht es ja keinen klassischen Handshake. Es schießt einfach wahllos die Anfragen durch die Leitungen, wenn nichts zurückkommt, versucht es das wohl nochmal, dann gibt es irgendwann auf. Eine klare Unterlegenheit des Protokolls.
Andreas Achtzehn wrote:
rückwärts. NFS basiert auf UDP, daher macht es ja keinen klassischen Handshake. Es schießt einfach wahllos die Anfragen durch die Leitungen, wenn nichts zurückkommt, versucht es das wohl nochmal, dann gibt es irgendwann auf. Eine klare Unterlegenheit des Protokolls.
Ich weiß ja nicht, ob das ein Unterlegenheit darstellt. Das wäre es erst, wenn es ein alternatives TCP-basiertes Protokoll gäbe, das ähnlich Dienste bei gleicher Geschwindigkeit anbietet. Wir wollen ja schließlich nicht immer einen Kaffee trinken gehen, wenn wir ein cp -R machen... - Matthias
From: Matthias Kleine [mailto:mkleine@prs.de] On Behalf Of Andreas Achtzehn wrote:
rückwärts. NFS basiert auf UDP, daher macht es ja keinen klassischen Handshake. Es schießt einfach wahllos die Anfragen durch die Leitungen, wenn nichts zurückkommt, versucht es das wohl nochmal, dann gibt es irgendwann auf. Eine klare Unterlegenheit des Protokolls.
Ich weiß ja nicht, ob das ein Unterlegenheit darstellt. Das wäre es erst, wenn es ein alternatives TCP-basiertes Protokoll gäbe, das ähnlich Dienste bei gleicher Geschwindigkeit anbietet. Wir wollen ja schließlich nicht immer einen Kaffee trinken gehen, wenn wir ein cp -R machen...
Ok, Performance ist eine Sache, IP-Spoofing eine andere. UDP ist für meinen Geschmack zu unsicher, es ist halt nur schnell. Es gäbe natürlich alternative Arten der Implementation (z.B. persistente TCP-Verbindungen, nicht 1x Verbindung pro Datei). Ich versuche jetzt, mangels Alternative, den NFS wenigstens ein wenig stabiler/toleranter zu machen. Was ist dabei eigentlich der Unterschied zwischen kernel-based und user-NFS? Was ist zu bevorzugen? Gruß, Andreas
Am Dienstag, 30. Oktober 2001 15:36 schrieb Andreas Achtzehn:
Ok, Performance ist eine Sache, IP-Spoofing eine andere. UDP ist für meinen Geschmack zu unsicher, es ist halt nur schnell. Es gäbe natürlich
Na das spielt ja wohl nur eine Rolle, wenn Du den "Feind in Deinem Bett" erwartest, d.h. in der eigenen Firma. Vor außen solltest Du Dich mit einer Firewall schützen, denn wenn jemand in Euer Netz kommt, nützt Dir auch ein TCP-basiertes Netzwerk-Filesystem nichts. Das ist für diesen Fall der falsche Ansatz. Wenn Du Grund hast, den Kollegen zu mißtrauen (was ja insbesondere bei größeren Netzwerken gerechtfertigt sein kann), hast Du denn alle anderen Sicherheitsmechanismen bereits ausgereizt? Nur so viel: Bevor Du Dich um die Abwehr von Spoofing kümmerst, sind mindestens ein paar Dutzend andere Sicherheitsmaßnahmen sicherlich wichtiger... - Matthias -- LPI Level 1 Certified http://www.selflinux.de
Matthias Kleine wrote:
Andreas Achtzehn wrote:
rückwärts. NFS basiert auf UDP, daher macht es ja keinen klassischen Handshake. Es schießt einfach wahllos die Anfragen durch die Leitungen, wenn nichts zurückkommt, versucht es das wohl nochmal, dann gibt es irgendwann auf. Eine klare Unterlegenheit des Protokolls.
Ich weiß ja nicht, ob das ein Unterlegenheit darstellt. Das wäre es erst, wenn es ein alternatives TCP-basiertes Protokoll gäbe, das ähnlich Dienste bei gleicher Geschwindigkeit anbietet. Wir wollen ja schließlich nicht immer einen Kaffee trinken gehen, wenn wir ein cp -R machen...
NFS ist inzwischen nicht mehr auf UDP beschränkt, sondern kann auch über TCP betrieben werden. Aber auch bei TCP wird man Timeouts abwarten müssen, um festzustellen, daß die Gegenstelle nicht mehr reagiert. Das Hauptproblem: Normalerweise will man in einem Unix-System nicht, daß ein Dateisystem einfach so verschwindet, denn das kann einige Probleme (Datenverluste, abstürzende Programme, ...) bringen. Daher ist es oft (nicht immer, mich hat's auch schon häufig genervt) durchaus gewünscht, daß alle NFS-Zugriffe blockieren, wenn der Server gerade nicht reagiert. So kann man nach Behebung der Störung sauber weiterarbeiten, auch wenn der Server vielleicht einige Minuten für einen Reboot gebraucht hat. Um dieses Verhalten zu beeinflussen gibt es für NFS die mount-Optionen hard, soft und timeo, die in `man mount` im Abschnitt "Mount options for nfs" beschrieben sind. Dort wird auch noch einmal auf die Probleme hingewiesen. Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert@informatik.uni-bremen.de - eilert@tzi.org http://www.informatik.uni-bremen.de/~eilert/
Am 30-Oct-2001 Eilert Brinkmann schrieb:
Matthias Kleine wrote:
Andreas Achtzehn wrote:
rückwärts. NFS basiert auf UDP, daher macht es ja keinen klassischen [...] NFS ist inzwischen nicht mehr auf UDP beschränkt, sondern kann auch über TCP betrieben werden. Aber auch bei TCP wird man Timeouts abwarten müssen, um festzustellen, daß die Gegenstelle nicht mehr reagiert.
Oops, gilt das auch für Linux??? Wenn ja, wie geht das da??? -- mfg Peter Küchler, Planungsverband Frankfurt Region Rhein Main
Peter Kuechler wrote:
Am 30-Oct-2001 Eilert Brinkmann schrieb:
Matthias Kleine wrote:
Andreas Achtzehn wrote:
rückwärts. NFS basiert auf UDP, daher macht es ja keinen klassischen [...] NFS ist inzwischen nicht mehr auf UDP beschränkt, sondern kann auch über TCP betrieben werden. Aber auch bei TCP wird man Timeouts abwarten müssen, um festzustellen, daß die Gegenstelle nicht mehr reagiert.
Oops, gilt das auch für Linux??? Wenn ja, wie geht das da???
Auf Client-Seite mit der Mount-Option tcp. Hab's gerade mal mit einem Linux-Client (Kernel 2.4.12) und einem Solaris8-Server getestet und es läuft. Ob und wie gut es mit Linux als Server geht, weiß ich nicht. Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert@informatik.uni-bremen.de - eilert@tzi.org http://www.informatik.uni-bremen.de/~eilert/
Am 31-Oct-2001 Eilert Brinkmann schrieb:
Peter Kuechler wrote:
Am 30-Oct-2001 Eilert Brinkmann schrieb:
Matthias Kleine wrote:
Andreas Achtzehn wrote:
rückwärts. NFS basiert auf UDP, daher macht es ja keinen klassischen [...] NFS ist inzwischen nicht mehr auf UDP beschränkt, sondern kann auch über TCP betrieben werden. Aber auch bei TCP wird man Timeouts abwarten müssen, um festzustellen, daß die Gegenstelle nicht mehr reagiert.
Oops, gilt das auch für Linux??? Wenn ja, wie geht das da???
Auf Client-Seite mit der Mount-Option tcp. Hab's gerade mal mit einem Linux-Client (Kernel 2.4.12) und einem Solaris8-Server getestet und es läuft. Ob und wie gut es mit Linux als Server geht, weiß ich nicht.
Hmm, danke für die Info. Leider brauche ich es hier genau anders herum, hab Linux-Fileserver und Solaris-Clients;-) -- mfg Peter Küchler, Planungsverband Frankfurt Region Rhein Main
Am 30-Oct-2001 Andreas Achtzehn schrieb:
From: Bert Blümer [mailto:bert@bluemer.de]
Andreas Achtzehn schrieb:
From: Peter Blancke [mailto:blancke@gmx.de]
On Mon, 29 Oct 2001, Andreas Achtzehn wrote:
Da wir immer wieder Probleme mit einem NFS-Server haben und NFS allgemein die Unsicherheit in Person darstellt, suchen wir nach einer Alternative.
Welche Probleme? Und warum lassen sich diese nicht beheben=? Wir hatten Probleme, als ein anderer Server nicht [...] Meldung kam' riecht doch eigentlich immer nach Fehler bei der Namensauflösung... vorwärts wie rückwärts...
Kann es das gewesen sein?
Eigentlich nicht. Die Namensauflösung funktioniert vorwärts wie rückwärts. NFS basiert auf UDP, daher macht es ja keinen klassischen Handshake. Es schießt einfach wahllos die Anfragen durch die Leitungen, wenn nichts zurückkommt, versucht es das wohl nochmal, dann gibt es irgendwann auf. Eine klare Unterlegenheit des Protokolls.
Das stimmt nicht so ganz. Z.B bei Solaris wird NFS schon lange über TCP betrieben, wahlweise kann es aber auch UDP. Für Linux wird daran gearbeitet, auch ein NFS V4 ist in der Entwicklung. -- mfg Peter Küchler, Planungsverband Frankfurt Region Rhein Main
Am Mon, 29 Okt 2001, schrieb Andreas Achtzehn:
From: Peter Blancke [mailto:blancke@gmx.de]
On Mon, 29 Oct 2001, Andreas Achtzehn wrote:
Da wir immer wieder Probleme mit einem NFS-Server haben und NFS allgemein die Unsicherheit in Person darstellt, suchen wir nach einer Alternative.
Welche Probleme? Und warum lassen sich diese nicht beheben=? Wir hatten Probleme, als ein anderer Server nicht erreichbar war und die Verbindungen zwischen den Servern nicht getrennt werden konnte. Jedesmal, wenn man sich das Verzeichnis anschauen wollte, dauerte es fast eine Minute, bis eine "nicht erreichbar"-Meldung kam.
Zweite, wichtigere Sache: NFS ist UDP-basiert, daher ist es sehr leicht, es zu spoofen. Wir suchen da was besseres.
Guck Dir mal Coda an. http://www.coda.cs.cmu.edu/ Scheint ein gegenüber NFS deutlich fortentwickelteres Filesystem zu sein. Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Andreas Achtzehn wrote:
Wollte nicht gleich mit Kanonen auf Spatzen schießen. Nur endlich von NFS weg, da es zu viele Probleme macht, wenn ein Server mal nicht verfügbar ist.
Wenn clients == Linux/Unix: Alle Unixe reagieren empfindlich, wenn man ihnen ein Filesystem unter dem Hintern wegzieht, sei das ein NFS- oder ein sonstiges Filesystem. Selbst IBM-Maschinen habe ich unter solchen Bedingungen schon stehenbleiben sehen. Das ist kein serverseitiges Problem und wird sich nicht beheben lassen, indem man das Netzwerk-Filesystem ändert. Wenn clients == Windows: Was hat das mit NFS zu tun? Dann ist Samba Dein Freund, und es sollte keine Probleme geben (Freigabe nicht erreichbar, na und?). - Matthias
Hi Andreas, Andreas Achtzehn wrote:
Da wir immer wieder Probleme mit einem NFS-Server haben und NFS allgemein die Unsicherheit in Person darstellt, suchen wir nach einer Alternative.
Was fuer eine SuSE Version verwendest du denn? Ich hatte glaub so bis 7.1 immer meine Muehe mit NFS, seit dem laeuft aber alles reibungsfrei. Die Konfigurationsdateien sind etwas kleinkariert, da muss man ein bischen mit Tabs/Space aufpassen. Ansonsten solltest du mal deine Probleme schildern, damit wir versuchen koennen dir damit weiterzuhelfen. Jan -- ETES - Espenhain & Theofel EDV-Systemhaus GbR Libanonstrasse 58 A * D-70184 Stuttgart Phone +49 711 4895550 * Fax +49 711 4809761 EMail: info@etes.de --- URL: www.etes.de
From: theofel@etes.de [mailto:theofel@etes.de]
Hi Andreas,
Andreas Achtzehn wrote:
Da wir immer wieder Probleme mit einem NFS-Server haben und NFS allgemein die Unsicherheit in Person darstellt, suchen wir
nach einer
Alternative.
Was fuer eine SuSE Version verwendest du denn? Ich hatte glaub so bis 7.1 immer meine Muehe mit NFS, seit dem laeuft aber alles reibungsfrei. Die Konfigurationsdateien sind etwas kleinkariert, da muss man ein bischen mit Tabs/Space aufpassen.
Ansonsten solltest du mal deine Probleme schildern, damit wir versuchen koennen dir damit weiterzuhelfen.
Jan
Ich hab verschiedene Systeme im Einsatz. So sieht es in etwa aus: sv1 (SuSE 6.4) --<Internet>-- sv2 (SuSE 7.2) <--LAN--> sv3 (SuSE 7.2) Als sv1 ausgefallen war, konnte sv2 die Verbindung nicht kappen (device busy). Als ich von sv3 per NFS auf Dateien auf sv2 zugreifen wollte, blieb der cd-Befehl einfach stehen. Ich konnte gar nichts mehr machen. Andere Verbindung aufmachen und den Prozess killen war die letzte Möglichkeit. Das ist aber wie gesagt nicht der einzige Grund, von NFS wegzuwollen: Es ist einfach zu unsicher, ich möchte ein Protokoll, dem ich vertrauen kann. Kein UDP-HickHack, dass sich u.U. schon überlebt hat. Gruß, Andreas
Am 29-Oct-2001 Andreas Achtzehn schrieb:
From: theofel@etes.de [mailto:theofel@etes.de]
Hi Andreas,
Andreas Achtzehn wrote:
Da wir immer wieder Probleme mit einem NFS-Server haben und NFS allgemein die Unsicherheit in Person darstellt, suchen wir
nach einer Alternative.
Was fuer eine SuSE Version verwendest du denn? Ich hatte glaub so bis 7.1 immer meine Muehe mit NFS, seit dem laeuft aber alles reibungsfrei. Die Konfigurationsdateien sind etwas kleinkariert, da muss man ein bischen mit Tabs/Space aufpassen.
Ansonsten solltest du mal deine Probleme schildern, damit wir versuchen koennen dir damit weiterzuhelfen.
Kurz zu dir Jan: Ich habe die Erfahrung gemacht, das es hauptsächlich von den Kernelversionen und den versionen der NFS-Tools abhängig war, wie gut es läuft (ich rede jetzt nur von Kernel-NFS!) Ich hatte früher selber mehr als genug Ärger damit. Ich habe fleissig Kernelupdates (worüber mancher hier nur den Kopf geschüttelt hat:-> ) gemacht und immer die Tools auf dem neusten Stand gehalten, irgend wann war es gut;-)
Ich hab verschiedene Systeme im Einsatz.
So sieht es in etwa aus:
sv1 (SuSE 6.4) --<Internet>-- sv2 (SuSE 7.2) <--LAN--> sv3 (SuSE 7.2)
Dazu muß man bemerken, das NFS eigentlich nie für den Einsatz in solch unsicheren Netzen wie dem Internet ausgelegt/entwickelt war. Es wird also eigentlich "zweckentfremdet" eingesetzt.
Als sv1 ausgefallen war, konnte sv2 die Verbindung nicht kappen (device busy). Als ich von sv3 per NFS auf Dateien auf sv2 zugreifen wollte, blieb der cd-Befehl einfach stehen. Ich konnte
gar nichts mehr machen.
Mit den aktuellen Versionen von knfs sollte in eine solchen Fall folgendes funktionieren: Auf sv3 samba anhalten dann auf sv3 ein umount der NSF-Verzeichnisse von sv2 (wenn samba noch läuft kommt sonst ein device busy) dann auf sv3 den nfs server anhalten Dann auf sv3 ein umount der NSF-Verzeichnisse von sv1 (wenn der nfsserver noch läuft kommt sonst ein device busy) Bei dem jeweiligen unmount wird zwar gemeckert, aber er wird durchgeführt. Danach kann man den nfsserver auf sc2 wieder starten (wenn es sinnvoll ist) und dann auch wieder die server auf sv3. -- mfg Peter Küchler, Planungsverband Frankfurt Region Rhein Main
Hallo Andreas,
From the keyboard of Andreas,
Hallo Liste!
Da wir immer wieder Probleme mit einem NFS-Server haben und NFS allgemein die Unsicherheit in Person darstellt, suchen wir nach einer Alternative.
Womit habt ihr Erfahrungen gemacht?
AFS, lief damals unstabil.
Was könnt ihr empfehlen?
AFS.
Liefert SuSE so was mit?
weiß nicht. http://www.openafs.org/ Es wird demnächst an der FH an der ich studiere eingesetzt und wenn es mittlerweile stabiler geworden ist, denk ich das es eine gute Alternative zu NFS ist. bye Waldemar
From: Waldemar Brodkorb [mailto:waldemar@thinknow.de]
Hallo Andreas,
From the keyboard of Andreas,
Hallo Liste!
Da wir immer wieder Probleme mit einem NFS-Server haben und NFS allgemein die Unsicherheit in Person darstellt, suchen wir nach einer Alternative.
Womit habt ihr Erfahrungen gemacht?
AFS, lief damals unstabil.
Was könnt ihr empfehlen?
AFS.
Liefert SuSE so was mit?
weiß nicht.
Es wird demnächst an der FH an der ich studiere eingesetzt und wenn es mittlerweile stabiler geworden ist, denk ich das es eine gute Alternative zu NFS ist.
Ich hab schon einiges über AFS gelesen und es hört sich wirklich toll an. Nur ist es für mich ein Mit-Kanonen-Auf-Spatzen-Schießen. Mein einziges Problem ist die Freigabe eines Verzeichnisses auf dem Server zum Backup mit Dateirechten, user-ids etc. Da ist AFS, dass ja mehr auf Ausfallsicherheit (File-Server-Cluster) und Volume-Transparenz zielt, für mich eine übertriebene Lösung. Hab zu dem Thema auch schon von Coda (http://coda.cs.cmu.edu) gelesen, allerdings bietet es die gleiche Funktionalität wie AFS und braucht dazu auch noch raw-devices.
Da wir immer wieder Probleme mit einem NFS-Server haben und NFS allgemein die Unsicherheit in Person darstellt, suchen wir nach einer Alternative.
Womit habt ihr Erfahrungen gemacht? Was könnt ihr empfehlen? Liefert SuSE so was mit?
Gruß, Andreas
Hallo zusammen! Ich habe insofern auch Probleme mit NFS, als ich NFS nur ohne Firewall nutzen kann. Läuft auf meinem Server eine Firewall (auch wenn die Ports, die ich - siehe man rpc.mountd und man rpc.nfsd - per Definition auf 980/tcp und 2049/tcp gesetzt habe), so kann ich NFS backen. Da kommt, wenn ich mal Glück habe, nach 2 Minuten des Wartens auf den mount-Befehl die Info "RPC timed out". Wie gesagt: Laut man-files sollte die Firewall mit den offenen Ports 980 und 2049 richtig konfiguriert sein. Trägt man nämlich in die /etc/services irgendwo den Eintrag "mountd 980/tcp" oder so ähnlich (hab's richtig, bin aber zu faul nachzuschauen) ein, so sollte rpc.mountd mit diesem Port starten. Da hält sich aber so ziemlich nichts dran... Tschüss! Christian
participants (11)
-
Andreas Achtzehn -
Bert Blümer -
Christian Weickhmann -
Christoph Maurer -
Eilert Brinkmann -
Jan Theofel -
Matthias Kleine -
Matthias Kleine -
Peter Blancke -
Peter Kuechler -
Waldemar Brodkorb