11:35 <icebrain> hi! I'm trying to package an app that depends on Postgres, but it's failing with "could not look up effective user ID 1000: No such file or directory". Has anyone got PG working in Sandstorm?

11:47 <dwrensha> icebrain: Maybe postgres is looking for /etc/passwd ?

11:49 <dwrensha> by default, spk hides /etc/passwd from the app

11:50 <dwrensha> this is specified in your sandstorm-pkgdef.capnp file, under pkgdef.sourceMap

11:52 <dwrensha> for gitlab-sandstorm, I needed to add an /etc/passwd file: https://github.com/dwrensha/gitlab-sandstorm/blob/8b2508ac6ab8295e8c7ad1ab974677edc2f6e4bb/etc/passwd

11:57 <icebrain> dwrensha: thanks! I'll look into it. Didn't know /etc/passwd got hidden

11:57 <dwrensha> yeah, maybe that makes less sense now that vagrant-spk is the default

12:00 <dwrensha> note also that /proc does not get mounted in the sandbox

12:01 <icebrain> thanks; I don't expect the app to need it, thankfully

12:24 <icebrain> dwrensha: sorry, but how should one add the file? I've created one like yours (in a 'etc' directory in my app) and then added "etc/passwd" to alwaysInclude, but PG is still not getting it

12:47 <dwrensha> icebrain: you'll need to make sure that sourceMap maps the file in at the right place

12:48 <dwrensha> see https://github.com/sandstorm-io/sandstorm/blob/v0.172/src/sandstorm/package.capnp#L166-L190

12:48 <dwrensha> I think in the default setup your file would get mapped in at /opt/app/etc/passwd

12:49 <dwrensha> but if in your repo you put the passwd file at .sandstorm/etc/passwd then I think it will show up in the right place in the sandbox

12:49 <dwrensha> due to the `(sourcePath = ".")` line

12:51 <icebrain> dwrensha: I probably need to start over at this point :) thanks for your help!

17:26 <asheesh> icebrain: Hi!

17:26 <asheesh> Still need help?

18:16 <mnutt> I'm trying to run spk directly and getting this error: `sandstorm/fuse.c++:378: failed: read(/dev/fuse): Input/output error`

18:17 <mnutt> (running with `sudo spk dev` from the .sandstorm directory)

18:17 <mnutt> as to why I'm not using vagrant-spk, I'm testing a sandstorm PR and need to rebuild with that sandstorm's http bridge

18:23 <mnutt> ah, it may have been how I installed sandstorm....many things in /opt/sandstorm are chowned root:root?

18:25 <asheesh> sudo modprobe fuse

18:25 <asheesh> Probably

18:25 <asheesh> But also I/O error is a little weird.

18:25 <asheesh> Also I think you shouldn't 'sudo spk dev'

18:25 <asheesh> as for vagrant-spk + sandstorm PR

18:26 <asheesh> You can 'sudo sandstorm update' within the 'vagrant-spk vm ssh' and then you can keep using vagrant-spk while using a new Sandstorm build

18:26 <asheesh> And the fact that people run into this periodically is a serious docs bug, I do suppose!

18:26 <asheesh> mnutt: ^

18:26 <mnutt> hmm

18:26 <mnutt> yeah, unfortunately modprobe fuse didn't fix it

18:26 <asheesh> Running an ever-increasing number of things as root is a bit of a mess, in the sense that I haven't tested it and who knows what is lurking deep within.

18:26 <asheesh> Oh, I forgot to say - you can sudo sandstorm update /path/to/a/build.tar.xz

18:27 <mnutt> ohh, I see now. I'll try vagrant-spk.

18:27 <asheesh> And you can get such a build by doing

18:27 <asheesh> $ make fast

18:27 <asheesh> within a sandstorm git clone

18:28 <asheesh> Also if you want, you can very easily convince me to write up a docs section on this in the near-immediate future.

18:29 <asheesh> I'm trying to work harder to write docs to answer people's questions rather than typing answers into a beautiful evanescent space like email or IRC.

