Das ed2k-gtk-gui Handbuch: Fragen und Antworten, Tips und Tricks

Next Previous Contents

## 5. Fragen und Antworten, Tips und Tricks

## 5.1 Frequently Asked Questions (FAQ) - Häufig gestellte Fragen

Bitte wirf einen Blick auf die FAQ ( Englisch, Deutsch oder Französisch) auf der Projekt Homepage.

## 5.2 Einen HTTP-Proxy zum holen von Serverlisten über HTTP benutzen

Wenn du einen HTTP Proxy Server für den Zugriff auf das Internet benutzen musst und du möchtest, dass die GUI diesen Proxy benutzt, um Serverlisten über HTTP zu holen, musst du die Umgebungsvariable 'http_proxy' setzen, bevor du die GUI startest (=Befehlszeile):

> `

>     export http_proxy=http://wwwcache.somehost.net:8080/

> `

Beachte den Slash '/' am Ende. Andere Programme wie wget und lynx werden diese Einstellung auch benutzen. Um zu prüfen, ob die Variable gesetzt ist kannst du mit `echo $http_proxy` prüfen.

Das Beste ist wahrscheinlich die export-Zeile ans Ende deiner ~/.bashrc Datei anzufügen, dann musst du das nicht jedesmal eintippen, wenn du die GUI startest. Die Umgebungsvariable 'http_proxy' wird dann jedesmal, wenn du dich anmeldest automatisch gesetzt.

## 5.3 Corruption found in XYZ at N

Das bedeutet, dass nachdem ein Teil einer Datei heruntergeladen wurde die Checksumme (Teil-Hash) dieses Teils der Datei auf deiner Festplatte nicht mit der Checksumme übereinstimmt, die der Teil haben sollte.

Darüber muss man sich keine Gedanken machen. eDonkey/Overnet hat das Problem bemerkt und wird diesen Teil erneut herunterladen.

Übertragungsfehler passieren eben. Dagegen kann man nichts machen. Mach dir keinen Kopf. Falls das aber mit verschiedenen Dateien sehr, sehr oft passiert ist es möglich, dass es irgendein Hardwareproblem gibt (RAM/Festplatte/Controller/Kabel fehlerhaft, Overclocking, Überhitzung des Systems, Dateisystemprobleme usw) .

## 5.4 Ändern des Standardbrowsers

Die GUI sucht auf deinem System nach einem Browser und wird den ersten, den sie findet benutzen (Galeon, Konqueror, Mozilla, Netscape, Opera). Wenn du einen bestimmten Browser bevorzugst, solltest du die Umgebungsvariable 'BROWSER' in der Befehlszeile setzen bevor du die GUI startest:

> `

>     export BROWSER=/usr/bin/konqueror

> `

Du musst den absoluten Pfad des Programms angeben. Diesen Pfad erhältst du entweder mit `whereis konqueror` oder `which konqueror` (Anmerkung: `which` findet die Programme vielleicht nicht immer, weil Pfade fest vorgegeben sind).

Das Beste ist wahrscheinlich die export-Zeile ans Ende deiner ~/.bashrc Datei anzufügen, dann musst du das nicht jedesmal eintippen, wenn du die GUI startest. Die Umgebungsvariable 'BROWSER' wird dann jedesmal, wenn du dich anmeldest automatisch gesetzt.

## 5.5 Das Vorschau-Skript anpassen

Mit der neuesten GUI Version kannst du laufende Downloads ansehen, bevor sie komplett sind, wenn der Core auf deinem lokalen System läuft und wenn dein Core die Namen der temporären Dateien (x.part) mitteilt. Alle aktuellen Versionen des Core sollten das machen.

Wenn du die Vorschaufunktion zum ersten Mal benutzt, schreibt die GUI ein Standardskript auf deine Festplatte. Dieses Vorschauskript heisst `~/.ed2k_gui/ed2k_gui_preview`. Diese Datei kann mit einem Texteditor nach deinen Bedürfnissen angepasst werden.

