Manage factorio version through instance settings

[Danielv123]

trafficstars

The instance settings page has a new element for selecting the factorio version from a list scraped from factorio.com. Clusterio downloads the selected version when starting the instance. There is also a control API to manually download a factorio version from a custom URL.

Before this is merged I want to:

• [ ] find a more proper way to target the version field in the ConfigTree
• [x] Automatically download the latest version from the website when starting an instance with "latest"
• [x] Allow selecting versions that exist on disk but cannot be downloaded
• [ ] Add tests - this changes core communication stuff

[Hornwitser]

Is this really the way you want to manage Factorio installations?

• Downloading and installing factorio in the init() method of a class
• Adding 15 packages to get an HTML5 parser when it doesn't solve the problem any better than a regexp.
• No support for Windows whatsoever.
• Adding features to lib/link in the same commit as everything else, and leaving the tests to be put in later.
• No protection against race conditions, combined with the start all policy of start everything at the same time 50 instances will create 50 simultaneous requests to list the versions, followed by 50 simultaneous downloads of the Factorio installation. Then it'll unpack the archive 50 times to the same location and so on.
• Even if the above is corrected, if you have 10 physical servers behind the same IP you'll still see 10 simultaneous requests and downloads from the same IP.
• No way to delete Factorio installations you don't need any more.
• No way to provide your own Factorio installation.
• Using experimental versions as "latest".
• Although not explicitly written in the style guide, single function exports are not a thing in this codebase (with the exception of is_deep_strict_equal which was added to avoid pulling in a dependency server side and webpack configs).
• Files don't follow naming convention (no camelCase files).
• Use of self recursion that makes the logic difficult to understand and test.
• Adding !.jsx to the gitignore instead of removing the obviously conflicting Factorio rule which shouldn't be there at all.
• Making a request to factorio.com every time the instance config is displayed or revert is clicked.
• No ctl interface.
• Copy paste of LineSplitter when there already exists one in lib.
• Copy paste errors made when copying Factorio download code from installer (wrong temp directory name, logging to the wrong location, logging error output to verbose)
• Random whitespace changes, in lib/factorio/server.js moving ;.
• Creating factorioFolderContents variable without using it for anything else.
• Making every config entry named "version" render as a Factorio version selector regardless of what group it belongs to.

It feels like a hodgepodge. I haven't been in the mood for programming and this is--not helping. There are some deep questions in here that need a good answer.

1. Customizing rendering of config entries in web UI. Whatever core does plugins should be able to do too. In terms of customized controls I had thought about having the nice ones on top (like the assign instance button) and leaving the gritty details in the config. Mostly because it makes it more consistent with editing the config via ctl. And potentially via editing the config file if the format is changed.

2. Allowing uploads of Factorio versions, or as implemented here providing an arbitrary download link for where to get Factorio from creates remote code execution by design. And that is something I don't like. It shouldn't be that if you join your desktop computer to help out hosting a cluster that it can suddenly just be remotely rooted by anyone with the right permissions on the master server. The default should be that you need to exploit a vulnerability to do that. Obviously we should allow third party sources, but that should be an opt-in that you understand the implication of when you turn it on.

3. Do we want slaves to get Factorio from the master server? It sort of ties in to the previous issue in that you get RCE by design since the files on the master server could be altered by the admin of the server. But it makes it much simpler to retrieve the versions of Factorio available by the master. (Since adding a version would be a separate action elsewhere.)

[Danielv123]

It is a hodgepodge. There is a reason this is a draft PR, because its nowhere near ready to merge. I just wanted to have it in my branch. I don't think we have really discussed how this is to be done at all.

Regarding the factorio API issues, I was planning to add simple rate limiting. Downloading factorio waits if the current version is already downloading, latest versions cache refreshes once an hour or somthing.

Regarding the config entry in the UI - its obviously wrong as is. I just wanted to put it somewhere, the component is OK with being moved. I agree putting version control on top makes a lot of sense, I also want a way to do batch changes of versions from the instance list. That was more writing though, hence not included.

2. is fair. I wanted a way to pull older archive versions of factorio that aren't available from official sources, but it should be hidden behind some flag or something.

3. I don't want instances to get factorio through the master server. Currently the download url is taken from there, but it would be blocked by the same slave flag. I prefer direct download to the instances, just like we have always done.

I wrote this without adding tests because its obvious its not going in before major refactoring of basically all of it, just wanted some discussion. Don't stress the reviews for it, we'll do a more proper review thing once everyone agrees with how it should work and stuff.