Can this be swapped in to the MC 28 container or does a new one have to be created?
Not really sure why it does not work. Turning on privileged mode also does not make it work (I know chrome/chromium does use features for sandboxing by default that are not available to containers unless you run it in priviledged mode, or disable sandboxing). But firefox started without any additional flags, just not threw mc. Same thing with chromium (once privileged mode was enabled). While I donŽt know how to make it work youŽll be out of luck either way.
Currently working on a new container image too. Though, not for this reason. I want to get away from the current baseimage to just using debian to allow for more customization (as in having the ability to put jriver specific features into the web gui) and also better arm support. Will be some time until that is ready. No timeline whatsoever. Im not working for JRiver, so it gets worked on whenever I have time and feel like it. Hence developement is somewhat slow.
Images arenŽt really ready, yet. But if youŽre curious all the work is in those three repositories
-
https://gitlab.com/shiomax/jrivermc-docker-next - The actual image
-
https://gitlab.com/shiomax/jrivermc-docker-gui - A Vue JS Web GUI
-
https://gitlab.com/shiomax/jrivermc-docker-api - C# Backend for Authentication and to be able to run code in the container savely instead of just being able to remote control MC
It does build, but there may be bugs here and there and many things are not done. Still need to work on
- Actually building the images automatically on amd64, armhf and arm64, like now but likely gonna need either 3 systems doing it or 3 vms and emulate arm, first wanted to use docker buildx, but it only builds images, it wonŽt run them (you cant even save the images locally that donŽt match your processor architecture). I do not think buildx is very helpful here after having tried it. Just blindly pushing images to a repo and hope for the best isnŽt very useful.
- Some automated testing, probably even more important now as I can no longer rely on the baseimage to work.
- Finish up the gui
- Figure out how to change resolution at runtime. The image is no longer using x11vnc, but tigervnc instead. I found it to be more responsive and supposedly it allows for dynamic resolution updates. But I donŽt know how to do that just yet. The plan is to ditch the environment variables for resolution and make it configureable in the webgui at runtime.
- Probably, need to work on User management some more (creating the user jriver will run as, adding groups, etc.)
- As first jriver integration im gonna do just the activation thing with .mjr files. Since, itŽs a bit complicated right now to get that done. WonŽt plan anything else for now.
- A "stateless mode" would be cool imo. Probably, not very helpful for most people. But the plan is to on startup copy the .jriver folder into /tmp and use that, if stateless mode is enabled. So you can set up a test environment that is effectively immutable (just make your media folders read only). Would be useful for developing stuff like pymcws or anything else really that tries to integrate with jriver. ItŽs not that hard to do and I think it would be nice to have, even though, as I said, most people wonŽt care about it.
- Refresh Tokens that I can store in local storage, currently it stores username and password in process only, so when you refresh the page or navigate to another url in the address bar you are logged out and get redirected to login. And it also sends username, password again whenever your current token expired and you want to do something that needs authentication, so itŽs not great either way.
Note that authentication is now handled by the C# api. I wrote a plugin for websockify to accept the tokens it generates. However, there is no form of authentication for direct VNC connections, but only for the webui and websockify. So, by default it should reject direct VNC connections that do not come from localhost. Something that I also still did not bother testing because well.. look at the list above. Right now it still may accept them, not sure. Either way, it is extremely likely that you wonŽt be able to use direct VNC connections with the new images anymore.
Most likely, when this is somewhat reasonably ready, ill keep the old image(s) in shiomax/jrivermcxx and create another one shiomax/jrivermc-next-xx. Kind of beta release thing. At some point the plan ofc is to replace it. But it will be sometime until then.