Und so funktioniert das: Die GUI ruft das Skript auf und übergibt den Pfad der teilweise heruntergeladenen Datei als Parameter. Dieser erscheint im Skript als `$*` (was soviel bedeutet wie: 'mit allen erhaltenen Parametern ersetzen'). Die GUI wird auch eine Umgebungsvariable `ED2K_PREVIEW_EXTENSION` auf die Dateierweiterung in Kleinbuchstaben setzen (weil man mit einem Namen wie /mnt/temp/34.part den Dateityp nicht kennt).

Jetzt vergleicht das Skript die Dateierweiterung mit den eingetragenen Werten im `case`-Teil des Skripts. Gibt es eine Übereinstimmung wird der Name zum abspielen der Datei in der Variable `PREVIEW_BIN` mit jeglichen Parametern für das Programm gespeichert. Danach wird das Programm gestartet. Wie du siehst ist es kinderleicht dein Lieblingsprogramm einzustellen oder neue Dateitypen hinzuzufügen.

Nachdem das Programm beendet ist musst du auf Enter drücken, um das xterm Fenster, das geöffnet wurde, um die Ausgaben des Programms anzuzeigen, zu schliessen (somit kann das Abspielen auch mit Strc+c unterbrochen werden, z.B. für mpg123/ogg123).

Wenn du nicht möchtest, dass das Skript wartet nachdem das Programm beendet wurde, entfernst du einfach folgende zwei Zeilen aus dem Skript:

> `

>     echo "Finished. Hit <enter> to close this window"
>     read

> `

Wenn du möchtest, dass das xterm Fenster gleich nach dem Aufruf des Programms geschlossen wird entferne einfach die beiden Zeilen von oben und ändere die Zeile, in der das Programm augerufen wird in:

> `

>     $PREVIEW_BIN "$*" &

> `

## 5.6 ed2k-links benutzen

Bitte schau dir den Abschnitt über ed2k-links im Kapitel Anwendung an.

## 5.7 Einen Befehl beim Beenden eines Downloads ausführen

TODO, see FAQ

## 5.8 Sonderzeichen werden in der GUI nicht richtig angezeigt

Wenn das in Dateinamen oder Servernamen passiert, dann wahrscheinlich wegen deiner Spracheinstellung. Du musst rausfinden, wie du die Spracheinstellung auf etwas passendes setzt. Wenn du die Spracheinstellung aber änderst, dann benutze auf jeden Fall den UTF8 Zeichensatz und nicht ISO-8859-X (z.B. de_DE.UTF8).

Wie auch immer, eDonkey2000 und Overnet teilen der GUI oder anderen Clients nicht mit, mit welchem Zeichensatz ein String codiert ist. Also wirst du Dateinamen bei den Suchergebnissen nie genau so sehen, wie jemand anders mit einer anderen Spracheinstellung. Das sollte aber normalerweise kein großes Problem sein.

## 5.9 DNS lookup für Server

TODO, see FAQ

## 5.10 Ich habe ein Mausrad und es passieren komische Dinge. Warum?

Warum? Keine Ahnung. Wahrscheinlich ein GTK+ Bug. Bei den Optionen kannst du die 'Doppelklicks in den Listen deaktivieren'. Das sollte das Problem beheben.

## 5.11 Die Vorschaufunktion ist abgeschaltet - was stimmt nicht?

Wenn die Vorschaufunktion im Rechtsklick Menü in der Downloadliste ausgegraut ist gibt es dafür zwei Gründe:

(1) es ist keine Reihe ausgewählt

(2) die GUI denkt, das der Core auf einem anderen Computer läuft. Das ist der Fall, wenn du einen anderen Hostnamen als 'localhost' oder '127.0.0.1' angibst. (Anmerkung: wegen Anfragen von Benutzern ist eine ausgeklügeltere Erkennung des Hostnamens verworfen worden. Also ist zur Zeit alles bis auf 127.0.0.1 oder localhost nicht lokal.)

## 5.12 Mehrere eDonkeys auf verschiedenen Computern mit einer Internetverbindung

Problem: Dein Router kann eine Portnummer nur an genau eine IP Adresse weiterleiten.

