giFToxic läuft einfach nicht

Dieses Thema im Forum "Anwendungen" wurde erstellt von Luzifer, 30.08.2004.

  1. #1 Luzifer, 30.08.2004
    Luzifer

    Luzifer Schachspieler

    Dabei seit:
    09.03.2004
    Beiträge:
    540
    Zustimmungen:
    0
    Ort:
    Alpha Quadrant
    Hallo Ich habe folgendes Problem:
    Immer wenn ich giFToxic starten will kommt die Meldung "The giFT daemon was started but could not be connected to." Ich bin schon tausend mal die gift-setup durchgeganden. Hilft nichts :(
    Hier mal meine giftd.conf.template

    # $Id: giftd.conf.template,v 1.2 2003/12/12 12:15:49 jasta Exp $
    ###############################################################################

    ###############################################################################
    # MAIN

    [main]

    #
    # Boolean determining whether or not this file has been reviewed and is
    # complete. giFT will fail to start unless this is non-zero. This is done
    # so that we can make sure you, at the very least, read through this file.
    #
    # Default: 0
    #
    setup = 0

    #
    # Space separated list of hosts to allow connection to giFT's interface
    # protocol (running default on port 1213). This protocol is used for GUIs
    # to communicate with giFT and could be considered a security risk to allow
    # external connections.
    #
    # The following special keywords are supported:
    #
    # ALL - Synonym for 0.0.0.0/0
    # LOCAL - Synonym for 127.0.0.0/8 192.168.0.0/16 172.0.0.0/11 10.0.0.0/8
    #
    # Bitwidth fields are optional.
    #
    # Default: LOCAL
    #
    hosts_allow = LOCAL

    #
    # Port on which to listen for user interface connections. Unless you have a
    # special need to talk to the client on a non-standard port, just accept the
    # default.
    #
    # NOTE:
    # If you change this value, you will also need to modify the ui.conf
    # configuration for the machine which will be making outgoing connections
    # here.
    #
    client_port = 1213

    #
    # Determines whether or not to follow symbolic links. If this value is set
    # non-zero, symlinks will be traversed and a directory inode tracking system
    # will be used to ensure that giFT does not descend the same directory
    # twice. If you do not have any symlinks or do not want them traversed, set
    # this to 0 for a very minor efficiency gain.
    #
    # Windows users: this setting has no effect.
    #
    # Default: 1
    #
    follow_symlinks = 1

    #
    # Colon separated list of protocol plugins to load by default. If dynamic
    # library support is enabled, the plugin specified will be stat'd to check if
    # it is a loadable path. If that fails, the fallback method is to attempt to
    # construct the fully qualified path based on the configured environment.
    #
    # NOTES:
    # Without dynamic library support, this plugin must have been compiled into
    # your giFT binary. With, this plugin must exist in the installed
    # plugin directory. giFT -V will output this path to you, if you are not
    # sure.
    #
    # Protocol names are case sensitive, so use OpenFT, not Openft.
    #
    # For example, to use the OpenFT and Gnutella protocols use:
    #
    # OpenFT:Gnutella
    #
    # Default: none
    #
    plugins = OpenFT

    ###############################################################################
    # DOWNLOAD CONTROLS

    [download]

    #
    # Directory to store transfers while they are being operated on. Temporary
    # state files are also kept here. It is recommended, but not required, that
    # the incoming and completed directories are on the same partition (drive).
    #
    # Windows users: please use the following path specification:
    #
    # incoming=/[drive]/dir1/dir2
    #
    # For example, to refer to C:\Program Files\giFT\incoming, use:
    #
    # incoming=/C/Program Files/giFT/incoming
    #
    # Default (*nix): ~/.giFT/incoming
    # Default (Windows): /C/Program Files/giFT/incoming
    #
    incoming = ~/.giFT/incoming

    #
    # Directory which will contain files after they have successfully finished
    # downloading.
    #
    # Default (*nix): ~/.giFT/completed
    # Default (Windows): /C/Program Files/giFT/completed
    #
    completed = ~/.giFT/completed

    ###############################################################################
    # SHARE SUBMISSION AND UPLOAD CONTROL

    [sharing]

    #
    # Maximum amount of uploads allowed from the same user at any given time. It
    # is recommended that you keep this at 1 in order to prevent users from
    # unfairly queueing your connection.
    #
    # Default: 1
    #
    max_peruser_uploads = 1

    #
    # Determines whether or not to hide directories which contain a leading dot.
    # These directories are commonly meant to be "hidden" and thus should not be
    # submitted to the network. Selecting 0 here will submit all directories.
    #
    # Default: 1
    #
    hide_dot_files = 1

    #
    # Colon separated list of fully qualified paths you wish to share. These
    # directories will be recursed at giFT's startup and the files contained
    # within will be subjected to an MD5 hashing. The results will be cached and
    # will only be recalculated on a per share basis when the size or
    # modification time in the cache and on disk disagree, or the file name is
    # changed.
    #
    # Sanity notice:
    # Do NOT share source directories! Remote nodes will refuse to index your
    # shares if you are attempting to submit more than 64000 files.
    #
    # Security notice:
    # Do not share directories which may contain sensitive information, such as
    # ~ ($HOME). Also note that any directories shared here will be stripped of
    # all but the last path element when submitted to other nodes for indexing,
    # effectively "hiding" the directory prefix.
    #
    # Windows users: please use the following path specification:
    #
    # /[drive]/dir1/dir2:/[drive]/dir3/dir4 ...
    #
    # For example, to refer to C:\Program Files\giFT\shares and D:\shares, use:
    #
    # /C/Program Files/giFT/shares:/D/shares
    #
    # Default: none
    #
    root =

    #
    # Maximum amount of simultaneous uploads allowed. Setting this to -1 will
    # cause giFT to not limit outgoing transfers. 0 effectively disables sharing.
    # This may also be handled at run time via your GUI of choice.
    #
    # Default: -1
    #
    max_uploads = -1

    #
    # Controls when giFT periodically rescans your shared directories for any
    # changes (new files, missing files, changed files, etc.) and communicates
    # those changes to the underlying protocols. This parameter specifies how
    # often (in seconds) you want that to happen.
    #
    # For your reference
    # ==================
    # 0 turns off periodic auto-resync
    # 3600 one hour
    # 86400 one day
    # 604800 one week
    #
    # Default: 86400
    #
    auto_resync_interval = 86400

    #
    # Controls whether or not giFT should automatically share files that you have
    # finished downloading. This feature significantly improves the network's
    # abundance of files and helps ease the load on those sharing popular files.
    # It's a Good Thing (TM), please leave it on.
    #
    # Avoid setting your completed directories through sharing/root, as that
    # setting will duplicate recursion of the completed directory and cause
    # generally undesirable results.
    #
    # Default: 1
    #
    share_completed = 1

    ###############################################################################
    # USER SPACE BANDWIDTH CONTROL

    [bandwidth]

    #
    # Bandwidth throttling allows giFT to have some basic control over your
    # bandwidth usage. This code operates in user space, and as a result can not
    # guarantee perfect accuracy. If you wish to use this feature, please
    # consider using a more reliable kernel space option first. As always, google
    # should be able to assist you there.
    #
    # The following configuration switches control the maximum number of bytes
    # per second allowed for the given stream direction. A setting of 0 will
    # disable throttling for that direction.
    #
    # Default: 0
    #
    downstream = 0
    upstream = 0
    gift.conf.template


    Ich hoffe ihr könnt mir weiterhelfen

    MfG Luzifer
     
  2. Anzeige

    Schau dir mal diese Kategorie an. Dort findest du bestimmt etwas.
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  3. devilz

    devilz Pro*phet
    Administrator

    Dabei seit:
    01.05.2002
    Beiträge:
    12.244
    Zustimmungen:
    0
    Ort:
    Hessen
    /me slaps Luzifer !

    # Boolean determining whether or not this file has been reviewed and is
    # complete. giFT will fail to start unless this is non-zero. This is done
    # so that we can make sure you, at the very least, read through this file.
    #
    # Default: 0
    #
    setup = 0


    WAS STEHT DA BITTE ?
     
  4. #3 Luzifer, 30.08.2004
    Luzifer

    Luzifer Schachspieler

    Dabei seit:
    09.03.2004
    Beiträge:
    540
    Zustimmungen:
    0
    Ort:
    Alpha Quadrant
    sorry habe ich übersehen. Der Fehler tritt aber immernoch auf:(
     
  5. Kane32

    Kane32 Kleiner Alternativer

    Dabei seit:
    02.04.2004
    Beiträge:
    98
    Zustimmungen:
    0
    Ort:
    Schwabmünchen, 86830
    blöde frage, aber: hast du "giftd" gestartet?
     
  6. #5 Luzifer, 30.08.2004
    Luzifer

    Luzifer Schachspieler

    Dabei seit:
    09.03.2004
    Beiträge:
    540
    Zustimmungen:
    0
    Ort:
    Alpha Quadrant
    Juhuu es geht.

    Die Lösung:

    1. gift-setup hat die config garnicht geändert.
    2. ich habs per hand geändert und dann ging es :)
     
Thema:

giFToxic läuft einfach nicht

Die Seite wird geladen...

giFToxic läuft einfach nicht - Ähnliche Themen

  1. Bashscript aus Debian6 läuft nicht auf Debian7

    Bashscript aus Debian6 läuft nicht auf Debian7: Hallo an alle, nachdem ich ein Skript von squeeze auf wheezy kopiert habe und ausführte, erschienen gleich wilde Fehlermeldungen, nach denen ich...
  2. OpenELEC 6.0.3 läuft auf dem Raspberry Pi 3

    OpenELEC 6.0.3 läuft auf dem Raspberry Pi 3: Die Multimedia-Distribution OpenELEC unterstützt in Version 6.0.3 die vor wenigen Tagen veröffentlichte dritte Ausgabe des Einplatinenrechners...
  3. PCI-Soundkarte welche mit Debian Wheezy Kernel 3.16 läuft?

    PCI-Soundkarte welche mit Debian Wheezy Kernel 3.16 läuft?: Hallo zusammen Kann mir jemand eine Soundkarte vorschlagen, welche mit dem Wheezy-backports-Kernel v3.16.x läuft? Dabei sollte die Karte im...
  4. Unterstützung für Ubuntu 15.04 läuft aus

    Unterstützung für Ubuntu 15.04 läuft aus: Neun Monate nach der Veröffentlichung endet die Unterstützung für Ubuntu 15.04 am 4. Februar. Benutzer sollten bis zu diesem Zeitpunkt auf Ubuntu...
  5. Anmeldung für LUG-Camp 2016 läuft

    Anmeldung für LUG-Camp 2016 läuft: Vom Donnerstag, den 5. Mai, bis zum Sonntag, den 8. Mai 2016, findet im badischen Bruchsal das mittlerweile 17. Treffen der Linux User Groups aus...