18:30 <mnutt> I wonder when vagrant will start supporting hyperkit on mac, I've gotten to where I only use virtualbox as a last resort the fs is so slow

18:31 <asheesh> https://github.com/sirn/vagrant-xhyve

18:31 <asheesh> "Port forwarding Not implemented"

18:32 <mnutt> yeah, promising to see though

18:32 <asheesh> https://veertu.com/forums/topic/vagrant-provider/ is promising but vague too

18:32 <mnutt> docker has it figured out

18:33 <mnutt> the new docker for mac is quite pleasant to use

18:33 <asheesh> https://rubygems.org/gems/vagrant-veertu does actually exist, interestingly

18:33 <asheesh> Interesting.

18:33 <asheesh> Yeah, if Docker has it figured out, it sure would be nice to layer on top of that.

18:33 <asheesh> https://veertu.com/knowledgebase/vagrant-setup-instructions/

18:34 <asheesh> If you can try vagrant-veertu at some point, and it works reasonably well, it might be smart to switch vagrant-spk to it.

18:34 <mnutt> oh cool, will do

18:34 <asheesh> vagrant-spk has a somewhat conservative design; I'd love to see it keep changing.

18:35 <asheesh> The shell scripts thing is meh but livable. Layering something vagrant-spk-like on top of Docker would be nicer in some ways, but has its own challenges.

18:36 <asheesh> The fact that https://docs.sandstorm.io/en/latest/install/#option-6-using-sandstorm-within-docker exists now is interesting. That reminds me, I should add installer-tests for Docker.

18:38 <asheesh> Arguably the Vagrant VMWare support is also worth looking into.

18:39 <mnutt> some vagrant-spk commands for building sandstorm from source would be cool. I think at one point I had a setup where sandstorm lived in .sandstorm/sandstorm which was mounted inside the vm.

18:40 <asheesh> Oh, interesting.

18:40 <asheesh> vagrant-spk get-sandstorm-source

18:41 <asheesh> And maybe that puts a git clone of sandstorm into ~/sandstorm-source and then prints out instructions.

18:41 <asheesh> Maybe by default what it does is install Sandstorm git master from source into the box, leaving the code in ~/sandstorm-source

18:41 <asheesh> And also prints out instructions on how to customize it etc.

18:42 <mnutt> yeah, I think that would make it a lot easier to contribute to sandstorm itself

18:43 <mnutt> with probably a route for just editing the meteor frontend (probably much more common) and one for making changes to the daemon

18:43 <asheesh> In theory the main Sandstorm repo has a Vagrantfile.

18:43 <asheesh> However it uses the binary bundle instead of Sandstorm's source.

18:43 <asheesh> I am the person who write it 2y ago so I have some responsibility for it.

18:44 <asheesh> I apparently need to go walk over to a coffee shop but will be back in a little while.

18:44 <asheesh> I would be very interested in spending an hour or two writing up proposals for how to make all this simpler and getting your mostly-synchronous feedback, at some point, though it might not be able to be today, but I would totally be happy if you feel like jumpstarting that process by filing a bug against vagrant-spk about the fact that no one knows how to use a custom Sandstorm build against a vagrant-s

18:44 <asheesh> pk app.

18:46 <mnutt> sure, sounds good. my use cases may not be everyone's but I'm happy to write them up.

18:46 <asheesh> That sure helps!

18:47 <mnutt> and thanks for the help, looks like everything is going

18:47 <mnutt> (trying to verify the x-oc-mtime PR)

18:47 <mnutt> well, the custom header whitelist PR. but I think of it as the x-oc-mtime PR.

18:48 <mnutt> stepping away for a bit.

18:49 <asheesh> bd !

19:05 <mnutt> when you `make install`, the default is to not ask you what channel you want and give you dev, which will silently "upgrade" your custom build after some short amount of time

19:06 <asheesh> Yeah. Luckily 'make update' will warn you about that.

19:07 <asheesh> Maybe 'sudo sandstorm update /path/to/filename.tar.xz' will, too.

19:08 <asheesh> Oh... 'make install' won't warn you, it sounds like you're saying?

19:08 <asheesh> If so that's pretty tragic.