search

SynoCommunity / spksrc

Cross compilation framework to create native packages for the Synology's NAS
https://synocommunity.com
Other
3.04k stars 1.24k forks source link

Transmission port change is not reflected in DSM #3319

Closed Magissia closed 6 years ago

Magissia commented 6 years ago

For new Package Requests, see the guidelines

Setup

_Package Name:_Transmission _Package Version:_2.93-14

_NAS Model:_DS918+ _NAS Architecture:_x86_64 _DSM version:_6.1.6-15266 Update 1

Expected behavior

Tell us what should happen Changing Transmission's listening port should reflect in DSM's firewall rules when using package instead of manual port

Actual behavior

Tell us what happens instead Default transmission port is always reported

Steps to reproduce

_1._Open Transmission settings _2._Change listening port _3._Open DSM firewall config _4._Add new rule for Transmission

OR

_1._Ensure Transmission is not running _2._Change listening port in settings.json _3._Start Transmission from package center _4._DSM asks if we want to whitelist inbound connection to Transmission on port 9091

Package log

Check Package Center or /usr/local/{package}/var/

transmission_install.log :

Wed Apr 25 01:32:11 CEST 2018
===> Step preinst. USER=transmission GROUP=sc-download SHARE_PATH=/volume1/downloads
Invoke service_preinst
Wed Apr 25 01:32:11 CEST 2018
===> Step postinst. USER=transmission GROUP=sc-download SHARE_PATH=/volume1/downloads
Installing service configuration /var/packages/transmission/conf/transmission.sc
Creating group sc-download
Group Name: [sc-download]
Group Type: [AUTH_LOCAL]
Group ID:   [65536]
Group Members: 
0:[sc-transmission]
Configuring /volume1/downloads
Granting 'sc-download' group permissions on /volume1/downloads
ACL version: 1 
Archive: has_ACL,is_support_ACL 
Owner: [root(user)] 
--------------------- 
     [0] group:administrators:allow:rwxpdDaARWc--:fd--  (level:0)
     [1] group:sc-download:allow:rwxpdDaARWcC-:fd--  (level:0)
Invoke service_postinst

transmission.log

Sun May 13 16:21:43 CEST 2018
Starting transmission command /volume1/@appstore/transmission/bin/transmission-daemon -g /volume1/@appstore/transmission/var/ -x /volume1/@appstore/transmission/var/transmission.pid -e /volume1/@appstore/transmission/var/transmission.log 
[2018-05-13 16:21:44.752] Transmission 2.93 (3c5870d4f5) started (session.c:740)
[2018-05-13 16:21:44.752] RPC Server Adding address to whitelist: 127.0.0.1 (rpc-server.c:971)
[2018-05-13 16:21:44.752] RPC Server Serving RPC and Web requests on port 127.0.0.1:9191/transmission/ (rpc-server.c:1213)
[2018-05-13 16:21:44.752] RPC Server Password required (rpc-server.c:1220)
[2018-05-13 16:21:44.752] UDP Failed to set receive buffer: requested 4194304, got 425984 (tr-udp.c:84)
[2018-05-13 16:21:44.752] UDP Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf (tr-udp.c:89)
[2018-05-13 16:21:44.752] UDP Failed to set send buffer: requested 1048576, got 425984 (tr-udp.c:95)
[2018-05-13 16:21:44.752] UDP Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf (tr-udp.c:100)
[2018-05-13 16:21:44.752] UDP Failed to set receive buffer: requested 4194304, got 425984 (tr-udp.c:84)
[2018-05-13 16:21:44.753] UDP Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf (tr-udp.c:89)
[2018-05-13 16:21:44.753] UDP Failed to set send buffer: requested 1048576, got 425984 (tr-udp.c:95)
[2018-05-13 16:21:44.753] UDP Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf (tr-udp.c:100)
[2018-05-13 16:21:44.753] DHT Reusing old id (tr-dht.c:307)
[2018-05-13 16:21:44.753] DHT Bootstrapping from 68 IPv4 nodes (tr-dht.c:156)
[2018-05-13 16:21:44.753] DHT Bootstrapping from 7 IPv6 nodes (tr-dht.c:159)
[2018-05-13 16:21:44.753] Using settings from "/volume1/@appstore/transmission/var/" (daemon.c:528)
[2018-05-13 16:21:44.753] Saved "/volume1/@appstore/transmission/var/settings.json" (variant.c:1266)
[2018-05-13 16:21:44.753] Saved pidfile "/volume1/@appstore/transmission/var/transmission.pid" (daemon.c:543)
[2018-05-13 16:21:44.753] transmission-daemon requiring authentication (daemon.c:554)
[2018-05-13 16:21:44.753] Port Forwarding (NAT-PMP) initnatpmp succeeded (0) (natpmp.c:70)
[2018-05-13 16:21:44.753] Port Forwarding (NAT-PMP) sendpublicaddressrequest succeeded (2) (natpmp.c:70)
[2018-05-13 16:21:44.753] Port Forwarding (UPnP) Found Internet Gateway Device "http://192.168.170.1:50684/ctl/IPConn" (upnp.c:227)
[2018-05-13 16:21:44.753] Port Forwarding (UPnP) Local Address is "192.168.170.11" (upnp.c:229)
[2018-05-13 16:21:44.753] Port Forwarding (UPnP) Port forwarding through "http://192.168.170.1:50684/ctl/IPConn", service "urn:schemas-upnp-org:service:WANIPConnection:1". (local address: 192.168.170.11:51413) (upnp.c:304)
[2018-05-13 16:21:44.753] Port Forwarding (UPnP) Port forwarding successful! (upnp.c:307)
[2018-05-13 16:21:44.753] Port Forwarding State changed from "Not forwarded" to "Forwarded" (port-forwarding.c:92)