Lösung: Betreibe alle Donkey Cores auf unterschiedlichen Ports (z.B. einen mit 3662, einen mit 4662, einen mit 5662 usw), und lasse deinen Router den entsprechenden Port zur passenden IP weiterleiten. Anmerkung: Es muss für jeden Core nur ein TCP Port weitergeleitet werden, um eine hohe ID zu erhalten.

## 5.13 Mehrere Cores

Möglicherweise laufen mehrere Cores und du willst sie entweder gleichzeitig oder zu unterschiedlichen mit einer GUI verbinden. In diesem Fall wirst du wahrscheinlich die '-n' Befehlszeilenoption der GUI benutzen wollen, was die GUI in einer anderen 'Instanz' startet. Das bedeutet, dass ein anderer Satz Konfigurationsdateien benutzt wird. Für den ersten Core startest du die GUI ganz normal. Für den zweiten Core übergibst du die Option '-n 2' an die GUI. Damit werden deine Statistiken usw getrennt behandelt. Du kannst die GUI beim starten auch automatisch zum entsprechenden Core verbinden lassen.

## 5.14 Mehrere GUIs mit einem Core

Das ist ein Problem. Ein Core kann immer nur mit einer GUI verbunden sein.

Es gibt aber eine einfache und freie Lösung dafür: VNC.

Installiere einen VNC Server auf dem Rechner, auf dem der Core läuft und VNC Clients (gibts für alle Plattformen) auf den Rechnern, von denen du die GUI und den Core kontrollieren willst. Jetzt startest du die GUI auf dem Rechner, auf dem der Core läuft und kontrollierst die GUI über VNC. Ein VNC Desktop kann von mehreren Usern genutzt werden, also sollte dieses Problem gelöst sein. Wenigstens theoretisch, da ich es noch nicht selbst probiert habe.

## 5.15 Ein kleines Startskript

Das ist mein (Thomas) Startskript for eDonkey. Ich hatte keine Lust jeden Tag in das richtige Verzeichnis zu wechseln... Es holt eine neue Serverliste, startet den Core, wartet und startet dann die GUI.

    #!/bin/sh
    # eDonkey2000 Startskript
    # Den Donkey in seinem Heimatverzeichnis starten, ersetz das mit deinem eDonkey Verzeichnis!
    cd ~/edonkey
    # Serverliste holen (wir versuchen clever zu sein)
    mv server.met _server.met
    wget http://ocbmaurice.dyndns.org/pl/slist.pl/server.met?download/server-max.met || cp _server.met server.met
    rm _server.met
    # eDonkey in einer benannten screen-Session starten (Du brauchst GNU screen!)
    screen -dmS donkey -- ./donkey - !
    # Alternative:
    # ./donkey - ! &
    # Ein wenig warten...
    sleep 5
    # Die GUI starten
    ed2k_gui -c

## 5.16 Den Core im Hintergrund oder über telnet/ssh starten

Normalerweise kannst du Programme in der Shell mit einem '&' am Ende starten und sie werden im Hintergrund laufen. Leider funktioniert das mit dem eDonkey nicht richtig. Ähnliche Probleme gibt es auch, wenn du denn Donkey über telnet/ssh (ssh ist natürlich zu bevorzugen!) starten willst. Natürlich soll der Core weiterlaufen, wenn du dich abmeldest. 'nohup' funtioniert leider mit dem Donkey auf vielen Systemen nicht.

Für solche Zaubereien brauchst du das 'screen' Tool, das wahrscheinlich schon auf deinem System installiert ist. Lies das Manual mit `man screen>`. Hier ist eine Zusammenfassung:

Startw den Donkey mit

> `

>     cd /home/joe/ed2k/
>     screen -dmS donk ./donkey0.50.1 - !

> `

Das 'cd /home/joe/ed2k' stellt sicher, dass der Core seine Konfigurationsdateien immer im selben Verzeichnis liest und schreibt. Wenn du das nicht machst, wird der Core diese Dateien in das aktuelle Arbeitsverzeichnis schreiben, was wahrscheinlich irgendwann Probleme bereitet.

Die Option '-' lässt den Core nach einer GUI horchen und die Option '!' lässt den Core nur Anweisungen von der GUI annehmen, nicht aber von der Befehlszeile. Das wird benötigt, um den Core korrekt aus der GUI zu beenden.

