PBH-BTN / PeerBanHelper

BT 反吸血工具 - 自动封禁不受欢迎、吸血和异常的 BT 客户端,并支持自定义规则。PeerId黑名单/UserAgent黑名单/IP CIDR/假进度/超量下载/进度回退/多播追猎/连锁封禁/伪装检测 支持 qBittorrent/Transmission/Deluge/BiglyBT/Vuze(Azureus)/BitComet
GNU General Public License v3.0
2.44k stars 80 forks source link

[Other] Transmission #683

Open Anuskuss opened 3 days ago

Anuskuss commented 3 days ago

问题描述 - Issue Description

I understand that after #382 Transmission is considered deprecated and when compared to something like v6.0.2 the latest version doesn't do anything. But is it really that much of a support burden? If I set up my Transmission to restart once a day (so it can get the latest blocklist) that would work perfectly fine for me. I know that means that some blocked peers will continue downloading (unless you manually merge https://github.com/transmission/transmission/pull/7167) but I think that's better than nothing. And while the advanced anti-leeching features are great (hopefully https://github.com/transmission/transmission/pull/7172 will help in that regard) I don't really need them. So can you please restore the ability to populate the blocklist and just let the user know that they have to restart Transmission manually?

额外信息 - Addition Information

No response

检查清单 - Check list

Ghost-chu commented 3 days ago

The code for the Transmission feature is still in the PeerBanHelper codebase, but it has been disabled and not updated for more than six months due to the issues we mentioned, and we don't expect to maintain support for Transmission in the future. However, you can indeed re-enable it manually before it is completely removed.

You can follow the documentation to manually re-enable and manually add the configuration (it is disabled in the WebUI so edit the file is necessary).

https://pbh-btn.github.io/pbh-docs/docs/downloader/Transmission#%E9%87%8D%E5%90%AF%E7%94%A8%E8%A2%AB%E7%A6%81%E7%94%A8%E7%9A%84-transmission

I'd love to restore active support for Transmission, but it's going to be hard to do that until Transmission makes changes.

Anuskuss commented 3 days ago

Okay thanks for the link, that indeed made it work. And it also populated blocklist-url although I'm wondering how often that will happen?

So the warning says

Warning: Use Transmission Adapter is discourage. Frequent starting and stopping of torrents on seeds that are often subject to bans can result in frequent updates to the tracker server, indirectly triggering DoS attacks. This increases the load on the tracker server and may lead to your IP address being banned by the tracker. We encourage you to migrate to other downloaders whenever possible.