Other logs

E.g. /var/log/messages or /var/log/synopkg.log

Insert log here
Magissia commented 6 years ago

Proposed solution idea : Make a DSM specific config panel that will edit both settings.json and /@appstore/transmission/app/config port the same time, stopping transmission if running before changes, restart it after.

In case port is changed from transmission, when transmission stops, check if port changed in settings.json, if changed, update appropriate file accordingly.

BenjV commented 6 years ago

No that will not work. DSM assigns a port to an application and uses that setting in different parts of the package management system. DSM is simply not designed to change ports after installation time.

Why would you even want to change the port?

Magissia commented 6 years ago

Because IPv6 is not available everywhere and that port may be taken by something else on NAT already.

DSM correctly reflects changes of ports for DSM web GUI in the firewall when changed, same for DownloadStation when changing default after it was installed.

ymartin59 commented 6 years ago

To avoid package design complexity and keep usage quite easy, ports are set once in package and documented: https://github.com/SynoCommunity/spksrc/wiki/SynoCommunity-Used-Ports

If you are interested in switching a package port, I recommend you to rebuild it from spksrc after changing SERVICE_PORT value in Makefile.

You may also propose a pull request with implementation of your port switch concept... I think it may be possible to provide it as generic support so that most packages can take benefits from it.

Magissia commented 6 years ago

I will try to study what Synology has done with DownloadStation then.

BenjV commented 6 years ago

Give it a go!

DownloadStation uses a elaborate set of scripts to do so and has its own gui interface which can steer DSM. To accomplice that you should add functionality to the application itself to make changes to DSM. Transmission must have functionality that can call a script of a program to make changes to DSM when you change the port in transmission. Or you must make an extra application with a gui so you can change the port in the different places. A package cannot do that, because it is only run once during the installation of the package.

ymartin59 commented 6 years ago

@BenjV A quick option may be to "copy" application port from configuration file (or DB) to DSM thanks to a script hook service_prestart at service startup... So we can document that user has to restart DSM service after changing port in application.

BenjV commented 6 years ago

It may be a possibility, but the real question is why bother.

The standard ports used for packages do not conflict with each other and so everything works. There is no real need to change a port. If you let users change them, then they will do so and as a result create conflicts. And there is a good change that seeing the increase security awareness of Synology that in the future the port will be tighter integrated in DSM security/firewall etc.

Adding this functionality will also result in a lot of silly issue's here because lots of people have no idea what they are doing. We have seen how difficult the changes in the permissions are to understand by lots of people and how many pointless issue's it has created.

ymartin59 commented 6 years ago

@BenjV I agree with you - and we cannot take care for users system security typically when ports are opened from internet. To notice that when a package declares its listening ports, DSM already checks there is no conflict on system with others. I guess it is possible for a script to report same error in startup log. Another option to change port, is to do firewall NATing either on network equipment like router or inside DSM itself (if available but as a Linux system, I guess it is)

ymartin59 commented 6 years ago

I find it worth to write a FAQ in wiki about it...

Safihre commented 6 years ago

Maybe indeed good to note in the Wiki that it can't be changed. :) I agree with @BenjV that there's just no need to implement a fancy way to change the ports.

Magissia commented 6 years ago

"There is no real need to change a port." IPv4 is a real reason to change port, you won't be able to run multiple instances of Transmission over the same port on your router, using upnp is out of the game if you care about security. Let's not assume people will only have one Synology machine on their network, they may have other machines that may run Transmission too, because it's just less costly to let the machine that should store the data do the actual download instead of wasting CPU cycles downloading from one to store on the other.

Ports issues are different from user permission issues from people that are too selfish to understand a system can a will use multiple users sessions, let's not mix them.

Please do write in the wiki that if the port is changed, it won't reflect in DSM at this time, the service_prestart idea seems to be a good one and I will dig there, it would mean the service would have to be restarted to reflect the change, but it's cleaner that hard coded ports in a world where ISP are lagging the IPv6 train.

BenjV commented 6 years ago

It is a very silly idea to have more then one Nas running transmission.

Lots of issue will arrive from people that choose ports that conflict with other packages and to accommondate something almost nobody needs, is not the right way to go.