screen verlässt du, indem du zuerst Strg-a, dann Strg-d drückst. Jetzt solltest du wieder in der Shell sein.

Du kannst den Donkey jederzeit mit

> `

>     screen -d -r donk

> `

zurückholen.

## 5.17 Alle Server sagen ich wäre 'firewalled', aber das stimmt NICHT!

Das kann verschiedene Gründe haben. Das mit der Firewall darf man nicht so wörtlich nehmen. 'Firewalled' beudeutet nur, dass sich ein Server nicht erfolgreich über den eingestellten Port (normalerweise 4662) mit dem Core verbinden konnte.

Natürlich ist eine Möglichkeit dafür, dass du wirklich hinter einer Firewall bist. Entweder läuft diese auf deinem Computer oder auf deinem Gateway/Router und blockiert den ankommenden Verbindungsversuch von dem Server.

Eine andere Möglichkeit ist, dass du einen DSL Router oder etwas ähnliches verwendest und dieser NAT (= Network Address Translation = IP Masquerading = Internet Connection Sharing/ICS) ausführt. NAT wird benutzt, damit mehrere Computer eines kleinen Netzwerk sich eine Internetverbindung teilen können In diesem Fall wird deinem Router die 'öffentliche IP' von deinem ISP (Internet Service Provider) zugewiesen, und alle Computer im LAN (Local Area Network) haben eine 'private IP' (z.B. 192.168.x.x oder 10.x.x.x). In diesem Fall musst du Portweiterleitung auf dem Router einrichten. Der TCP Port 4662 muss zu dem Computer mit dem Core weitergeleitet werden. Wenn in deinem Netzwerk mehrere Donkeys laufen, musst du sie alle auf unterschiedlichen Ports betreiben und jeden dieser Ports zur entsprechenden IP weiterleiten lassen.

Ausserdem gibt es einige falsch eingerichtete Server, die keine abgehenden Verbindungen zu 'exotischen' Ports erlauben (also andere als 4662). Diese Server werden dir sagen du wärst 'firewalled', obwohl sie es selbst sind. Das wird wahrscheinlich gelegentlich passieren, wenn du einen anderen Port als TCP 4662 benutzt.Falls aber wirklich alle Server behaupten du wärst 'firewalled', ist das kein sehr wahrscheinlicher Grund dafür.

## 5.18 Ich muss einen SOCKS Proxy benutzen, aber der Core scheint das nicht zu unterstützen

Leider Unterstützt er wirklich keine SOCKS Proxy Server, aber du könntest tsocks probieren, was SOCKS Proxy Unterstützung für Programme bereitstellt, die das eigentlich nicht unterstützen. (Das funktioniert über ein Library, die Network System Calls nach connect() abfängt und sie zu einem SOCKS Proxy weiterleitet)

## 5.19 Die DSL/Cable Verbindung wird träge und Surfen wird zur Qual

Deine Internetverbindung wird, nachdem eDonkey eine Weile läuft schrecklich langsam oder träge (der Verbindungsaufbau zu einem Webserver oder das Abrufen deiner eMails dauert plötzlich einige Sekunden statt Millisekunden)

Vorneweg: wenn das Problem mit bestimmten Servern unabhägig davon, ob eDonkey läuft oder nicht, reproduziert werden kann liegt das Problem woanders. Falls du PPPoE (PPP-over-Ethernet) benutzt solltest du beispielsweise die MTU Einstellungen deines Netzwerkgerätes (pppX oder ethX) überprüfen. Falls das Problem nur auftritt, wenn eDonkey viel uploaded: lies weiter.

