Changes between Version 3 and Version 4 of HeadlessUsageGentoo


Ignore:
Timestamp:
Dec 26, 2008, 6:20:21 PM (12 years ago)
Author:
rb07
Comment:

Changes to configuration and script to addapt them to Tr 1.42

Legend:

Unmodified
Added
Removed
Modified
  • HeadlessUsageGentoo

    v3 v4  
    6969# (machines/networks allowed/denied to control transmission -- comma separated)
    7070# TR_ACL="+127.0.0.1"
     71# or (for versions 1.4x -- different syntax)
     72# TR_ACL="127.0.0.1"
    7173
    7274# Enable use of block lists
     
    120122NAME=transmission-daemon
    121123declare -a OPTIONS
    122 OPTIONS+=" -a ${TR_ACL:=+127.0.0.1}"
     124OPTIONS+=" -a ${TR_ACL:=127.0.0.1}"
    123125if [ -z "$TR_BLOCK" -o "$TR_BLOCK" = "no" ]; then
    124126   OPTIONS+=" -B"
     
    178180      --exec /usr/bin/transmission-daemon -- ${OPTIONS[@]} \
    179181   || { eerror $E_MSG; eend 1; return 1; }
    180    sleep 1
     182   sleep 2
    181183   transmission-remote ${CTL_PORT:-9091} \
    182184      ${REMOTE_PASS:+-n $REMOTE_USER:$REMOTE_PASS} \
     
    233235
    234236The procedure is not difficult but involves more work: create a local emerge repository structure, copy the contents from the current transmission branch, inside your local copy duplicate the file transmission-1.33.ebuild into transmission-1.34.ebuild, change the configuration in /etc/make.conf adding 'PORTDIR_OVERLAY="/usr/local/portage"', rebuild the package (2 ebuild commands), and emerge will show it as an option.
     237----
     238Notes:
     239
     2401. With version 1.42, the change from ACL to whitelist prompted the change above of dropping the "+"; leaving it causes a failure on the script when transmission-remote tries to change some parameters and is not authorized to do so (the whitelist is probably empty, not even 127.0.0.1).
     241
     2422. As reported on the forum, the sleep on the script was increased to 2 seconds to avoid a communication failure between transmission-remote and the daemon.  I observed this problem, with twice the torrents reported before in the forum, so the daemon startup might be slower the more torrents it has and the problem may persist.