How can I disable this "Frequent starting and stopping" (if it's not already disabled) so I can just restart Transmission once a day myself? (I also found a bug when ignore-private is set to true but since you don't officially support Transmission anymore I'm not going to ask you for a fix.)

Ghost-chu commented 3 days ago

Okay thanks for the link, that indeed made it work. And it also populated blocklist-url although I'm wondering how often that will happen?

So the warning says

Warning: Use Transmission Adapter is discourage. Frequent starting and stopping of torrents on seeds that are often subject to bans can result in frequent updates to the tracker server, indirectly triggering DoS attacks. This increases the load on the tracker server and may lead to your IP address being banned by the tracker. We encourage you to migrate to other downloaders whenever possible.

How can I disable this "Frequent starting and stopping" (if it's not already disabled) so I can just restart Transmission once a day myself? (I also found a bug when ignore-private is set to true but since you don't officially support Transmission anymore I'm not going to ask you for a fix.)

This is actually one of the problems we're having, PeerBanHelper is designed to disconnect immediately after a block, and if it doesn't disconnect, it tries again and again. Each repeated ban is also logged as a banning operation thus polluting the statistics. I would suggest that you could use BTN-Collected-Rules as we are constantly updating it with data from BTN and it works just fine. Transmission 3.0+ should read this rule set without any problems.

Of course the best option is always to switch to another supported downloader.

Anuskuss commented 3 days ago

I would suggest that you could use BTN-Collected-Rules

This seems like a fair compromise but then you're really forced to restart Transmission yourself. Would you consider undeprecating Transmission and removing the "stop-and-start" workaround once https://github.com/transmission/transmission/pull/7167 is merged? Or maybe add a restart_torrent option in the config that defaults to true which a user then can manually disable? I already build my own Transmission with a few unmerged patches so it would be easy to apply 7167 myself. I know that Transmission has been stuck in limbo for a few months but I really think we can make this work.

Of course the best option is always to switch to another supported downloader.

I tested the big 3 (Transmission, qBittorrent, Deluge) many many years ago and for me the clear winner was Transmission for servers (low CPU/memory usage, better headless) and qBittorrent for desktops (more features, better speeds). Back then qbittorrent-nox was quite bad and you didn't have have a good remote GUI but maybe that has improved since then? Anyway I have hundreds of torrents in Transmission and I really don't wanna switch unless I have to. I'll consider qBittorrent once Transmission officially dies but until then I hope we can make this work. The dev of 7167 said that blocklist-update will trigger a blocklist refresh and 7167 will let you kick blocked peers so I think it's possible to make Transmission a first-class citizen again.

P.S. Is there any way to change the loglevel? My systemd service/journal is flooded with Java nonsense and I would really like to only see warnings and errors there (the rest can go into /etc/peerbanhelper/logs/latest.log). I'm doing java -jar PeerBanHelper.jar | grep --line-buffered -v '\(/\||-\)INFO\|^ ' but there's got to be a better way.

Anuskuss commented 3 days ago

Also don't forget about the ability to just straight up block peers through iptables which means that you wouldn't have to use Transmission's blocklist at all (the rules apply immediately). Is this already trackable without running into the "repeated ban is also logged as a banning operation" situation?

Ghost-chu commented 2 days ago

I would suggest that you could use BTN-Collected-Rules

This seems like a fair compromise but then you're really forced to restart Transmission yourself. Would you consider undeprecating Transmission and removing the "stop-and-start" workaround once transmission/transmission#7167 is merged? Or maybe add a restart_torrent option in the config that defaults to true which a user then can manually disable? I already build my own Transmission with a few unmerged patches so it would be easy to apply 7167 myself. I know that Transmission has been stuck in limbo for a few months but I really think we can make this work.

Of course the best option is always to switch to another supported downloader.

I tested the big 3 (Transmission, qBittorrent, Deluge) many many years ago and for me the clear winner was Transmission for servers (low CPU/memory usage, better headless) and qBittorrent for desktops (more features, better speeds). Back then qbittorrent-nox was quite bad and you didn't have have a good remote GUI but maybe that has improved since then? Anyway I have hundreds of torrents in Transmission and I really don't wanna switch unless I have to. I'll consider qBittorrent once Transmission officially dies but until then I hope we can make this work. The dev of 7167 said that blocklist-update will trigger a blocklist refresh and 7167 will let you kick blocked peers so I think it's possible to make Transmission a first-class citizen again.

P.S. Is there any way to change the loglevel? My systemd service/journal is flooded with Java nonsense and I would really like to only see warnings and errors there (the rest can go into /etc/peerbanhelper/logs/latest.log). I'm doing java -jar PeerBanHelper.jar | grep --line-buffered -v '\(/\||-\)INFO\|^ ' but there's got to be a better way.

Hi I want to know which one deploy method that you have to use to setup PBH? The .sh script or .deb package or something else?

Ghost-chu commented 2 days ago

Also don't forget about the ability to just straight up block peers through iptables which means that you wouldn't have to use Transmission's blocklist at all (the rules apply immediately). Is this already trackable without running into the "repeated ban is also logged as a banning operation" situation?

This works for Linux systems, but there doesn't seem to be a better way for Windows. I've tried operating the firewall but it doesn't work well, especially since sometimes the number of IPs blocked reaches the upper limit of a single rule.

Another important reason is that I don't think I should have PeerBanHelper running under root or Adninistrator privilege levels, whereas operating the firewall obviously requires elevated privileges.

Anuskuss commented 2 days ago

Hi I want to know which one deploy method that you have to use to setup PBH? The .sh script or .deb package or something else?

The .deb package.

This works for Linux systems, but there doesn't seem to be a better way for Windows.

I don't know about Windows but that's why I was asking for a restart_torrent option. So the user can decide for themself if they want PBH to restart the torrent, or either restart the client or use a firewall instead.

Another important reason is that I don't think I should have PeerBanHelper running under root

In Linux land it already runs as user peerbanhelper. For use with iptables you'd also need at least CAP_NET_RAW and CAP_NET_ADMIN (haven't tested).

Ghost-chu commented 2 days ago

The .deb package.

@Gaojianli Can you redirect stdout/stderr to a file in /var/log for .deb packaging?

I don't know about Windows but that's why I was asking for a restart_torrent option. So the user can decide for themself if they want PBH to restart the torrent, or either restart the client or use a firewall instead.

If Transmission can merge that PR, we can actually not restart Torrent but just update the blocklist url.

Ghost-chu commented 2 days ago

For what it's worth, our community members have created a tool that can proxy the Transmission API and the System Firewall API and convert them to the qBittorrent API and provide it to PeerBanHelper or any other program that needs the qBittorrent API (although it's not yet complete) if you're interested.You can check it out at: https://github.com/azicen/transmission-proxy

Disclaimer: This project is not affiliated with PeerBanHelper, PBH-BTN or me.

Anuskuss commented 2 days ago

Can you redirect stdout/stderr to a file in /var/log for .deb packaging?

The full log is already being recorded in /etc/peerbanhelper/logs/latest.log so the only thing that would make sense it to set StandardOutput=null. But I need a filtered log in systemd so I can quickly check for problems (e.g. systemctl status peerbanhelper).

If Transmission can merge that PR, we can actually not restart Torrent but just update the blocklist url.

Transmission could merge that PR but it's release cycle is currently stuck. So the merged PR could sit in master for months and nobody would benefit. A restart_torrent option would fix it today but I guess the code would be dead once Transmission 4.0.7/4.1 releases so I understand why you're maybe opposed to that. It's your call after all.

Anuskuss commented 2 days ago

our community members have created a tool that can proxy the Transmission API and the System Firewall API and convert them to the qBittorrent API

That sounds really interesting but I hope we can make it work with the tools we have available now.

Anuskuss commented 1 day ago

I saw that you disabled the logs completely now but I still wanna see them when I do systemctl status peerbanhelper so instead I just turned on the loglevel (#698). There are still a bunch of useless lines like

22:25:01,641 |-INFO in ch.qos.logback.classic.LoggerContext[default] - This is logback-classic version 1.5.12

but it's better than before.

Edit: The loglevels seem a bit arbitrary, no? Because why aren't these INFOs?


Nov 06 22:53:24 java[4097459]: [22:53:24] [virtual-13334/ERROR]: The Peer being blocked is in the block list: BanMetadata(context=com.ghostchu.peerbanhelper.module.impl.rule.IPBlackRuleList, banAt=1730930004819, unbanAt=1731189204819, banForDisconnect=false, rule=TranslationComponent{key='all-in-one', params=[]}, description=TranslationComponent{key='MODULE_IBL_MATCH_IP_RULE', params=[all-in-one, ###]})
Nov 06 22:53:24 java[4097459]: [22:53:24] [virtual-13334/WARN]: [Repair] PeerBanHelper scheduled full banlist re-sync with downloaders