It would be awesome if you folks can maintain a docker similar to the linuxserver/mysql-workbench image but with firefox instead (with the same awesome automation you folks have on updating images whenever firefox is updated, or your base image is, etc). We took the linuxserver/baseimage-rdesktop-web image which the same image the mysql-workbench one is based on, and locally updated the Dockerfile to contain the following run and it works:
echo "**** install packages ****" && \
add-apt-repository ppa:mozillateam/firefox-next -y && \
apt-get update && \
apt-get install -y \
firefox && \
echo "**** cleanup ****" && \
apt-get clean && \
rm -rf \
And in the root/defaults/autostart file use firefox as the command
The use case for us is that we want to use it to supply ephemeral web GUI access to internal web tools but we don’t want to open it up to every end user’s web browser directly. So instead, we are booting up a docker with this firefox view inside, then from the end user’s machine they open up a webpage which happens to run firefox inside the view and then go to the internal web tools from there. This way, we can put the network/firewall restrictions on our internal web tools to only allow from the docker and nothing else directly. It also helps with not having to worry about different browser versions, different extensions/plugins that may be installed, etc on the end users browsers directly for our web tools.
We actually have an image with chromium instead of Firefox for a similar purpose. Our Jenkins ci uses it to take screenshots of the guis while testing the newly built images.
Here it is: GitHub - linuxserver/docker-tester: internal tool used to test containers in a desktop env
Exciting! Is that image published onto docker hub? We couldn’t find it there. Tried linuxserver/tester, linuxserver/docker-test but it’s not there. Is it perhaps published under a different name?
If it is not published up there, is it possible to do so?
On docker hub, it’s published at our lsiodev endpoint,
lsiodev/tester (along with our other internal dev images). However on ghcr (GitHub’s registry), it’s at
ghcr.io/linuxserver/tester, which is the recommended registry due to no rate limits.
Great, thanks for the tip!
Unfortunately, it has the same problem we have seen with chrome within this environment where lots of web UI cannot be displayed because it will die with a “Error code: SIGABRT” in chrome. In fact, when we did the install manually before, we actually went to chrome first and saw that, so then tried firefox after and firefox doesn’t have these issue on the same pages. Try something like cnn.com for a random example of it dying.
Do you folks not run into that internally when you use this? Any idea what you are doing to get around this?
No, not really, it works for our purposes taking screenshots of the guis of images our jenkins builds: CI Results
Each docker image repo has a badge that shows
CI Pass and links to those result pages.
The only issue we have is with the delay we set for screenshotting, where it takes the screenshot prematurely, before the arm32 and aarch64 containers can serve the pages (they’re run under qemu and are much slower than the x86_64 counterparts during the tests)
So any chance of you folks maintaining a firefox one automatically?
No benefit to us really.
You could use a docker mod to install firefox on the rdesktop-web baseimage, or you can fork the tester repo, switch out chromium for firefox and have docker hub auto build on baseimage updates.