Still working?

[jsalatiel]

@farribeiro Have you been able to make this work recently ?

[farribeiro]

Maybe a broken link of Warsaw. I will see soon

[jsalatiel]

No. It is downloaded , installed and running inside the container.

[rcassaniga]

I tested both @farribeiro and @jsalatiel solutions. I confirm, unfortunately both are not working for BB. The link for downloading the warsaw package is fine. The problem must be something else.
I tested a third solution from @juliohm1978 at dockerbb that worked for me. But it uses VNC to export the browser instead of using X protocol. His docker uses ubuntu, but the main difference, from my point of view, between dockerbb and wsbb or wscef is that dockerbb uses init and starts some basic services.
It is interesting to mention: when I tried to install manually the warsaw package file inside container it complained PID 1 was not init.
I appreciate your time dedicated on a docker for BB/CEF. If could help you, let me know. I really would like to have a solution using X protocol instead of VNC.

[farribeiro]

Running in Ubuntu 21.04, showing the warsaw is operational. But not applied the cef conf files

PS: in login pages of cef and bb not have warning about the warsaw

[juliohm1978]

Hey guys. Dropping by after I saw my username mentioned here 😄

Here are the main difficulties I found trying to get warsaw running inside a container:

1. Warsaw will simply not install unless /sbin/init is PID 1.

2. The fact that the official download URL has no version identification also makes for unpredictable re-builds

3. There are no command line options for any of the binaries installed, such as --help or -h. No man pages at all.

Because of (1), a number of other side issues come up.

For one, I was unable to get systemd running using rootless docker. It needs absolute permissions by running the continer with --privileged and access to your root's dockerd. Because of all these privileges, the most recent version of systemd in the ubuntu:20.04 docker image conflicts with the instance of systemd running outside the container. I'm developing with ArchLinux and my entire user session is hijacked by the container systemd instance until I reboot.

I have not found a way to get warsaw properly running unless /sbin/init is pid 1. And since that's the case, might as well use systemd to run all other services needed to get the browser up and running inside the container as well.

To put it nicely, warsaw is a b****. A blackbox that deserves to be reverse engineered by an expert. It is an terrible solution to a bad problem.

[jsalatiel]

When I have some free time I will try to run the container using podman instead of docker.
Podman plays nice with init/systemd inside the container and does not require privileged flag.

[farribeiro]

cc @awerlang

[juliohm1978]

That would be great, @jsalatiel. Let us know if you get this to work.

Podman is not widely available as docker, but it's a start.

[jsalatiel]

Sure I will. @juliohm1978 thanks for debugging this , btw =)

[farribeiro]

When I have some free time I will try to run the container using podman instead of docker.
Podman plays nice with init/systemd inside the container and does not require privileged flag.

The podman can't run the wcef-docker actual docker-compose.yml... i think be the version of yml file

[farribeiro]

... ubuntu:20.04 docker image ...

I used the ubuntu in the past, but many people wanted to use debian, maybe has low footprint image

[jsalatiel]

@juliohm1978 It worked on podman. I created a new repo. Thanks for your effort debugging. It does not need --privileged flags, although it requires 2 capabilities: CAP_AUDIT_WRITE ( on recent kernels ) and CAP_SYS_PTRACE ( this is probably to strace our data )

I decided to remove all the VNC requirements. Just like @rcassaniga I prefer pure X protocol.

@farribeiro I haven't tried your version with podman, but podman > 3.0 does support docker-compose.yml files by itself. ( not using podman-compose ). If you use podman-compose probably it will not work.

[juliohm1978]

That is excellent! Works like a charm. Works with podman and docker.

But it still needs the usual sudo. I tried both rootless docker and rootless podman.

In rootless mode, I was not able to get the browser started because the mount volume /home/user/.Xauthority appears as root inside the container. The uid/gid mapping is different and my common host user gets mapped to root. You'd have to change permissions on the real /home/user/.Xauthority, but that'll probably mess up the X session for the host user.

Also, docker does is unable to run with just --cap-add CAP_AUDIT_WRITE --cap-add CAP_SYS_PTRACE. It still needs full --privileged.

Other than that, it works great. I'm thinking of using the same idea for dockerbb. It's a lot lighter and easier to use.

Thank you!

[jsalatiel]

That is excellent! Works like a charm. Works with podman and docker.

But it still needs the usual sudo. I tried both rootless docker and rootless podman.

In rootless mode, I was not able to get the browser started because the mount volume /home/user/.Xauthority appears as root inside the container. The uid/gid mapping is different and my common host user gets mapped to root. You'd have to change permissions on the real /home/user/.Xauthority, but that'll probably mess up the X session for the host user.

Also, docker does is unable to run with just --cap-add CAP_AUDIT_WRITE --cap-add CAP_SYS_PTRACE. It still needs full --privileged.

Other than that, it works great. I'm thinking of using the same idea for dockerbb. It's a lot lighter and easier to use.

Thank you!

It works rootless if you remove the .Xauthority mapping and just run 'xhost +' inside the host X session

[awerlang]

I am running podman rootless and it was working seamlessly up to a couple weeks ago. I moved to a VM when it stopped working, to get things done.

In short:

• Works with podman rootless
• With --init (i.e. tini)
• Without --privileged, no sudo package inside container (we drop privileges, never acquire)
• With only capabilities: SETUID SETGID AUDIT_WRITE DAC_OVERRIDE CHOWN
• Copying XAUTHORITY to the stopped container, as it moves across boots, no xhost.

I switched to chromium since firefox stopped working in all containers I have. It worked for a while then warsaw stopped working. Chromium wants some dbus access which is possible to make available to it, but didn't manage to get it working again. Didn't strace this time though.

I'm using make instead of compose, but see no reason why it shouldn't work with podman-compose. docker-compose requires rootful podman atm.

For reference, I reworked to an openSUSE base: https://github.com/awerlang/containers/tree/master/warsaw, my wip is in the develop branch, it's an overhaul of browsers and GUI containers.

I don't expect to have bandwidth to debug the issue this week, but will keep an eye on it.