Opened 14 years ago

Closed 13 years ago

#966 closed Enhancement (fixed)

[PATCH] Blocklist support for Transmission-daemon

Reported by: KyleK Owned by: charles
Priority: Normal Milestone: 1.30
Component: Daemon Version: 1.21
Severity: Normal Keywords:
Cc:

Description

The attached patch adds a command-line switch to enable or disable the blocklist functionality in transmission-daemon. The user has to manually put a blocklist file into the blocklist folder in order for it to work.

This has been requested multiple times on the Transmission forum and others (especially NAS users ask for it), I've had Transmission 1.2x running with this for a while without issues.

The diff is against the current SVN version 5910.

Attachments (1)

blocklist_switch.patch (3.4 KB) - added by KyleK 14 years ago.
Fixed a typo in the original patch file

Download all attachments as: .zip

Change History (12)

comment:1 Changed 14 years ago by mezz

Just a FYI before nobody notice it. ;-) There is a typo in this patch for '-v', which should be '-b'.

+          "  -v --blocklist          Enable blocklist\n"

comment:2 Changed 14 years ago by charles

Thank you for the patch, but it doesn't explain how the daemon is actually going to fetch the blocklist off the web in the first place...

comment:3 Changed 14 years ago by KyleK

@mezz Thank you, seems I've missed that. Patch file updated :)

@charles

I don't think that it is necessary for the daemon to fetch the blocklist automatically. The user can put the required list in the proper directory manually.

I believe that the people who use the daemon (as far as I can tell they're mostly installing Transmission on some kind of NAS) are capable of figuring this out.

Maybe, a log message to the console/logfile would help if the blockist switch is set but Transmission can't find a list file in the blocklists directory?

Changed 14 years ago by KyleK

Fixed a typo in the original patch file

comment:4 Changed 14 years ago by mezz

I don't think most of users can figure it out by themselves. Add about blocklist stuff in manpage should cover it and maybe tweak a bit in daemonUsage()'s -b line.

+          "  -b --blocklist          Enable blocklist, to get the blocklist see in transmission-daemon(1) manpage for how to fetch it.\n"

Something like that, I am sure one of you can figure out a better way.

comment:5 Changed 14 years ago by charles

@KyleK: I agree in the abstract question "should the daemon be able to use the blocklist", but to give a feature for this without any means of supplying a blocklist, doesn't make much sense IMO.

comment:6 Changed 14 years ago by charles

@KyleK: that's not to say I know what the answer is here, either... :(

comment:7 Changed 13 years ago by KyleK

I've looked at the blocklist update code in onUpdateBlocklistCB (gtk/tr-prefs.c) and more or less ported the download part for usage in daemon. I'm unclear what happens to the downloaded data when Transmission is shut down though. Is the blocklist file blocklists/level1.bin permanently updated or will the downloaded data be lost as soon as I quit Transmission?

My idea is to implement a check for blocklists/level1.bin before tr_initFull. If the file is not present, it will be downloaded. Will I have to explicitly place it in blocklists/ or does a call to tr_blocklistSetContent() suffice? (The problem with most of these calls is that they expect a session handle, but I don't have one yet).

comment:8 Changed 13 years ago by charles

@KyleK: I've been thinking about the response in the forums to your suggestion -- daemon users don't seem to mind getting their hands a little dirty to set up the blocklist. I think this ticket and #984 and #989 all dovetail together.

What I think we ought to do is have Transmission scan the `blocklists' directory in tr_sessionInitFull() for files not ending in ".bin". For every $filename of that sort, if it's newer than $filename.bin or $filename.bin doesn't exist, Transmission should generate it. Then, each .bin file should be used for the blocklist.

This would let users auto-update the blocklist just by running wget;gunzip in a cron job.

This would let daemon users add/remove blocklists by moving files around

This would let users add custom blocklists of their own without losing their changes every time the main blocklist updates.

What do you think?

comment:9 Changed 13 years ago by KyleK

  • Type changed from Bug to Enhancement

I would say make this in 2 steps:

  1. just provide the ability to use the blocklist for daemon users. This might not even require the additional command-line parameter from my patch. Just enable blocklist by default (like it is currently done for the CLI). If it doesn't find the level1.bin, it won't be activated anyway.

You can (for now) add a paragraph about the level1.bin in the man-file

  1. Step 2 would be some form of automation. Either let the user do the periodic updates himself, or implement some simple file date detection: if it's older than 1/2 weeks, update it.

Letting Transmission generate the blocklist seems _a lot_ of work, especially since the Bluetack IP range list is already in the desired format.

I always take uTorrent as reference. It doesn't support the user in any way when it comes to the IPFilter. The user has to find a blocklist file himself and place it in the application's data dir (which is very well hidden under Windows). A mention of this in the helpfile and the NEWS/ChangeLog should suffice for now.

comment:10 Changed 13 years ago by charles

  • Milestone changed from None Set to 1.30
  • Owner changed from SoftwareElves to charles
  • Status changed from new to assigned

comment:11 Changed 13 years ago by charles

  • Resolution set to fixed
  • Status changed from assigned to closed

fixed in r6146

Note: See TracTickets for help on using tickets.