Bug: Linux file perms + localhost access

[odyslam]

Two issues arise in Linux:

File permissions

Due to containers running as root in Linux, whatever files they create in the binded volumes, can't be cleaned up by the user. That means that it's impossible to run the playground, unless you manually delete these files. On MacOs, Docker Desktop automagically spawns the containers with user permissions so that issue doesn't arise.

Error: unlinkat /home/ubuntu/.playground/devnet/data_validator/validators/logs/validator.log: permission denied

Attempted Fixes:

• Add a user field in every service of the docker compose with the uid and guid of the user who runs the go binary. It made services crash.
• rm -rf $HOME/.playground after every run. Works, but it's a workaround.
• Haven't found anything other that is elegant. Probably the elegant solution is to use Named Volumes instead of Binded Volumes and delete them in Stop(). Could have a performance hit on the spin up/down of the sandbox.
• Another idea would be to pass the user as an env variable and then run the binaries as that user, which could maybe solve it, but I haven't attempted that.

host.docker doesn't seem to work on linux.

I see that the final docker compose has the extra flags that are needed to make it work on Linux, as per Stack Overflow, but so far this hasn't worked for us. Haven't spent huge amount of time in debugging it, probably using host network mode would solve it.

[ferranbt]

Related to #87

[ferranbt]

Validated in #136

[ferranbt]

host.docker doesn't seem to work on linux.

Which part is this? Is this the host.docker.internal DNS entry?

[odyslam]

@ferranbt yes, basically using an external block builder was not possible on a linux machine

[makemake-kbo]

To add more context, we had a builder listening on 0.0.0.0:9551, with external builder set to http://host.docker.internal:9551. we encountered a client error on rollup-boost indicating that it couldnt access the external builder. we could also not see any gossip or blocks on the external builder too.

we also tried to point it at the docker0 network device at 172.17.0.1 (so external builder 172.17.0.1:9551) with the same effect.

[ferranbt]

To add more context, we had a builder listening on 0.0.0.0:9551, with external builder set to http://host.docker.internal:9551. we encountered a client error on rollup-boost indicating that it couldnt access the external builder. we could also not see any gossip or blocks on the external builder too.

But is this a problem with the example? or with the playground?

[makemake-kbo]

But is this a problem with the example? or with the playground?

seems like a playground thing. Unless im missing something the only way to use the external builder flag as is, is with host.docker.internal which is only a docker desktop thing