Give IBC the ability to run TWS/Gateway with a predefined config

[rlktradewright]

There is an increasing desire amongst users to be able to run IBC in situations where the user does not have convenient (or even any) access to the target machine. Examples might be locked-down on-premises servers, cloud servers such as AWS or Azure, or containers (eg Linux or Windows containers running in Docker).

In these cases, the problem arises of how to make sure TWS or the Gateway (usually the latter, and we will assume Gateway for the remainder of this post) run with the desired configuration, which may be different from user to user and will always be different from the default as-installed configuration if only because the latter includes ReadOnlyApi = true).

This problem was referenced several times in the IBController repository (before the fork of IBC), and the general recommendation was that the user should somehow arrange for their desired configuration to be copied to the target machine or container, having first configured it to meet their needs in a local installation where they had full access. However, no specific guidance as to how best to achieve this was given, and I suspect several ingenious solutions have been invented by various users, though there has been little direct feedback on this.

Recently @charles-cooper faced this problem in Issue #10, and I'm grateful to him for the suggestion that perhaps IBC could itself do more to assist the user to achieve this. My view has always been that IBC is not a tool for configuring the Gateway (primarily because there is a large number of configuration options for which IBKR already provide an extensive configuration GUI), but I have no problem with IBC assisting with picking up a pre-defined configuration and using it when running Gateway. Thus the user would configure Gateway to meet their requirements using a local machine to which they have full access, and IBC would then be instructed to transfer the necessary configuration data to the target environment automatically.

So this is an initial post to introduce the topic, and I'll add to this when I've had time to think about it a bit. But please feel free to make any suggestions, or describe ways that you have already addressed the issue, or even submit PRs that have some bearing on it.

[charles-cooper]

So after returning to this I have had some thoughts on the matter. I think the approach I started in #10 of detecting where the ibg.xml file is located is fine. I think IBC could help abstract this by (in order of abstraction level)

1. Allowing the user to just provide the ibg.xml file and then it figures out where it needs to go and how to splice it in (rather than user-code working backwards)
2. Not needing to restart the JVM instance after injecting the new file, I guess this is an implementation detail as far as IBC is concerned
3. Using a file format which has a cleaner syntax (e.g. toml) and organization than IB's xml file, especially for commonly used options, and providing some sort of tool which converts it into the IB xml format
4. Documenting the configuration options available <-- much work but it could be a community effort

[rlktradewright]

Update:

I haven't done any work to progress this issue, due partly to lack of time, and partly because people seem to be finding ways of accomplishing what they need without assistance from IBC. And there has been no further input to this discussion.

I'll close this for now, but feel free to open it again if anyone has any further to add.

[cgd1]

@rlktradewright Firstly thank you so much for continuing to maintain this. You have saved me a lot of time!

I'm looking to build some management functionality that wraps around IBC.

This would include:

• Predefined config files
• API and GUI for IBC control

I cam across this https://github.com/erdewit/ib_insync/blob/master/ib_insync/ibcontroller.py in the project ib_sync

What are your thoughts?

[rlktradewright]

You're welcome to wrap anything you like around IBC, though I don't really know what you mean by 'API and GUI for IBC control'. I believe IBC provides enough 'hooks' to enable you to do this sort of thing (whatever it is) without modification. If you can identify particular things that are missing from IBC that would make the job easier, please raise them (preferably as separate Issues).

One example of this might be that at present, IBC only logs to stdout. I am considering the possibility of providing a way of injecting a logger mechanism that could be integrated with other logging mechanisms, such as Log4J.

And I have no opinion at all about ib_insync, apart from the indisputable fact that Ewald is an extremely capable developer, and a lot of users are very happy with his work. I don't really feel a need to follow what he's doing with IBC, or anyone else who's using it successfully in whatever way they feel fit..

So I'm not quite sure what kind of a response you're hoping for...

[subes]

Here people talk about being able to disable ibg.xml encryption via a configuration flag (not available in TWS for tws.xml as it seems). Though it seems this is not possible anymore because ibg.xml always stays encrypted for me. So I guess the only way to automate this configuration now would be to let the UI automation of IBC handle it. Maybe only for the most important settings like:

• Enable ActiveX and Socket Clients (already available via command server "ENABLEAPI")
• Locale (already set to english on startup)
• TimeZone (it seems this can be configured in jts.ini)
• Read-Only API (see flag in ibc.ini/config.ini)