<paulproteus> Agreed
<aldeka> "key ceremony"?
<mcpherrinm> I'm imagining people in ornate cleanroom suits
<mcpherrinm> a crown of anti-static shielding
<zarvox> the key ceremony is a required part of the CA/Browser Forum Baseline Requirements
<paulproteus> aldeka: see also "Meet the seven people who hold the keys to worldwide internet security" http://www.theguardian.com/technology/2014/feb/28/seven-people-keys-worldwide-internet-security-web
<zarvox> bucket list item: meet a majority of the Tor dirauth operators
<paulproteus> and subvert them
<zarvox> never!
<XgF> Specifically, the key ceremony is so that there is external verification of sorts of the "path" of the key from creation
<paulproteus> never have I ever
<paulproteus> - subverted the Tor dirauth operators
bb010g has joined #sandstorm
<kentonv> GCC and Clang disagree on calling convention if the class has a defaulted copy constructor where the parameter is a non-const reference (which is unusual; normally a default copy constructor parameter is const)
<zarvox> wow, what did it take to track that one down?
<dwrensha> kentonv: is this a known problem?
<kentonv> zarvox: starting from the broken case and deleting code until it went away
<kentonv> dwrensha: I think we had other problems related to non-const reference copy constructors but not exactly the same.
<zarvox> kentonv: nice.
iangreenleaf has joined #sandstorm
<iangreenleaf> Hey all, I'm trying to build Sandstorm from source in Ubuntu server 14.04 and am running into an error during `make`.
<iangreenleaf> node-capnp/capnp-test.js fails, with the log complaining "Error: Cannot find module '/tmp/build/sandstorm-v0.85/node-capnp/capnp-test.js'"
<kentonv> hmm
<iangreenleaf> that's the dir I'm building in, but it looks like `node-capnp` is in `deps` or `src` but it's looking for it in the root. And I can't figure out exactly where this is coming from.
<kentonv> so, ekam implements this virtual filesystem... >_>
<kentonv> but long story short the above path *should* resolve to src/node-capnp/capnp-test.js
<iangreenleaf> Huh. Could it be a dependency I'm missing or a step I skipped?
<zarvox> well, deps/node-capnp/src/node-capnp/capnp-test.js
<kentonv> zarvox: well, the former should point to the latter
<kentonv> iangreenleaf: is src/node-capnp/capnp-test.js present?
<iangreenleaf> yep
<iangreenleaf> I'm checking the source out from github right into `/tmp/build/sandstorm-vXX/`, is that okay?
<kentonv> yes, that should be fine
<kentonv> it seems like somehow the syscall interceptor isn't working when running node, but I don't know why that would be.
<kentonv> if you simply delete capnp-test.js, the test will be skipped, which should be fine unless you're planning to hack on node-capnp
jadewang has quit [Remote host closed the connection]
<kentonv> so you could do that
<iangreenleaf> Sounds good, I'll do that for now.
<zarvox> I reproduce the failure if I build from that directory.
<iangreenleaf> I'm working on building an Ansible playbook to install Sandstorm, hope to share it with the world eventually.
<kentonv> oh hmm
<kentonv> I bet ekam doesn't work under /tmp
<kentonv> I think when it sees "/tmp" it says "I don't need to remap this, it's a temp file"
<zarvox> would /var/tmp work?
<zarvox> or anything with tmp/ in the path is no good?
* zarvox tries /var/tmp
<kentonv> it *mostly* works because usually files in the source directory are opened via relative paths, but node likes to denormalize links before opening
<kentonv> I think /var/tmp would work
<kentonv> I think it only looks for the prefix "/tmp/"
jadewang has joined #sandstorm
<iangreenleaf> Even better then. Giving that a try now.
<zarvox> /var/tmp doesn't appear to work either
<XgF> kentonv: I think actually this is a GCC bug
<XgF> Thats not a trivial copy constructor
<kentonv> XgF: why not?
<kentonv> it's defaulted, how could it not be trivial?
<XgF> Specifically, a trivial copy constructor must be either (a) the implicit copy constructor, or (b) a user defined copy constructor which is defaulted _and has the same signature as the implicit copy constructor_
<kentonv> well fine, I don't care about the definition of "trivial", I care about ABI compatibility.
<XgF> True, but in this case there is also a bug in that gcc is getting std::is_trivially_copyable wrong
<kentonv> also, GCC's definition is the one that is useful in practice.
<XgF> I'm not sure why a T& copy constructor would be useful and why you wouldn't want a const T& one...
<zarvox> /var/build/ works
<zarvox> it looks to be an issue with having 'tmp' as a path component?
<kentonv> XgF: A T& copy constructor is very useful for dealing with transitive constness
<kentonv> I have a type which is a pointer wrapper, say. Somehow you get a const view of my pointer wrapper. I don't want you to be able to de-constify it and get write access to the pointed-to object by making a copy of the pointer.
<XgF> This is why const_iterator is a thing :-)
<kentonv> XgF: sure. But it's unreasonable to expect everyone to write two versions of every single type that happens to contain a pointer.
<XgF> I've done template magic with std::add_const_t in the past :-)
<XgF> And enable_if
<paulproteus> zarvox: apparently due to me being in Workshop Cafe right now, I'm helping someone package something with vagrant-spk (a Python app)
<paulproteus> I'm having them work through https://github.com/zarvox/python-app-to-package-for-sandstorm 's README
<paulproteus> Since they were especially interested in Python stuff. Let me know if this is particularly sane or insane.
<paulproteus> First "bug" report: if 'vagrant up' fails due to 'install.sandstorm.io' DNS problems, then the VM is in an inconsistent state.
<paulproteus> Presumably, since this is initial VM creation, vagrant-spk should say something like:
<paulproteus> "Bringing up the VM failed. Here's the last few lines of text:
<paulproteus> {{ whatever it printed }}
<paulproteus> We'll destroy the VM now, and you can try bringing it up again. OK? [Y/n]"
gopar has joined #sandstorm
<dwrensha> kentonv: Could node-capnp get a new npm release? I was just tripped up by the fact that 0.1.11 does not include the bootstrap capability stuff.
<kentonv> dwrensha: I don't remember if we've introduced things in node-capnp which are not compatible with cap'n proto 0.5...
<kentonv> why do you need it?
<dwrensha> just playing around, trying to isolate some weird behavior
<dwrensha> I can manually install things, it's just a bit cumbersome
<zarvox> paulproteus: how fun! what are they packaging? yeah, I should probably catch failures in `vagrant-spk up` and clean up the VM.
<paulproteus> Right now they're packaging the sample app. I think they make a variety of personal apps.
<paulproteus> They have a personal wiki, for example.
<paulproteus> Also the person is very slightly sad that bringing up the VM takes a while. It'd be nice if the setupvm step could be cached or something. i,i Docker build cache
<paulproteus> But they're pretty OK with it, only the very slightest bit sad.
<paulproteus> I'm pretty aggressively happy with how transparent vagrant-spk feels to me, in terms of the setupvm etc. steps being readable shell scripts, fwiw.
<zarvox> Yeah, setupvm-taking-a-while is annoying, I agree. For the record, if they're willing to run an instance of apt-cacher-ng on their host, that will speed up the .debs portion of things
<paulproteus> Person: "It worked! I got a SPK file."
<paulproteus> Me: "OK. Does the SPK file work?"
<zarvox> :D
<paulproteus> Them: "I don't know how I would verify that."
<zarvox> Upload the .spk to the same sandstorm instance!
<zarvox> (I should add that to the README)
<paulproteus> That's what I told them (-:
<dwrensha> `spk verify`? :p
<zarvox> hahaha that's not quite the same
<zarvox> (also spk verify isn't a command I expose at present, but could be I guess?)
<paulproteus> -0 fwiw
<zarvox> I'd prefer not to, though, since I'd have to copy the .spk into the VM before we could run it
<paulproteus> You could play hilarious games with stdin/stdout but this is not a recommendation that you do so.
<zarvox> oh hey yeah I could but how about I don't
<zarvox> not sure if vagrant ssh plays well with fiddly stdin/stdout things anyway
<kentonv> zarvox: vagrant ssh does binary stdin/stdout just fine, except possibly not on Windows.
<paulproteus> Uploading the SPK was hilariously slow, like 120 sec to upload to local.sandstorm.io. We have no idea why yet, and alas just missed our chance to diganose.
<kentonv> paulproteus: I've noticed Vagrant having really slow networking.
<zarvox> kentonv: thanks, good to know!
brucem has left #sandstorm ["Textual IRC Client: www.textualapp.com"]
<kentonv> long inexplicable pauses
<zarvox> I've noticed it having sometimes-slow networking, and sometimes insanely-fast networking.
<kentonv> in fact it seems to hang the VM to the point where I had to increase the timeout on my health checks from 2s to 10s to avoid killing them
<zarvox> This could also be Virtualbox's fault.
<kentonv> yes it seems pretty variable
<kentonv> oh I'm sure it's virtualbox, not actually vagrant
<zarvox> *nod*
<zarvox> FWIW, I've not had this kind of trouble with libvirt. (I've had *all* sorts of other trouble, but things seem to be pretty okay now.)
<zarvox> Hmmm, wonder if I can convince the Debian Cloud folks to make official libvirt packages in addition to the virtualbox ones.
<dwrensha> aha, weird node-capnp behavior somewhat more isolated now...
<kentonv> dwrensha: what is the behavior?
<zarvox> paulproteus: FWIW, I'm also interested in the possibility of having a caching pip proxy/npm proxy/etc. for the not-.deb dependencies
<paulproteus> ++
<dwrensha> saveParams not getting passed through
<paulproteus> BTW the person is now saying, "That was OK, but how about we use Heroku buildpacks and dokku?"
<paulproteus> So they're investigating that a little bit now.
<paulproteus> My answer is, "It basically depends on if the resulting SPK files would be enormous."
<paulproteus> i,i dokku-spk
<kentonv> dwrensha: when called from node?
<paulproteus> Once mega nice thing about dokku for this purpose is that you hand it your source tree and it, with no intervention, does all the work.
<kentonv> dwrensha: is it because SaveParams is a struct rather than a param list?
<zarvox> Well, we can't do that, because spk dev.
<paulproteus> I recall jparyani and I looking at the Heroku build packs in January 2015 and us both sort of sighing that they're massive piles of shell scripts that download random things from random places.
<paulproteus> zarvox: This flow would allow people to skip "spk dev", fwiw. I'm not sure what you mean by "because spk dev", though.
<dwrensha> kentonv: c++ calls save() with some params, and the save() method defined in node doesn't get the params
<zarvox> I mean, if we don't mind having big spks, we could (today!) make vagrant-spk run on full-auto and just pull in all of /
<dwrensha> by params I mean sealFor
<zarvox> the issue is that we currently require spk dev's tracing to build the filelist for what goes in the package.
<kentonv> dwrensha: Does it just get no params?
<paulproteus> w/r/t "big spks" -- yeah, that's why I asked them to look into the size of the resulting images. We'll see how that turns out.
<zarvox> I'm also not wholly convinced that big spks are bad, since they're immutable and you only really need one copy for all the grains on a machine.
<dwrensha> the method always observes the argment as "undefined"
<paulproteus> i,i every Python app is an "extension" to the "Python runtime app"
<paulproteus> Apparently their Docker VM generated by dokku for Ghost is 1.2GB, says "du -sh /", which is pretty large.
<zarvox> then you're doing the layering package stuff that docker does
<paulproteus> Yeah, I realize, hence i,i
<dwrensha> kentonv: I've got a test c++ server and node client that exhibits this behavior. Currently playing around with it to try to minimize it and understand more
<zarvox> paulproteus: and the spk size is?
<paulproteus> 12MB
<zarvox> Holy smoke, that's 1%.
<zarvox> (I hope the person you're talking to is suitably impressed.)
<zarvox> Granted, that's compressed.
<zarvox> And "du -sh /" is not.
<iangreenleaf> So I switched my build dir to /var/build/sandstorm-vXX and that sorted out the earlier problem. Now I'm getting a new one on `make install`
<iangreenleaf> sh: 1: node: Permission denied
<iangreenleaf> looks like this is happening during an npm install
<iangreenleaf> Strange to get a permissions problem, since I'm running as root. Ran the Meteor install as root too—not sure if that's good or bad.
* iangreenleaf is going AFK shortly, but will check back in later
<kentonv> it's probably not a great idea to run the build as root.
<kentonv> I could imagine that Meteor and other things dislike it
<kentonv> package managers (like Meteor and npm) tend to like to behave differently if you're root.
<kentonv> `tar` actually behaves _very_ differently if you're root (in that it applies ownership as specified in the archive, which you almost never want unless you made the archive yourself)
<kentonv> in any case, the "permission denied" is probably because the execute bit isn't set on `node` somehow, though I wouldn't know exactly why.
posix4e has left #sandstorm [#sandstorm]
<paulproteus> Hilariously zarvox he basically doesn't care about package size.
<paulproteus> Now going AFK for dinner!
<dwrensha> okay, I gotta sleep. kentov: if you want to look at the node-capnp thing, I threw up a repo here: https://alpha.sandstorm.io/shared/q4qsjqQ4Vx3JXi-3-XK6SIYhbJN4fxkSKIFXHK2AXae
<paulproteus> Yeah, iangreenleaf , I hope you can retry by being non-root, and then if that works, maybe we can make the build process bail out if it's being run as root!
<dwrensha> s/kentov/kentonv/
<paulproteus> I slightly exaggerated by "doesn't care", zarvox , but it's maybe 75% true.
<kentonv> dwrensha: probably won't have time to look tonight.
<dwrensha> 'sok
<paulproteus> We talked about one idea I hadn't thought of, which is that we could ship a list of Debian packages to _blacklist_ from inclusion in the SPK, and then otherwise pack the rest of the root filesystme.
<paulproteus> +/- typos
<paulproteus> This could include (hilariously) things like util-linux.
<paulproteus> I'm not quite sure if that's feasible, but there you go. Then vagrant-spk could support a new 'quickpackage' verb, which is non-interactive, but I don't know how small a e.g. Python app would really get with this approach.
<paulproteus> Now actually going AFK for dinner.
<zarvox> paulproteus: thanks for the feedback! useful to hear that he doesn't care much about package size.
isd has quit [Quit: Leaving.]
decipherstatic has quit [Ping timeout: 256 seconds]
decipherstatic_ has joined #sandstorm
paroneayea has quit [Read error: Connection reset by peer]
paroneayea has joined #sandstorm
gopar has quit [Quit: Leaving]
keturn has quit [Quit: weechat upgrade]
keturn has joined #sandstorm
ArcTanSusan has joined #sandstorm
joshbuddy has joined #sandstorm
ArcTanSusan has quit [Quit: ArcTanSusan]
darius has quit [Ping timeout: 255 seconds]
<XgF> Does he not have to *upload* that 1.2GB package somewhere?
joshbuddy has quit [Quit: joshbuddy]
jadewang has quit [Remote host closed the connection]
asmyers has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 244 seconds]
decipherstatic_ has quit [Remote host closed the connection]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 265 seconds]
paroneayea has quit [Read error: Connection reset by peer]
paroneayea has joined #sandstorm
<dwrensha> jparyani: does pycapnp provide a way to export a bootstrap capability?
<dwrensha> oh, I see. Looks like you added something just last night for the server side, but nothing for the client side.
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 272 seconds]
natea has joined #sandstorm
darius has joined #sandstorm
kxra has quit [Quit: WeeChat 1.2]
<dwrensha> kentonv: you were right. the problem is that SaveParams is a struct rather than a param list.
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 264 seconds]
<dwrensha> wait, what!? the params *do* get passed to the save method, but they are in the second argument, not the first
<dwrensha> Hm. Looking at the code for toJsParams() makes me wonder whether we'd be better off if we treated the two cases uniformly.
<dwrensha> client code shouldn't have to care whether a schema defines a param list inline or not inline
<dwrensha> or, put another way, schema authors should be allowed to change a param list from inline to not-inline without worrying about breaking any code
natea has quit [Quit: natea]
natea has joined #sandstorm
natea has quit [Quit: natea]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 276 seconds]
ArcTanSusan has joined #sandstorm
ArcTanSusan has quit [Quit: ArcTanSusan]
jadewang has joined #sandstorm
bb010g has quit [Quit: Connection closed for inactivity]
natea has joined #sandstorm
joshbuddy has joined #sandstorm
<ocdtrekkie> This is cool: https://crushpaper.com/ Uses a Chrome extension though to do it's thing.
<ocdtrekkie> Would this make it possible to make a native Sandstorm shell? https://github.com/delight-im/Android-DDP
<paulproteus> kentonv: And you claimed you never see off-by-one errors! (w/r/t https://github.com/kentonv/node-capnp/pull/21/files )
darius has quit [Ping timeout: 276 seconds]
<XgF> Hmm, I'm really tempted to do a capnp-dart. Wonder how hard that will be...
<XgF> Have to go for the compiler flow (as opposed to the dynamic flow of things like node, python) though
<dwrensha> yes, do it!
<dwrensha> is dart always compiled to javascript?
<XgF> No, Dart can run on the Dart VM too
<XgF> (but not in a browser that way, well except for Dartium)
<XgF> Also, I spotted a thing you all may like in the dart:isolate package: Capability. Yes, in the correct sense of the word
<paulproteus> OK, well, I have seemingly made the installer-tests run using qemu, at the cost of making the VMs take like 5 minutes to boot.
<paulproteus> The actual tests don't take super duper long.
posix4e has joined #sandstorm
<posix4e> tried installing sandstorm on sandstorm
<posix4e> get a lot of 500s
<paulproteus> Yeah; sandstorm disables mount(2) inside the sandbox, but sandstorm needs mount(2) to create sandboxes.
<paulproteus> There's probably other reasons you can't sandstorm within sandstorm at the moment. It's been made to work before, but given the trade-off between enabling apps to use some of these system calls (which would enable Sandstorm-in-Sandstorm to do so), versus leaving them disabled, we're going to stick with leaving them disabled, unless kentonv changes his mind.
natea has quit [Quit: natea]
<posix4e> Although with a fresh install and my wildcard dns i have sandstorm working hooray!
<paulproteus> Hooray!
natea has joined #sandstorm
posix4e has left #sandstorm [#sandstorm]
darius has joined #sandstorm
natea has quit [Quit: natea]
darius has quit [Ping timeout: 265 seconds]
natea has joined #sandstorm
kamalmarhubi has quit [Remote host closed the connection]
joshbuddy has quit [Quit: joshbuddy]
<XgF> One bit of Dart sadness (JavaScript exhibits higher sadness): It's a massive PITA to do the xoring for defaults on floats
<kentonv> XgF: Are you implementing Cap'n Proto in Dart?
<XgF> kentonv: Yes, at least the message serialization
nickmeharry has joined #sandstorm
itscassa|away has quit [Ping timeout: 272 seconds]
jadewang has quit [Remote host closed the connection]
natea has quit [Quit: natea]
nickmeharry has quit [Remote host closed the connection]
natea has joined #sandstorm
nickmeharry has joined #sandstorm
natea has quit [Quit: natea]
<nickmeharry> Hey, I'm getting an error starting my Sandstorm instance. It was running fine, but after I downgraded kernels on my Linode to avoid issue #461, I'm getting this error:
<nickmeharry> That gist is the end of a reinstall. The same error was showing up in /opt/sandstorm/var/log/sandstorm.log as well.
natea has joined #sandstorm
<nickmeharry> For reference, I downgraded the kernel version to 4.0.1-x86_64-linode55 (which I understand to be free of the panic issue).
<paulproteus> jparyani: ^
<paulproteus> about to fork child process, waiting until server is ready for connections.
<paulproteus> forked process: 7
<paulproteus> ERROR: child process failed, exited with error number 100
<paulproteus> Is this more mongodb "the password is mistaken for an argument" thing?
<paulproteus> And hi nickmeharry and thanks for coming in and I hope we can solve your problem.
<paulproteus> nickmeharry: I wonder if your Mongodb password starts with a -
<paulproteus> Let me see if I can find the place for you to look.
<nickmeharry> I didn't change it, and it was working earlier.
<paulproteus> But this does seem to be a fresh install, which might have regenerated the password, from what I can tell?
<paulproteus> sudo cat /opt/sandstorm/var/mongo/passwd
<paulproteus> That should show you the password, anyway; if it starts with a hyphen, it's sort of bad news.
<paulproteus> nickmeharry: I have to go to lunch; will you be back in ~45 min?
<nickmeharry> It was fresh a few days ago. I tried to launch an app yesterday, and my Linode froze. I found the bug report today about the kernel panic, so I swapped that out and rebooted. Sandstorm did not come back up. I then tried to reinstall.
<paulproteus> s/back/still here/
<nickmeharry> Sure. I've got actual work to do as well.
<paulproteus> Cool (-:
<paulproteus> tty soon!
<nickmeharry> Mongo password: 4x7CZ-t_N03J1L9bqgE072CxJd6
<nickmeharry> Does not start with a "-", but does contain one.
<nickmeharry> Hmm, should probably not have pasted that in :/ Now to go change it.
<nickmeharry> Not that it really matters at the moment, since it's not even running.
natea has quit [Quit: natea]
natea has joined #sandstorm
natea has quit [Client Quit]
natea has joined #sandstorm
natea has quit [Client Quit]
natea has joined #sandstorm
prosodyContext has quit [Remote host closed the connection]
jksonc has quit [Remote host closed the connection]
fkautz has quit [Remote host closed the connection]
bpierre has quit [Remote host closed the connection]
<paulproteus> nickmeharry: Yeah... I wonder if it's the - in there.
<paulproteus> OK, apparently only - at the beginning is important.
<paulproteus> And never mind; Sandstorm apparently no longer cares about this.
<paulproteus> Error 100 is "Returned by mongod when the process throws an uncaught exception"
<paulproteus> So probably the thing to do is read /opt/sandstorm/var/log/mongo.log
<paulproteus> p.s. Thanks for being a good sport about this. I hope that whatever the cause is, we can fix it in
<paulproteus> Sandstorm and make sure it doesn't hit anyone else.
<kentonv> I've seen Mongo do this when there isn't enough free disk space
<kentonv> even though there's way more disk space than it needs
<nickmeharry> I've got 47% free on /
<paulproteus> Yeah, I'm hopeful the Mongo log will say something useful.
<kentonv> well unless you're on a 1GB drive that ought to be enough
jadewang has joined #sandstorm
<paulproteus> FWIW, if it _does_, maybe we can print out the last few lines of mongo.log if we can't figure out how to auto-fix this.
<nickmeharry> There's only 22 lines in mongo.log. Scanning it for private stuff first before posting the gist.
<paulproteus> Cool. Thanks nickmeharry.
<nickmeharry> Lines 10 and 11 look interesting
<paulproteus> OK, so I read those lines, and I think:
<paulproteus> "The more you know, the less you know."
<paulproteus> The kernel panic corrupted your mongo, I think.
<kentonv> wtf mongo
<kentonv> YOU HAD ONE JOB
<nickmeharry> Ok. I was hoping the reinstall would fix all that. Should I just rm -rf /opt/sandstorm first?
asmyers has quit [Ping timeout: 240 seconds]
<paulproteus> Looks like --nojournal could be added to the mongo argv
<nickmeharry> Seems like journaling is supposed to prevent stuff like that, though.
<nickmeharry> But then, I don't know Mongo specifically.
<kentonv> if you don't have any important data in Sandstorm, you can just delete, yeah.
<nickmeharry> Yeah, I hadn't gotten very far with it. Was going to try setting up a blog with Ghost, and that's what triggered the panic.
<nickmeharry> I'll remove and reinstall and see if it still fails.
<nickmeharry> brb
<XgF> Mongo: Not Atomic. Not Consistent. Not Isolated. Not Durable.
<paulproteus> nickmeharry: I kinda want you to 'mv /opt/sandstorm /opt/sandstorm.bk' and then one day figure out how we can auto-recover Sandstorm from this madness.
<paulproteus> Having said that, I don't know that we actually will.
<nickmeharry> Too late, sorry.
<nickmeharry> However, no error message at the end of the install, so that might've worked this time.
<nickmeharry> (fwiw, the Mongo password is different this time as well)
<paulproteus> np, nickmeharry
<paulproteus> I'm sad that happened to you.
itscassa|away has joined #sandstorm
<nickmeharry> Well that's new: "Error looking up DNS TXT records for host 'nickmeharry.sandstorm.io': queryTxt ENODATA"
<nickmeharry> And some more stuff afterwards.
<paulproteus> sandstorm vs. sandcats
<nickmeharry> Ohh, right. Typo in the setup it looks like.
<paulproteus> Is it a bad string that the install script outputted?
<nickmeharry> No, I just messed it up. Since I already registered the sandcats.io subdomain, it said enter "none", and then I typo'd the server hostname.
<paulproteus> Oh okay (-:
<nickmeharry> Ok, going to try installing Ghost now. If I suddenly disconnect, then I picked the wrong kernel version and have to start over.
<paulproteus> Good luck.
<nickmeharry> I run irssi on the same box.
<paulproteus> Also sorry about the kernel thing.
<XgF> kentonv: So, when will Sandstorm use a Real (TM) database? :P
<XgF> (Or at least a Safe (TM) database)
<paulproteus> I think the answer is, "When Meteor supports it."
<nickmeharry> Still here, but 502 bad gateway. Time for more nginx config fun.
<paulproteus> If you're lucky, 'sudo service nginx restart' is all you need.
<nickmeharry> Anyways, thanks for the help paulproteus and kentonv.
<paulproteus> Sure thing nickmeharry . If I ever meet you IRL, I feel like I owe you a beverage of your choice for your troubles.
<kentonv> Meteor supports other databases, but transitioning would require rewriting a lot of our code and doing some sort of migration which doesn't sound fun.
itscassa|away has quit [Ping timeout: 272 seconds]
<kentonv> if we're rewriting stuff, eventually I'd like to move away from Meteor server-side and instead have the client doing Cap'n Proto calls to a C++ or Rust server but that's a long way away
<nickmeharry> paulproteus: I'll keep that in mind :)
<XgF> nickmeharry: What mount options does the partition you had Sandstorm on have? Want to double check there are no crazy options in fstab which might "sabotage" Mongo :-)
<nickmeharry> XgF: /dev/xvda on / type ext3 (rw,noatime,errors=remount-ro)
<XgF> Hmm, looks sane
<nickmeharry> That's from mount. Dunno if there's somewhere else that could give more details. I'm not doing anything fancy with that, afaik.
<paulproteus> cat /proc/mounts # but that likely is the same
nwf has joined #sandstorm
<paulproteus> Howdy nwf
<nwf> EHLO
<nwf> As it turns out, asking my DSL modem for connection stats results in it crashing.
<nwf> This is... antisocial of it.
<paulproteus> Can this be done by an attacker, like by cross-site request forgery?
<paulproteus> Although I guess if you're exfiltrating some data from your home network, having the connection reset isn't clearly to your (the attacker's) advantage.
jksonc has joined #sandstorm
<nwf> It'd take some doing, but I think producing the string "root\n${admin_password}\nstats modem\n" to my modem's IP address on port tcp/23 would indeed do that.
<paulproteus> I guess you'd have to know the admin_password, which hopefully makes it hard.
<nwf> Hopefully.
<paulproteus> : D
natea has quit [Quit: natea]
fkautz has joined #sandstorm
kamalmarhubi has joined #sandstorm
<XgF> Woot: I can make a Capnp ListReader implement dart's List<T>. Even better, I can just pass straight through to the typed data specializations for primitives
bpierre has joined #sandstorm
prosodyContext has joined #sandstorm
<paulproteus> nickmeharry: Things are looking good for you then, it seems!
joshbuddy has joined #sandstorm
natea has joined #sandstorm
natea has quit [Client Quit]
<nickmeharry> paulproteus: Sorry, got pulled into a meeting. I'll circle back to this tonight. Sandstorm itself seems to be working.
<nickmeharry> And cat /proc/mounts gives this: /dev/root / ext3 rw,noatime,errors=remount-ro,barrier=0,data=writeback 0 0
<paulproteus> barrier=0 hmm
<paulproteus> I wonder if that's related; I forget what it means in great detail.
<paulproteus> Glad that Sandstorm is working for you , nickmeharry !
bb010g has joined #sandstorm
joshbuddy has quit [Quit: joshbuddy]
joshbuddy has joined #sandstorm
<paulproteus> Upgrading a server so I can run vagrant from Debian on it!
<paulproteus> Unpacking tzdata-java (2015c-1) over (2014j-0wheezy1) ...
<paulproteus> Yay newer util-linux!
<XgF> Hmm, I think I have enough of the "raw" layer of capnp.dart implemented I can start parsing things, so... lets hand compile schema.capnp
<iangreenleaf> Want to make sure I'm on track here. I'm trying to set up an unattended install of Sandstorm from source (so the user can store their configuration in the Ansible playbook and have it set up without interaction).
paroneayea has quit [Read error: Connection reset by peer]
<paulproteus> Hi iangreenleaf !
<paulproteus> Cool.
<iangreenleaf> I'm thinking I can find the env vars in the install script and run `make install` with those vars set, so it skips all the questions. That the best way?
<iangreenleaf> like so: `CHOSEN_INSTALL_MODE=1 make install`
<paulproteus> When you do 'make install', that will do a build from source, right?
<paulproteus> I wonder if you would you be better-off distributing a "Sandstorm bundle" and an "install.sh".
<paulproteus> I think using these environment variables is a pretty reasonable idea.
<paulproteus> I'm curious what sort of people will be using this Ansible playbook!
<paulproteus> One downside to what you're describing is that I don't know how you'd get Sandcats data entered in.
<iangreenleaf> Yeah, I haven't figured out the Sandcats piece just yet.
<paulproteus> In general I'm not sure what hostname you will have users use; it'll be important that whatever domain it is, there should be a wildcard DNS domain.
<iangreenleaf> Is there some way to do Sandcats sign-up out-of-band and have them stick their credentials in?
paroneayea has joined #sandstorm
<paulproteus> Yeah -- take a look at a fully-configured Sandcats-enabled install, and you'll find that there's a setting in /opt/sandstorm/ (I think SANDCATS_BASE_DOMAIN) whose presence is what causes IP address auto-updating to work.
<paulproteus> I can take a look in a moment, if that's helpful.
<iangreenleaf> Ok, thanks. I'll poke around it in a bit and see what I can figure out. Thinking first I'll try to get it set up with all the other config and just skip the Sandcats part. Then once that's working, circle back.
<paulproteus> +1
<paulproteus> It should be possible to start Sandstorm with a user-specific key set in /opt/sandstorm/var/sandcats/ and the right settings in /opt/sandstorm/sandstorm.conf , whenever you look into that part.
<paulproteus> But yeah, I hope you'll consider using install.sh rather than "make install", since (iirc) "make install" causes a source build, and I think that isn't necessary and might result in your users ending up with stuff we haven't released yet, which may or may not work.
<paulproteus> Also I'd love to hear more about who you imagine using these playbooks!
<iangreenleaf> My motivation for the playbook is so I can do a reproducible self-install to a VPS like DigitalOcean or whatever.
<paulproteus> ++
<paulproteus> If you want help publicizing it or anything, let me know.
<paulproteus> Doubly so if you hope others might use it!
<iangreenleaf> Awesome, I will definitely ping you once it's finished
<paulproteus> Probably "all" you need is a copy of install.sh pinned to when you created the playbook, and to know which bundle file you want to download, and a copy of sandstorm.conf to drop into place.
<paulproteus> This isn't something that I've tested very well, though, so if you run into issues, do let me know.
<iangreenleaf> I like Ansible, it's nice and simple and takes the boring and error-prone parts out of setting up server stuff
<paulproteus> I'm literally in the middle of making sure that install.sh has a test suite that we run frequently.
<paulproteus> So if we end up figuring out that there are some tests I can write to ensure we don't break what you are doing, then that'll make me happy!
<iangreenleaf> The reasons I gravitated towards `make install` are 1) More flexibility, you can choose a release tag or master or whatever SHA you want to pin
<iangreenleaf> 2) I guess it feels more transparent than curling install.sh
<paulproteus> Yeah; I guess I suggest you bundle a snapshotted copy of install.sh and use it to install a bundle file by URL.
<paulproteus> I just used the word "bundle" in the same sentence with two different meanings.
<iangreenleaf> Yeah, doing it that way could be alright. Though I'd then need to keep an eye on upstream changes and stay synced.
<iangreenleaf> Is there a way to request a specific build version from install.sh?
<paulproteus> I figure if you want it reproducible, then you need to pin to a specific Sandstorm version number you want to install.
<paulproteus> You can specify the URL to a "Sandstorm bundle" ; see ./install.sh -h
<paulproteus> That's the best way to pin to a specific version, I believe.
<paulproteus> Naturally I hope you'll enable auto-updates too, but that's separate.
<paulproteus> Oh, and actually you specify the _file path_ of a Sandstorm bundle, not the URL of a Sandstorm bundle.
<paulproteus> https://dl.sandstorm.io/sandstorm-$BUILD.tar.xz
<paulproteus> is the expression for a bundle URL, so you could e.g. look at the latest release number in git, remove "0." string, and you should be able to find that bundle version.
<iangreenleaf> You know, it occurs to me that since I'm pulling the GitHub repo with install.sh already, I could continue doing that and run the script from there. Might save the source compile and save me the trouble of staying up to date. I'll contemplate.
bb010g has quit [Quit: Connection closed for inactivity]
joshbuddy has quit [Ping timeout: 265 seconds]
joshbuddy has joined #sandstorm
decipherstatic has joined #sandstorm
darius has joined #sandstorm