Add support for resolving interface from ip at startup - #109
Conversation
|
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 |
| EOF | ||
| fi | ||
|
|
||
| # Run each time as the interface can change in a container |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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.