Hier eine kleine Zusammenfassung des Problems: dein DSL Router hat eine eingebaute Warteschlange für Pakete, die ziemlich einfach arbeitet: Das zuerst ankommende Paket geht auch zuerst wieder raus (FIFO = first in first out). Wenn die Warteschlange deines Routers voll ist, werden einfach Pakete "weggeworfen". Das ist ein ganz normaler Vorgang und das TCP Protokoll kümmert sich darum. Das Problem besteht darin, dass für jedes empfangene Paket eine kleine Bestätigung gesendet werden muss (ACK = acknowledgement), damit der Absender sicher sein kann, dass das Paket angekommen ist. Dieser Mechanismus wird benutzt, um verlorengegangene Pakete auszugleichen und die Übertragungsgeschwindigkeit an die verfügbare Bandbreite anzupassen. Wenn die Warteschlange deines Router wegen dem Upload von eDonkey voll ist und du dich mit einem Webserver verbinden willst, wird die Verbindungsanfrage (SYN) zum Router geschickt, der sie einreiht. Wenn die Warteschlange aber voll ist wird es einige Sekunden dauern, bis das SYN Paket tatsächlich zum Webserver gesendet wird, weil der Router normalerweise nicht zwischen wichtigen und unwichtigen Paketen unterscheiden kann. Das gleiche wiederholt sich für jedes weitere Paket, das du sendest (z.B. eine HTTP-GET Anfrage deines Webbrowsers). Darum wird die Sache dann träge. Du musst bedenken, dass auch wenn deine Verbindungsgeschwindigkeit für den Upload technisch gesehen z.B. 128kbps (16 kB/s) ist, wird doch ein Teil davon durch die Header der unterschiedlichen beteiligten Protokolle verbraucht. Also ist die effektive Geschwindigkeit niedriger und deine Uploadgeschwindigkeit kann leicht ausgereizt werden, auch wenn die eingestellten Werte unter dieser Grenze liegen.

Was tun?

Ganz einfach: du möchtest Quality-of-Service (QoS). Neuere 2.4.x Linux Kernel haben das schon dabei, du musst nur sicherstellen, dass dein Kernel mit voller QoS Unterstützung kompiliert ist (als Modul oder fest eingebaut).

Das Prinzip ist einfach: wir stellen sicher, dass die Paketwarteschlange des Router nie voll wird. Um das zu erreichen werden die Pakete nicht mehr auf dem Router, sondern auf deinem Linuxrechner in die Warteschlange gestellt. (Anmerkung: normalerweise passiert das nicht, weil die Verbindung von deinem Rechner zum Router sehr viel schneller als die Verbindung zum Internet ist, so dass der Linux Kernel im Normalfall einfach alles ohne Verzögerung zum Router schicken wird). Da jetzt die Warteschlange von deinem Linux Kernel verwaltet wird kannst du alle möglichen schönen Dinge damit machen. Zum Beispiel können einige Pakete Vorrang vor anderen erhalten. Diese Pakete werden dann das Warten 'überspringen' und sofort gesendet, auch wenn andere (weniger wichtige) Pakete warten. Ich persönlich gebe dem Verkehr auf den 'interaktiven' Ports (21, 22, 23 und 110 aber nicht 80, weil viele Windowsbenutzer ihren Donkey diesen Port benutzen lassen), dem Verkehr zu meinen 'Lieblingswebseiten' und allen 'kleinen Pakete' (normalerweise SYN und ACK) die höchste Priorität.

Eine gute Beschreibung davon gibt es hier von Emmanuel Roger: http://www.prout.be/qos/QoS-connection-tuning-HOWTO.html.

Aus meiner Erfahrung kann ich nur raten die Finger von anderen HOWTOs (wie das ADSL-Bandwidth-Management-HOWTO), zu lassen. Es sei denn du suchst eine Herausforderung. Dieses und die meisten anderen HOWTOs, die ich dazu gefunden habe, erfordern es die Kernel-Quellen und die ipables-Quellen zu patchen, was sich als besonders schwierig erweist, wenn die dort erwähnten Patches nicht mit den neuesten Kernel und iptables Releases funktionieren...

