Skip to content

Add support for resolving interface from ip at startup - #109

Open
lugoues wants to merge 1 commit into
qbittorrent:mainfrom
lugoues:main
Open

Add support for resolving interface from ip at startup#109
lugoues wants to merge 1 commit into
qbittorrent:mainfrom
lugoues:main

Conversation

@lugoues

@lugoues lugoues commented Jul 22, 2026

Copy link
Copy Markdown

This assigns the proper interface based on the supplied ip address. This is helpful when using static networking as you know where the traffic needs to go and prevents having to update the config after a restart.

@lugoues

lugoues commented Jul 22, 2026

Copy link
Copy Markdown
Author

One thing I'd like to do is implement something this for more, if not all, the config fields. It would be nice to be able to configure the majority of things from env vars at launch instead of manually having to set things. I'm not sure how y'all feel about that though

Comment thread entrypoint.sh
EOF
fi

# Run each time as the interface can change in a container

@Chocobo1 Chocobo1 Jul 25, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Run each time as the interface can change in a container

This won't happen because the config file above is only applied for the very first qbt startup, i.e. when there are no existing qbt config file. Subsequent qbt startups will not modify it.

I don't think modifying entrypoint.sh will achieve your goal. It would be best to supply your own qbt config file or script which will run before starting up qbt container.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does work though. The "does config" exist check is on line 34 which is the mechanism you are speaking of. This executes a sed replace outside of that block which will update the existing config every restart.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does work though.

Right, I'm mistaken.
However, it doesn't really guarantee the sed call below will always succeed since the above default config won't be applied when there is an existing config and the config may not have a Session\Interface entry in it.

@Chocobo1 Chocobo1 Jul 26, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll leave the implementation details aside and ask something else.

Is setting the interface to some specific IP really a common operation for the users? Why the default value won't work? It should be listening on all available interfaces IIRC.
I mean, I would really like to keep the tuning knobs minimal.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it doesn't really guarantee ..
true, it could be more robust

Is setting the interface to some specific IP really a common operation for the users
When using static networking in a container environment it kinda is. I can assign a static ip but I cannot guarantee the interface that will be assigned.

It should be listening on all available interfaces IIRC
If one is using a VPN to isolate traffic, then they must bind to only that interface or risk that traffic leaking. It's the same thing outside of a container, it's why the config option exists.

In my case the container is created with 3 interfaces, only one of which I want qbit to actually communicate on. It communicating on other interfaces would allow it to potentially escape VPN isolation.

But I understand the desire for less knobs, and maybe my use case is unique. I also prefer to have as much configured up front by orchestration and minimize the manual knobs by the user in the UI - this allows the container to be treated as the cattle that they are.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants