| *** toscalix has joined #baserock | 00:51 | |
| *** toscalix has quit IRC | 01:01 | |
| *** CTtpollard has quit IRC | 01:59 | |
| *** rdale has quit IRC | 02:32 | |
| *** gtristan has joined #baserock | 06:39 | |
| jjardon | pedroalvarez: no problem with ansible when using a gitlab mirror instead our trove: https://gitlab.com/baserock/definitions/builds/5193766 | 06:56 |
|---|---|---|
| *** ctbruce has joined #baserock | 07:39 | |
| *** ctbruce has quit IRC | 07:40 | |
| *** ctbruce has joined #baserock | 07:47 | |
| pedroalvarez | jjardon: | 08:09 |
| pedroalvarez | <tiagogomes> HEAD in ansible from git.baserock.org points to refs/heads/master | 08:09 |
| pedroalvarez | <tiagogomes> HEAD in ansible from git://github.com/ansible/ansible points to refs/heads/devel | 08:09 |
| pedroalvarez | the head seems to be fine in gitlab too | 08:10 |
| pedroalvarez | I still think this is nothing to be fixed in the trove | 08:11 |
| paulsherwood | pedroalvarez: so you believe that tiagogomes' git gc change will fix it? | 08:14 |
| * paulsherwood is merging it now | 08:14 | |
| pedroalvarez | I'm not sure | 08:14 |
| pedroalvarez | but the change makes sense | 08:15 |
| *** locallycompact has joined #baserock | 08:29 | |
| pedroalvarez | gah, gitlab -> 500 | 08:40 |
| rjek | Perhaps they tried upgrading it | 08:58 |
| tiagogomes | yes, my patch will fix it | 09:18 |
| tiagogomes | The explanation why other ansible repo can work, is because it won't need to run the garbage collection after the fetch | 09:21 |
| pedroalvarez | why does it run the gc for g.b.o repo? | 09:21 |
| * paulsherwood thinks that gitlab.com is unacceptably slow | 09:22 | |
| tiagogomes | I don't know the git internals to know that. But I wonder if gc is being run automatically on gbo. | 09:23 |
| * paulsherwood has had three attempts to merge this so far... it just sits there saying 'merge in progress' | 09:25 | |
| leeming | gitlab.com was being painfully slow yesterday too | 09:25 |
| leeming | although it has its merits, their official site is too damn slow :( | 09:26 |
| jmacs | I agree | 09:27 |
| ChrisPolin | +1 | 09:27 |
| tiagogomes | bear in mind that we are using a rc version ;) | 09:27 |
| paulsherwood | tiagogomes: rc version of what/ | 09:30 |
| paulsherwood | ? | 09:30 |
| paulsherwood | tiagogomes: merged, anyway | 09:31 |
| leeming | I wonder if this is to blame : https://twitter.com/gitlabstatus/status/788301433435291648 | 09:33 |
| tiagogomes | paulsherwood, gitlab.com. On Friday there was an alert on gitlab.com saying that it was going to be updated to a new version. That new version ended in "rc" | 09:34 |
| paulsherwood | :/ | 09:34 |
| leeming | they also seem to be aware of delayed build queues since the 14th | 09:34 |
| jjardon | anahuelamo: about the usrmerge, take a look to https://storyboard.baserock.org/#!/story/11 , current WIP branch here: https://gitlab.com/baserock/definitions/commits/jjardon/usr-merge | 11:01 |
| anahuelamo | ta jjardon | 11:02 |
| tiagogomes | jjardon, about the usr-merge… why are you merging /usr/bin and /usr/sbin? | 11:04 |
| anahuelamo | I can guess is a requirement for using ostree as a tool for update the system | 11:05 |
| jjardon | no, I do not think so; Im doing that because it doesnt cost me nothing and will make the system more deterministic (all is in /usr/bin). Some distros do this already | 11:06 |
| tiagogomes | jjardon, can you give one distro that is doing that? I like the separation between the executables intended to be used by normal users, and administration tools | 11:09 |
| jjardon | tiagogomes: Arch | 11:09 |
| leeming | isn't fedora also one of them? I had issues with their atomic stuff | 11:13 |
| tiagogomes | Fedora implemented usr-merge but with distinct /usr/bin and /usr/sbin directories | 11:15 |
| tiagogomes | Btw I was planning to try to have the branch build, but I assume guess anahuelamo will | 11:16 |
| tiagogomes | *bah* | 11:16 |
| tiagogomes | I assume anahuelamo will do that work? | 11:17 |
| anahuelamo | I'll try use ostree with baserock, so any work needed for that will be on my list of tasks | 11:17 |
| jjardon | tiagogomes: I do not think she would mind some help ;) | 11:18 |
| anahuelamo | not at all! everything is always very welcome | 11:18 |
| tiagogomes | :) | 11:19 |
| rjek | Hello. Say I have a trove that is currently pulling from gbo. What would I need to do to change it to pulling from upstream directly instead? I assume a Lorry config change, but how much of one? | 11:53 |
| rjek | (I realise that for some repositories this means it won't be possible to switch back as commit SHAs will be different for things that do not originate from git) | 11:54 |
| *** locallycompact has quit IRC | 11:54 | |
| SotK | I think you just remove the upstream trove bit from lorry-controller.conf | 11:56 |
| SotK | and then add lorries you want in local-config/lorries.git | 11:57 |
| tiagogomes | who has the powers to do so, can we stop mirroring gitlab sandboxlib from github | 12:03 |
| paulsherwood | tiagogomes: you mean update its lorry file? | 12:08 |
| paulsherwood | has sandboxlib officially moved to gitlab now? | 12:08 |
| tiagogomes | I don't think there are lorry files involved. There is a gitlab baserock/sandboxlib repo that is configured to mirror from github codethinklabs/sandboxlib . I think that the canonical location for the repo should be gitlab/baserock | 12:11 |
| paulsherwood | well, the official upstream of sandboxlib has been github so far | 12:12 |
| tiagogomes | I don't know how to interpret "officially" here, as things have been moving in a not officially way | 12:12 |
| SotK | ybd moved officially, thats the only thing thats gone github --> gitlab afaik? | 12:13 |
| tiagogomes | yes, I know. But I think gitlab where the ybd and definitions are would be a better home | 12:13 |
| paulsherwood | i'm not disagreeing... just noting that there'd have to be some process to move it | 12:13 |
| tiagogomes | Maybe there is value in having some repos in both gitlab and github and mirroring from each other, but baserock stuff shouldn't be under the CodethinkLabs umbrella no? | 12:14 |
| * paulsherwood is ok with moving it, but is not a member of upstream sandboxlib | 12:14 | |
| tiagogomes | Moving here is, 1) stop mirroring the repo from github on gitlab 2) add a note on Codethinklabs/sandbox lib about the new location of the repo | 12:15 |
| SotK | 3) update the lorry file on g.b.o to point to the new upstream | 12:16 |
| tiagogomes | ah I didn't know that sandboxlib was on gbo as well | 12:18 |
| *** gtristan has quit IRC | 12:24 | |
| leeming | as I saw it, github is the upstream master. gitlab was only being used by myself to utilise the ci | 12:28 |
| leeming | is this an issue? | 12:28 |
| leeming | i am unaware if there is any official doctrine for these things | 12:29 |
| *** locallycompact has joined #baserock | 12:30 | |
| pedroalvarez | tiagogomes: your fix works | 12:43 |
| pedroalvarez | thanks for that | 12:43 |
| tiagogomes | Now if only the sky had an API that I could use to fix this weather… | 12:46 |
| pedroalvarez | nope, there are not API's for real clouds | 12:46 |
| tiagogomes | Even openstack is better then | 12:58 |
| franred | tiagogomes, you can always try to implement Zeus in SkyStack and try to see if he can change the weather | 13:08 |
| franred | tiagogomes, depending on the language you will use, you may implement Jupiter instead :P | 13:09 |
| tiagogomes | Implementing Zeus requires god powers, which I am afraid to not possess :P | 13:13 |
| pedroalvarez | hehe, thge deploy stage at gitlab will also build | 13:19 |
| pedroalvarez | the artifacts won't be there from the previous stage | 13:20 |
| pedroalvarez | very annoying if you are testing something very low in the stack | 13:20 |
| *** mwilliams_ct has joined #baserock | 13:21 | |
| tiagogomes | mm, in case of no better solution, then remove the build stage? | 13:21 |
| mwilliams_ct | Hey baserockers. I'm currently setting up a trove of my own to mirror from another trove. I don't want it to mirror all repositories, as some is proprietary private stuff that we don't want on this new machine. All those repositories start with "delta/codethink/". Should "ignore": ["delta/codethink/*"] block them? | 13:22 |
| tiagogomes | The problem will become more aggravated when more contributors come on board. | 13:23 |
| paulsherwood | pedroalvarez: with private runners, we can retain state/artifacts iiuc | 13:23 |
| SotK | mwilliams_ct: I think so | 13:24 |
| pedroalvarez | paulsherwood: that would speedup things | 13:24 |
| mwilliams_ct | SotK: OK, I'll give it a shot. jic not, is there an easy way to delete later? It's not a crisis if they do get mirrored by accident (there is password protection) but we will need to eliminate them | 13:24 |
| pedroalvarez | it looks like there are deps missing for deployment: https://gitlab.com/palvarez89/definitions/builds/5126387 | 13:26 |
| SotK | I expect you can probably just rm the repositories in wherever lorry-controller puts them, but I'm not enough of a gitano expert to know if there is anything else needed | 13:26 |
| mwilliams_ct | SotK: ack, thanks for the help :) | 13:26 |
| tiagogomes | huh? But doesn't it need the yaml module to build? | 13:28 |
| * pedroalvarez has no idea | 13:31 | |
| pedroalvarez | (not much time to debug this things, just some to give them a try) | 13:31 |
| pedroalvarez | these* | 13:31 |
| paulsherwood | Successfully built fs pyyaml sandboxlib | 13:35 |
| paulsherwood | Installing collected packages: six, fs, pyyaml, sandboxlib, requests | 13:35 |
| paulsherwood | Successfully installed fs-0.5.4 pyyaml-3.12 requests-2.11.1 sandboxlib-0.3.1 six-1.10.0 | 13:35 |
| paulsherwood | weird | 13:35 |
| leeming | it is weird. I didn't even know I had updated sandboxlib on pypi | 13:36 |
| SotK | does gitlab do something to PYTHONPATH which might be confusing the extensions (which are run with their own PYTHONPATH magic)? | 13:37 |
| paulsherwood | i doubt it - ybd doesn't fiddle with PYTHONPATH, and it's clearly ok with the install | 13:38 |
| pedroalvarez | (i believe this has been working before) | 13:39 |
| pedroalvarez | but yeah, SotK could be right | 13:39 |
| pedroalvarez | but the fact that it has been working before makes me doubt as well | 13:40 |
| SotK | https://gitlab.com/baserock/ybd/blob/master/ybd/sandbox.py#L215-219 is the PYTHONPATH thing that lets extensions run properly, but I also doubt it if its been working before | 13:40 |
| * paulsherwood apologises, then... ybd *does* fiddle with it | 13:41 | |
| paulsherwood | leeming: are you close to fixing https://github.com/CodethinkLabs/sandboxlib/pull/25 ? | 13:52 |
| leeming | no, i am blocking on the issue i was discussing yesterday | 13:52 |
| paulsherwood | have you seen tiagogomes comment? | 13:53 |
| leeming | which one? | 13:53 |
| paulsherwood | 'I believe @leeming is missing adding --unshare-user --gid 0 --uid 0 to the bwrap command line.' | 13:54 |
| leeming | yes, we were discussing this yesterday evening. I am getting an "unknown --uid 0" error when running with ybd | 13:54 |
| leeming | i have just been trying to identify where this comes from | 13:55 |
| leeming | if it is ybd or inside sandboxlib | 13:55 |
| leeming | as I print out the command sandboxlib will be using | 13:55 |
| leeming | and i run it manually, and it does not complain of the same thing | 13:55 |
| paulsherwood | where is your code that implements what tiagogomes is asking? | 13:56 |
| leeming | https://github.com/CodethinkLabs/sandboxlib/blob/0972adb5395165d91fefc64a793ee9e687d336e5/sandboxlib/bubblewrap.py#L128 | 13:59 |
| paulsherwood | what is stdou: ? | 13:59 |
| leeming | stdout? | 14:00 |
| leeming | one of the run_command args | 14:00 |
| paulsherwood | should the extend by '--uid', '0', '--gid', '0' by any chance? (i'm just guessing) | 14:01 |
| rjek | log.info("bubblewrap.run_command({}, stdou:{}, stderr:{}, env:{})" | 14:01 |
| rjek | stdou: should be stdout:? | 14:01 |
| rjek | I know that's just a log line, but it's burning a hole into my retinas | 14:01 |
| leeming | small type for debugging but yes radiofree | 14:01 |
| leeming | rjek, ** | 14:01 |
| paulsherwood | leeming: and my question above? | 14:02 |
| leeming | running | 14:02 |
| leeming | seems to get past the usual error point, which is strange. so thanks for the suggestion, it seems to have resolved that | 14:04 |
| * leeming doesn't understand what voodoo python is doing to this list | 14:04 | |
| tiagogomes | -bwrap_command.extend(['--unshare-user', '--uid 0', '--gid 0']) | 14:18 |
| tiagogomes | +bwrap_command.extend(['--unshare-user', '--uid', '0', '--gid', '0']) | 14:18 |
| tiagogomes | leeming, do that ^, not tested | 14:18 |
| leeming | tiagogomes, yes I did, it seems to be all working now | 14:21 |
| leeming | thanks | 14:21 |
| leeming | someone pointed out to me in another channel that these are exec args, therefore need to be split out into separate members, instead of my naive assumption of shell based args that are just " " joined | 14:23 |
| locallycompact | how do I install pip for python3.5 on debian | 14:28 |
| locallycompact | *ubuntu | 14:28 |
| tiagogomes | Without knowing, I would give 'pip3' or 'python-pip3' a shot. | 14:30 |
| locallycompact | that just installs thing sfor python3.4 | 14:31 |
| tiagogomes | Also leeming, you push branches named 'fix-tiago'. | 14:31 |
| * tiagogomes doesn't need any fix! | 14:31 | |
| SotK | locallycompact: `python3-pip` any good? | 14:31 |
| locallycompact | it's just pointing at python3.4 | 14:32 |
| leeming | it was not clear what the process was, that was a suggestive fix for a PR | 14:32 |
| tiagogomes | I don't think isn't a 3.0, 3.1, 3.2 version of a library. | 14:33 |
| tiagogomes | So or you install pip or pip3 | 14:33 |
| locallycompact | lc@warsong:/usr/local/lib$ pip3 --version | 14:33 |
| locallycompact | pip 1.5.6 from /usr/lib/python3/dist-packages (python 3.4) | 14:33 |
| locallycompact | I wnat that last bit to be python 3.5 | 14:33 |
| locallycompact | so it installs things in python3.5 dist packages | 14:33 |
| tiagogomes | Do you python 3.5 installed? | 14:34 |
| locallycompact | yes | 14:34 |
| tiagogomes | *have | 14:34 |
| leeming | oh, i thought it was just py2/dist-packages and py3/dist-packages | 14:34 |
| locallycompact | maybe I'll try just a hacky copy | 14:35 |
| tiagogomes | Have you tried to upgrade pip? | 14:35 |
| pedroalvarez | not sure but maybe `update-alternatives --config python` works in this case? | 14:35 |
| pedroalvarez | or is that a only-debian thing? | 14:35 |
| leeming | maybe pip is printing out the default py3 in that string, but if you were to include the lib when running py3.5, it would still look in the same place | 14:35 |
| locallycompact | no alternative sfor python | 14:35 |
| tiagogomes | It is not a debian-ism | 14:35 |
| *** CTtpollard has joined #baserock | 14:36 | |
| leeming | tiagogomes, was this gid the only issue remaining for the sandboxlib pr? | 14:37 |
| leeming | if so, i will squish my latest micro commits | 14:38 |
| tiagogomes | leeming, no. I didn't review the PR yet. And I'd prefer to only review it once you get a successful build with ybd | 14:38 |
| leeming | ok | 14:38 |
| leeming | i think you just cursed it | 14:39 |
| * leeming reads the error | 14:39 | |
| tiagogomes | As you may need to tweak the flags in order to get there (as you had for --uid and --gid) | 14:39 |
| leeming | you everyone is clearly more tuned into this stuff than I, here is a bit of the log. If anything jumps out? http://paste.baserock.org/acehesixil | 14:41 |
| leeming | I will investivate | 14:41 |
| leeming | ah, looks like ybd is the one trying to create devices, then presumingly passing them into the sandbox | 14:43 |
| tiagogomes | lulz, I had asked about how devices nodes were going to work a few days ago… | 14:43 |
| *** gtristan has joined #baserock | 14:43 | |
| paulsherwood | leeming: i guess this is the crux of the matter :) | 14:43 |
| leeming | what my response was tiagogomes ? | 14:43 |
| paulsherwood | does bubblerwap allow things to believe they can mknod ? | 14:44 |
| tiagogomes | something not very distant from dunno | 14:44 |
| leeming | yes, something along the lines that it was outside my knowledge area, and i was just following orders, and people could help, which im pleased you have | 14:45 |
| leeming | why aren't devices made inside the sandbox anyway? | 14:45 |
| leeming | e.g. stage2-fhs-dirs's build-command have the mknod command | 14:46 |
| leeming | or what ever os.mknod converts to | 14:46 |
| tiagogomes | paulsherwood, why would you want pseudo-mknod? If the build steps for some chunk requires real devices nodes, pseudo-mknod wouldn't help. If not, we perhaps could get rid of the device nodes. | 14:47 |
| paulsherwood | tiagogomes: i don't know. ybd just reimplements what morph did in this regard. | 14:47 |
| * tiagogomes points out that also ostree doesn't support devices nodes on an ostree commit. | 14:47 | |
| * paulsherwood is unclear how device nodes would get created for actual systems, if they aren't in the artifacts | 14:48 | |
| *** gtristan has quit IRC | 14:48 | |
| tiagogomes | Morph ran as root, so the os.mknode would work | 14:48 |
| paulsherwood | so does ybd | 14:48 |
| SotK | I think I did a thing to do it when I did the ostree stuff for the artifact cache | 14:48 |
| SotK | but I can't remember what that thing was | 14:48 |
| paulsherwood | lol | 14:48 |
| leeming | what about my query? | 14:49 |
| paulsherwood | you mean 15:45 < leeming> why aren't devices made inside the sandbox anyway? | 14:50 |
| leeming | yes | 14:50 |
| paulsherwood | afaik they are | 14:50 |
| tiagogomes | I assume that actual systems would have device nodes automatically via a devtmpfs fs | 14:50 |
| *** gtristan has joined #baserock | 14:50 | |
| leeming | but you were just saying morph/ybd does it | 14:50 |
| leeming | then these are passed to the sandbox | 14:50 |
| tiagogomes | But that needs more research. | 14:51 |
| leeming | instead of putting in the dev creation inside the definitions | 14:51 |
| leeming | therefore the sandbox would make the dev | 14:51 |
| leeming | what am i missing? | 14:51 |
| * paulsherwood is confused, and multitasking, sorry | 14:51 | |
| SotK | ah, my patch made it so that the device nodes are created in the staging area when putting an artifact that would need them there, so that wouldn't help with ostree-based systems I think | 14:51 |
| tiagogomes | leeming, permissions to make the dev if you are not root, is what u are missing. | 14:52 |
| SotK | (as opposed to actually storing the device nodes in the artifact) | 14:52 |
| tiagogomes | Although you could bind mount the host devices into the sandbox I guess | 14:52 |
| leeming | that is how it is trying to do it atm | 14:52 |
| tiagogomes | But I don't know how much of that affects reproducibility and safety | 14:53 |
| leeming | so you have ot be root to make a device? | 14:53 |
| leeming | even inside the sandbox? | 14:53 |
| leeming | I thought that was what the --unset-user bit did | 14:53 |
| paulsherwood | SotK: even so, maybe your patch is what leeming needs here? | 14:55 |
| *** tardyp has quit IRC | 14:56 | |
| paulsherwood | ostree is a separate step/problem | 14:56 |
| paulsherwood | this is just about getting artifacts to build without root | 14:56 |
| leeming | what is this patch SotK ? I thought you were talking about the ostree issue | 14:56 |
| SotK | paulsherwood: I think it'd just move the problem from creating artifacts to unpacking them | 14:58 |
| leeming | so how do i proceed? | 14:59 |
| paulsherwood | SotK: you may be right... but can we see your patch? | 14:59 |
| * paulsherwood reminds himself that a device node is just a file, so there must be a way to do this | 15:00 | |
| *** tardyp has joined #baserock | 15:01 | |
| * paulsherwood wonders if http://blog.hansenpartnership.com/unprivileged-build-containers/ is any help | 15:02 | |
| tiagogomes | I would try to individually bind mount each device node that is required, instead of bind mounting whole /dev | 15:02 |
| SotK | paulsherwood: it is a patch to morph, idk where the similar code lives in ybd, https://gerrit.baserock.org/#/c/291/ | 15:02 |
| SotK | (that series was terribly split up too, so that patch may be missing bits) | 15:03 |
| paulsherwood | SotK: tvm | 15:03 |
| paulsherwood | leeming: so i think you were right, currently ybd doesn't create the nodes inside the sandbox. but it should | 15:11 |
| leeming | yes, it is done in snadbox.py:create_devices | 15:12 |
| leeming | but as tiagogomes explained to me, we still wouldn't be able to make the devices without root | 15:12 |
| * paulsherwood is not helping, here, today, then | 15:14 | |
| * leeming scratches head | 15:14 | |
| leeming | who would be a good person to track down to ask then? | 15:15 |
| leeming | i dont understand why these have to be root permissions/ normal user can't make them | 15:15 |
| * paulsherwood is still trying to understand this | 15:20 | |
| paulsherwood | tiagogomes: how does ostree handle nodes, then? | 15:20 |
| * paulsherwood wonders if we coud just disregard the nodes completely somehow | 15:21 | |
| leeming | well i know some of the build commands access /dev/things | 15:22 |
| paulsherwood | right, but in the sandbox, does dev/foo need to be a device node? | 15:22 |
| leeming | well i could mount arbitrary things to /dev if I wanted | 15:24 |
| leeming | if that is what you are asking? | 15:24 |
| leeming | i am not sure what the build instructions are doing/require from /dev | 15:24 |
| leeming | this is for stage2-fhs-dirs btw | 15:25 |
| paulsherwood | ack | 15:26 |
| * paulsherwood wonders if dev/foo in a tarball is really a device node | 15:33 | |
| tiagogomes | paulsherwood I think there are two distinct aspects re devices nodes. Devices nodes required for building a system, and devices nodes on running systems. ostree is agnostic regarding how the filesystem is built (hence why baserock is a good candidate for building ostree's trees). The devices nodes on running systems may be created automatically by devtempfs. | 15:34 |
| * leeming reads about fakeroot | 15:34 | |
| tiagogomes | device nodes is not much more than a normal file with a major and minor number associated. Then the kernel will use those numbers to map to the right driver | 15:36 |
| leeming | what are the effects of using host dev? | 15:36 |
| leeming | well, the dev's that are used | 15:37 |
| leeming | /dev/random,null, ... | 15:37 |
| leeming | so like tiagogomes(?) said earlier, mount each device node separately? | 15:37 |
| leeming | from the host | 15:37 |
| leeming | (or am i miss reading/understanding) | 15:38 |
| paulsherwood | that could be ok for what the builds need... then there's just the question of what needs to go in the artifacts | 15:38 |
| * paulsherwood should maybe step back from this, though and let gtristan, tiagogomes and others comment properly | 15:39 | |
| leeming | okies | 15:39 |
| tiagogomes | [tiagogomes@tiagogomes-thinkpad bubblewrap]$ bwrap --bind /usr /usr --proc /proc --symlink usr/lib /lib --symlink usr/lib64 /lib64 --symlink usr/bin /bin --symlink usr/sbin /sbin --chdir / --bind /dev/urandom /dev/urandom --uid 0 --gid 0 --unshare-user /bin/sh -c 'head -n1 /dev/urandom' | 15:40 |
| tiagogomes | head: cannot open '/dev/urandom' for reading: Permission denied | 15:40 |
| leeming | "execvp /bin/sh: No such file or directory" , but i've come across this before :) | 15:41 |
| leeming | you are using a fedora system right? | 15:41 |
| *** ctbruce has quit IRC | 15:49 | |
| tiagogomes | Yes, you will need to use the right symbolic links for your os. Or just use some baseroch chroot | 15:50 |
| *** mwilliams_ct has left #baserock | 15:50 | |
| tiagogomes | bwrap --bind /usr /usr --proc /proc --symlink usr/lib /lib --symlink usr/lib64 /lib64 --symlink usr/bin /bin --symlink usr/sbin /sbin --chdir / --dev-bind /dev/urandom /dev/urandom --uid 0 --gid 0 --unshare-user /bin/sh -c 'head -n1 /dev/urandom' | 15:51 |
| tiagogomes | ��#�n�_S���{06IMbį״Oڂ�����t#)��Ǎ&�T�x8������Y | 15:51 |
| tiagogomes | success ^ | 15:51 |
| pedroalvarez | random success, but success after all | 15:51 |
| tiagogomes | Actually, although `--dev-bind /dev /dev` makes all devices nodes available in the sandbox, `--dev` only makes a reduced sanitized list of devices nodes available: | 16:03 |
| tiagogomes | bwrap --bind /usr /usr --proc /proc --symlink usr/lib /lib --symlink usr/lib64 /lib64 --symlink usr/bin /bin --symlink usr/sbin /sbin --chdir / --dev /dev --uid 0 --gid 0 --unshare-user /bin/sh -c 'ls /dev' | 16:03 |
| tiagogomes | console full null ptmx ptsrandomshm stderr stdin stdout tty urandom zero | 16:03 |
| leeming | oh really? | 16:04 |
| leeming | but better to whitelist the devs we need though? | 16:05 |
| tiagogomes | So for at list building systems to work without root privileges, the build tool needs to stop parsing the 'devices' field in chunks and creating the respective device nodes, and just mount the sane /dev in the sandbox. The fhs-dirs artifact would cease to have device nodes on it. | 16:06 |
| tiagogomes | *at least | 16:07 |
| tiagogomes | I don't see the point of having a whitelist, if there is already one in bubblewrap. | 16:08 |
| leeming | it was a matter of trustability and only mounting what we need | 16:09 |
| tiagogomes | But if you want to be extremely suspicious, you could verify that each major/minor number of the devices nodes in the host that will be made available in the sandbox have the expected numbers. | 16:09 |
| *** fay_ has quit IRC | 16:09 | |
| locallycompact | argfh | 16:27 |
| locallycompact | https://gitlab.com/baserock/ybd/builds/5244534 | 16:27 |
| locallycompact | This is doing my nut | 16:27 |
| leeming | is it a root permissions thing? | 16:28 |
| locallycompact | yes | 16:28 |
| locallycompact | or something | 16:29 |
| locallycompact | ffffffs | 16:29 |
| leeming | is it running a command? doesn't the ci tell you the command | 16:29 |
| locallycompact | I don't even know how to get to a state where I can test this | 16:29 |
| locallycompact | It's fetching the repository | 16:29 |
| locallycompact | It hasn't got to commands | 16:30 |
| leeming | doing a git clone? | 16:30 |
| locallycompact | doing git fetch | 16:30 |
| leeming | of the runner container? | 16:30 |
| leeming | or how ever they run internally | 16:30 |
| locallycompact | I turned that off so I could run it on a local ubuntu runner | 16:30 |
| locallycompact | but that failed for something | 16:30 |
| locallycompact | now I will try.... | 16:31 |
| locallycompact | something esle I have no idea | 16:31 |
| leeming | be nice if the ci linked ot the .ci-whatsyamajiggy file | 16:31 |
| locallycompact | it hasn't got to that yet | 16:31 |
| leeming | yea, but just in general :) | 16:32 |
| locallycompact | yea | 16:32 |
| locallycompact | OH UBUNTU | 16:32 |
| locallycompact | OH GITLAB | 16:32 |
| leeming | haha | 16:32 |
| locallycompact | OH DOCKER | 16:32 |
| locallycompact | OH YBD | 16:32 |
| locallycompact | OH PYTHON | 16:32 |
| leeming | shhh behave in these parts | 16:32 |
| tiagogomes | s/OH UBUNTU/OH DEBIAN/ | 16:32 |
| locallycompact | Make debian haskell jamaica | 16:33 |
| *** CTtpollard has quit IRC | 17:30 | |
| *** SotK has quit IRC | 17:33 | |
| *** inara` has quit IRC | 17:33 | |
| *** bjdooks has quit IRC | 17:33 | |
| *** gary_perkins has quit IRC | 17:33 | |
| *** SotK has joined #baserock | 17:33 | |
| *** bjdooks has joined #baserock | 17:33 | |
| *** gary_perkins has joined #baserock | 17:33 | |
| *** inara has joined #baserock | 17:34 | |
| *** CTtpollard has joined #baserock | 18:18 | |
| *** locallycompact has quit IRC | 18:41 | |
| *** locallycompact has joined #baserock | 18:54 | |
| *** gtristan has quit IRC | 19:03 | |
| *** tardyp has quit IRC | 19:45 | |
| *** tardyp has joined #baserock | 19:46 | |
| *** jjardon_matrix has quit IRC | 21:17 | |
| *** jjardon_matrix has joined #baserock | 21:19 | |
| *** locallycompact has quit IRC | 21:22 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!