Hier ist ein Ausschnit aus meinem iptables start-up script, falls es jemanden interessiert:

            ##########################################################
            #
            # Quality of Service (QoS)
            #
            # from http://www.prout.be/qos/QoS-connection-tuning-HOWTO-4.html
            #
            ##########################################################

            # reset

            tc qdisc del dev eth1 root 2>/dev/null > /dev/null

            # mark packets with size 0-500 (considered interactive traffic)
            #
            iptables -t mangle -A OUTPUT -m length --length 0:500 -j MARK --set-mark 3

            # mark UDP packets as important as well
            #
            iptables -t mangle -A OUTPUT -p udp -j MARK --set-mark 3

            # bigger packets will be marked data traffic
            #
            iptables -t mangle -A OUTPUT -m length --length 500:1500 -j MARK --set-mark 4

            # mark ssh/smtp/pop3 packets also as priority
            # (not http, due to many donkey people using port 80)

            for i in 22 25 110
            do
                    iptables -t mangle -A OUTPUT -p tcp --dport "$i" -j MARK --set-mark 3
                    iptables -t mangle -A OUTPUT -p tcp --dport "$i" -j TOS --set-tos Minimize-Delay
            done

            # mark favourite sites high priority traffic.
            #
            # slashdot(new) slashdot.org, www.ct.heise.de,
            #       edonkey2000, jigle.com, jabber.org
            #       google
            #
            for i in "66.35.250.150" "64.28.67.150" "193.99.144.71" \
                            "198.77.34.120" "212.249.10.246" "208.245.212.108" \
                            "216.239.39.101"
            do
                    iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.255" -j MARK --set-mark 3
                    iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.255" -j TOS --set-tos Minimize-Delay
            done

            # mark whole subdomains important
            #
            # amazon/imdb - sourceforge.net
            #
            for i in "207.171.166.0" "216.136.171.201"
            do
                    iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.0" -j MARK --set-mark 3
                    iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.0" -j TOS --set-tos Minimize-Delay
            done

            # create root cvq qdisc for our device eth1
            #
            tc qdisc add dev eth1 root handle 10: cbq bandwidth 10Mbit avpkt 1000 mpu 64

            # DL bandwidth = 576 kbits
            # UL bandwidth = 288 kbits
            #
            # Interactive class rate = DL bandwidth / 20 = 29
            # Data class rate = UL bandwidth - Interactive class rate = 259
            #
            # Let's make the latter a bit smaller just to be on the safe side
            # (we don't want a single packet ever to be queued on the router)
            #  => 190, which is much lower than suggested, but works best wor me
            #
            # (1500 is interface MTU?)
            #
            tc class add dev eth1 parent 10:0 classid 10:1 cbq bandwidth 10Mbit \
                    rate 29Kbit allot 1500 prio 1 maxburst 10 avpkt 100 isolated weight 100

            tc class add dev eth1 parent 10:0 classid 10:2 cbq bandwidth 10Mbit \
                    rate 190Kbit allot 1500 prio 8 maxburst 2 avpkt 1500 bounded weight 1500

            # tell kernel which class we want to send packets to

            tc filter add dev eth1 parent 10:0 protocol ip handle 3 fw flowid 10:1
            tc filter add dev eth1 parent 10:0 protocol ip handle 4 fw flowid 10:2

## 5.20 "Couldn't create Temp File" Fehlermeldung

Das scheint mit neueren Cores zu passieren. Die wahrscheinlichste Ursache ist, dass eDonkey/Overnet mehr sogenannte 'file descriptors' (ein 'file descriptor' für jede öffene Datei und Netzwerkverbindung) benutzt, als dir als normaler Benutzer auf deinem System erlaubt sind.

Wie viele 'file descriptors' dir als Benutzer erlaubt sind, kannst du mit

> `

>     %ulimit -n

> `

prüfen. Dieser Wert ist für alle laufenden Programme und Prozesse.

Diese Grenze kann als root in der Datei /etc/security/limits.conf durch Anhängen einer Zeile wie der Folgenden geändert werden:

> `

>     tim     hard    nofile  4096

> `

'tim' ist der Benutzername, 'hard' steht für 'hard limit', 'nofile' steht für die Zahl der erlaubten 'file descriptors' und 4096 ist der Wert. Du kannst auch eine größere Zahl angeben, aber 4096 sollte ausreichen.

Jetzt mußt du dich noch um eine Sache kümmern, und das könnte sich von Distribution zu Distribution unterscheiden. Wenn es die Datei `/etc/pam.d/common-session` gibt, dann sollte folgende Zeile enthalten sein:

> `

>     session required  pam_limits.so

> `

