by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Matthias Vegh
    @matthiasvegh
    cap-add ALL with vagga fails:
    docker run --cap-add ALL --rm -ti matthiasvegh/jenkins-slave /bin/bash
    root@1e95bcb5b21c:/# export http_proxy='http://159.107.194.60:8000'
    root@1e95bcb5b21c:/# apt update &>/dev/null
    root@1e95bcb5b21c:/# apt install --yes apt-transport-https &>/dev/null
    root@1e95bcb5b21c:/# echo 'deb [arch=amd64 trusted=yes] https://ubuntu.zerogw.com vagga main' > /etc/apt/sources.list.d/vagga.list
    root@1e95bcb5b21c:/# apt update &>/dev/null
    root@1e95bcb5b21c:/# apt install --yes vagga &>/dev/null
    root@1e95bcb5b21c:/# cat > vagga.yaml
    containers:
      test:
        setup:
          - !Ubuntu xenial
          - !UbuntuUniverse
          - !Install [htop]
    commands:
      test: !Command
        container: test
        description: "testing"
        run: [/bin/bash]
    root@1e95bcb5b21c:/# vagga test
    ERROR:vagga::wrapper: Error executing _build: Can't mount proc at "/.vagga/.mnt/proc": Operation not permitted (os error 1)
    Command <Command "/proc/self/exe" "__wrapper__" "_build" "test"; environ[4]; uid_map=[UidMap { inside_uid: 0, outside_uid: 0, count: 1 }, UidMap { inside_uid: 1, outside_uid: 1, count: 65535 }]; gid_map=[GidMap { inside_gid: 0, outside_gid: 0, count: 1 }, GidMap { inside_gid: 1, outside_gid: 1, count: 65535 }]> exited with code 124
    root@1e95bcb5b21c:/#
    Paul Colomiets
    @tailhook
    Okay, so differences to --privileged I see:
    1. capabilities (seems to be cheked)
    2. /sys and /cgroup are not readonly in privileged
    3. All devices are allowed in privileged mode
    4. ReadonlyPaths and MaskedPaths are empty (a bunch of paths in /sys and /proc, looks like unused)
    The (2) and (4) I don't see a way to override, the (3) might be tried, but I'm not sure how to specify all devices using --device
    Might try mount -o remount,rw /cgroup if it works
    Matthias Vegh
    @matthiasvegh
    mount -o remount would require --cap-add SYS_ADMIN, but it can be checked
    /cgroup doesn't exist, do you mean /proc/cgroups?
    Sergey Noskov
    @Albibek
    /sys/fs/cgroup most probably
    Paul Colomiets
    @tailhook
    Good question probably this means /sys/fs/cgroup/* and /sys is also a candidate. But I'm in doubt at least any of the works
    Matthias Vegh
    @matthiasvegh
    and is there anything in your gitlab CI that relates to these mountpoints?
    Paul Colomiets
    @tailhook
    No. Vagga does bind mount of sys. And that's it. I just think that kernel might check some of it for some undocumented reason.
    We may patch vagga to skip mounting /proc if everything else is fine :)
    top and ps will not work, but tests might run fine
    Matthias Vegh
    @matthiasvegh
    Well for my use case /proc working is rather important, as I'm running tests where killall my-services are run, and I actually want to break these tests up into separate shards, so each test should be run in there own pid namespace (with accompanying /proc)
    Paul Colomiets
    @tailhook
    Hi! Here is one of the RFCs I want more attention to: tailhook/vagga#488
    Please comment!
    Paul Colomiets
    @tailhook
    Hi everyone! I've started a contest for logo on 99 designs. Here is the issue to subscribe for updates: tailhook/vagga#491 Also, feel free to discuss it here.
    Paul Colomiets
    @tailhook
    Here is the first, preliminary poll for logo: https://99designs.com/contests/poll/3bf78334c0
    It will helps us give more guidance to designers, it's not for the final logo.
    Matthias Vegh
    @matthiasvegh
    Hi! I'm trying to run Thunderbird within vagga, and so far everything works, except opening links. As there is no browser inside the container, Thunderbird doesn't know how to open the link. I was hoping that xdg-open would just work with the X11 socket mounted, but doesn't. Do you have any suggestions? I'm considering writing an xdg-open proxy, that would communicate with the host via unix domain socket to issue the xdg-open in the host namespace instead of the container, but that seems like a hack.
    Paul Colomiets
    @tailhook
    Hi! Everything that wants to "escape" the container probably requires the hack you described. Some things may communicate via X11 socket (I certainly know gvim does that, but I'm not sure about firefox/chrome). But to make that work you need the same browser executable in the container too. xdg-open just calls the command as far as I know, it doesn't communicate to the browser by itself.
    Matthias Vegh
    @matthiasvegh
    Right, I was thinking of putting a custom xdg-open binary into the container that would call out to the host.
    Paul Colomiets
    @tailhook
    We have a poll for the final logo, please, take a look: https://99designs.com/contests/poll/71fabfbf5e
    Kon Tsaki
    @laerus
    cool!
    Kon Tsaki
    @laerus
    hey firefox doesn't like the certificates for https://vagga.rtfd.org/
    vagga.rtfd.org uses an invalid security certificate.
    The certificate is only valid for the following names: *.readthedocs.org, readthedocs.org 
    Error code: SSL_ERROR_BAD_CERT_DOMAIN
    Paul Colomiets
    @tailhook
    @laerus, you should report this bug to readthedocs.org.
    Kon Tsaki
    @laerus
    oh right
    Paul Colomiets
    @tailhook
    In the meantime we can change the link, if it's hanging somewhere...
    Kon Tsaki
    @laerus
    seems like an old issue rtfd/readthedocs.org#3059 :(
    Karel Wintersky
    @KarelWintersky
    Hi, All. How to compile Vagga at gentoo using rust docker container?
    error: environment variable `VAGGA_VERSION` not defined
      --> src/config/config.rs:56:26
    fails here.
    (можно отвечать на русском ;) )
    Karel Wintersky
    @KarelWintersky
    Solved.
    docker run --rm --user "$(id -u)":"$(id -g)" -e VAGGA_VERSION=v0.8.1-19-g372bded -v "$PWD":/usr/src/myapp -w /usr/src/myapp rust cargo build --release
    Lloyd Konneker
    @bootchk
    • !Sh 'git clone --recurse-submodules git://github.com/flathub/org.gimp.GIMP' seems to create a directory org.gimp.GIMP at the top i.e. in parent directory of vagga.yaml, i.e. not in the container. That seems bad. I suppose I can do the recursion myself.
    Paul Colomiets
    @tailhook
    @bootchk, I've already answered on a github, but basically, just cd into a specific directory in the container (we don't forbid mutating working directory, as it would crash a lot of tools out of the box)
    Michael Pankov
    @mkpankov
    hey, from the docs I got the impression that I can build a container with vagga and run it with docker.
    is it correct? how do I do it?
    Paul Colomiets
    @tailhook
    @mkpankov, yes. You should be able to do something like vagga _pack_image CONTAINER_NAME > image.tar; docker import image.tar (or ADD image.tar / in Dockerfile)
    Michael Pankov
    @mkpankov
    thanks, not a docker user so it was really a riddle
    Michael Pankov
    @mkpankov
    hey
    I have several repos where I want to use vagga, currently I've put vagga.yaml in first one. now I've discovered I need to share parts of vagga.yaml between repos (i.e. definition of Rust container). how should I do that?
    I've read about YAML includes and mixins, I can't quite put it together. both of them are restricted to including stuff from sub-directories. why?
    Paul Colomiets
    @tailhook
    @mkpankov, this is a a security measure. So that when you run vagga xxx from a foreign project it can't stole your ssh keys or similar. You can share configs either but putting them in git submodule (and updating manually), or you can mount --bind a subdirectory into several places. Or you can use external-volumes to overcome that limiation (although, it would require configuring them for every user).
    Michael Pankov
    @mkpankov
    thanks for quick reply. to me that seems like a lot of overhead for something I'd like to have out-of-the-box. I mean, submodules are hell and mounting something manually when the purpose of vagga is to avoid doing that... what is your opinion on something that could be built-in?
    or, maybe I should just write a "root" vagga.yaml and move everything there? so that project repos don't contain one and come just as source repositories
    context is, I have repos of two rust tools, one of which runs the other, so they are almost always used together
    Paul Colomiets
    @tailhook
    Technically you can, if you like it.
    I usually install one tool in the second's vagga.yaml as a normal package (e.g. cargo install)
    And then if I want debug something very coupled I use mount --bind or just copy thing in ad hoc way.
    Alternatively, you can also make a command which fetches mixin remotely before the first start.
    Michael Pankov
    @mkpankov
    my tools are proprietary and we currently don't run our registry, so I can't cargo install
    I guess I'd like something of "best practice" advice (even better if it's in the docs)

    Alternatively, you can also make a command which fetches mixin remotely before the first start.

    that's interesting