Wenn es diese Datei n icht gibt, musst du diese Zeile in `/etc/pam.d/login` hinzufügen oder auskommentieren. Wenn du gdm/kdm/xdm zum einloggen benutzt, solltest du `/etc/pam.d/gdm`, `/etc/pam.d/kdm` oder `/etc/pam.d/xdm` diese Zeile hinzufügen.

Nach dem Bearbeiten dieser Datei musst du dich noch einmal 'richtig' anmelden (Abmelden von X und erneutes Anmelden an der Konsole oder xdm/kdm/gdm). Wenn du danach 'ulimit -n' in einem xterm ausführst, sollte der neue Wert ausgegeben werden und das Problem behoben sein.

Das genaue Vorgehen könnte von deinem System / deiner Distribution abhängen. Lass es mich bitte wissen, falls das Vorgehen auf deinem System anders ist.

## 5.21 Die GUI erkennt meinen manuell gestarteten Core nicht!

Zuallererst: Hast du die '-' Option beim starten des Cores benutzt? Die '-' Option lässt den Core auf dem angegebenen aport nach einer GUI horchen. Wenn die Option nicht übergeben wird kann die GUI keine Verbindung zum Core herstellen. Deswegen sucht die GUI nur nach einem Core der mit der Option gestartet wurde.

Zweistens erwartet die GUI, dass der Core 'donkey*', 'overnet*', oder 'cdonkey*' heisst (nur der Anfang des Namens ist wichtig). Wenn du das Programm umbenannt hast, kann die GUI es nicht finden (wie sollte sie?).

## 5.22 Ich möchte die GUI-Core Verbindung über SSH tunneln... aber die GUI besteht auf einem Lokal laufenden Core, wenn ich 'localhost'oder '127.0.0.1' als lokales Ende des Tunnels nehme.

Zwei einfache Lösungen: Entweder eine andere (nicht localhost) IP des Rechners nehmen, z.B. die IP der Netzwerkkarte (z.B. 192.168.0.2), oder eine Zeile zu /etc/hosts hinzufügen, z.B. 'core.outerspace.world 127.0.0.1' und 'core.outerspace.world' im Verbindungsdialog der GUI eintragen.

Weil die Entscheidung, auf einem lokal laufenden Core bei 'localhost' zu bestehen. absichtlich getroffen wurde ist es unwahrscheinlich, dass es geändert wird. Die Entscheidung wurde zugunsten des Durchschnittsbenutzer getroffen, um ihm den Einstieg zu erleichtern.

Anmerkung: die Erkennung eines laufenden Cores funktioniert momentan nur mit einem eingehängten /proc Dateisystem unter GNU/Linux Benutzer anderer Betriebssysteme (*BSD, MacOSX) können gerne einen Patch schicken, um das zu ändern :)

## 5.23 Ich habe einen Bug gefunden - was soll ich machen?

Prüfe, ob du ihn reproduzieren kannst und/oder wie er reproduziert werden kann.

Überprüfe, ob der Bug schon gemeldet wurde und, falls dem so ist, ob er schon gefixt wurde. Stell sicher, dass du alle Bugs siehst, sonst wirst du nur die offenen, nicht aber die schon geschlossenen Bugs zu Gesicht bekommen.

Wenn du weisst, wie man mit dem CVS umgeht, hol dir bitte die neueste Version der GUI aus dem CVS, um zu prüfen, ob es den Bug da auch noch gibt.

Übermittle den Bug mit dem Bug-Tracking System des Projekts mit so vielen Details wie möglich. Wenn du einen Sourceforge Account hast melde dich bitte an, damit ich im Falle weiterer Fragen auf dich zukommen kann. Eine andere Möglichkeit ist die 'monitor' ("Überwachungs-") Funktion oder von Zeit zu Zeit nachzuschauen, ob es weitere Fragen gibt.

## 5.24 Diese GUI macht mich glücklich - wie kann ich mich bedanken?

Schreib mir eine eMail. Positives Feedback macht immer Freude :-)

Ausserdem habe ich jetzt einen amazon.co.uk Wunschzettel und einen amazon.de Wunschzettel falls du mir zum Dank für die Millionen Stunden Arbeit an der GUI eine Kleinigkeit schenken willst ;)

Next Previous Contents