<russruss>
Hey, I’m curious if there’s a way for sandstorm to support something like a self-hosted irccloud, like https://www.irccloud.com - my understanding is that there are two problems - persistance, and access to the tcp port of the chat server (which maybe powerbox can handle now?). Am I wrong that the grain will be shut down at some point, so something like irccloud where it needs a persistant connection to another server wouldn
<russruss>
work?
Jan\ has quit [Ping timeout: 245 seconds]
Jan\ has joined #sandstorm
aggelos_ has quit [Ping timeout: 265 seconds]
aggelos_ has joined #sandstorm
vvalt has joined #sandstorm
<vvalt>
hi!
<vvalt>
could someone plz point me to a way of installing/running sandstorm side-by-side with a regular apache2 webserver?
<vvalt>
it seems I'm having multiple issues with port listeners etc.
<simonv3_>
russruss: I think there’s stuff in place for keeping grains up now
<simonv3_>
I know some of The Lounge people looked into hosting it on sandstorm but it was a bit too much effort
<simonv3_>
Don’t quite remember what the issues where. I think they hang out in #thelounge if you want to ask.
KooBaa has quit [Ping timeout: 260 seconds]
<zarvox>
powerbox-requesting IpNetwork will work on self-hosted Sandstorm and grant raw outgoing network access, which I think is what you'd need for The Lounge.
<zarvox>
That said, you'd have to speak tcp-over-capnproto or implement a TCP bridge, which is a big ask for most developers.
<zarvox>
While we do have wakelocks for keeping grains alive, they're not perfect - they don't persist across updates, and they don't autostart if the grain gets killed for any other reason. This may be perfectly acceptable, depending on your use case.
<russruss>
zarvox: any documentation about wakelocks?
<isd>
If you're using a different language, they may still be useful as a reference
<isd>
Though especially with the latter, be aware that it's not very well tested; It's been driven by the needs of irc-idler, so the other corners aren't as fleshed out.
<isd>
Hope that's helpful
mnutt_ has joined #sandstorm
<mnutt_>
I'm trying to publish some files with davros+sandstorm, and some of the filenames contain spaces. I would expect that I'd be able to access these, encoding the spaces as %20 but it doesn't seem to work. Is this expected?
jemc has quit [Ping timeout: 244 seconds]
<zarvox>
mnutt_: huh, looks like neither the node process nor the supervisor handles urldecoding the path
<zarvox>
mnutt_: would you like to file a bug, or should I? :)
<mnutt_>
I can do it, thanks
<zarvox>
just thinking out loud: it should probably be the supervisor that handles decoding the path before trying to open the file it serves
<mokomull>
Oh, dang, mounting the things for the grain (notably: the fuse filesystem that'll be its /) happens in an already-unshared mountns, doesn't it?
<mokomull>
(i.e. already unshared to mount /opt/sandstorm/sandstorm-version as a root) ... if I'm reading this right?
funwhilelost has joined #sandstorm
<zarvox>
Yes.
dwrensha has joined #sandstorm
<zarvox>
runServerMonitor() is the thing that launches the `spk dev` daemon; it calls enterChroot(true) at the top, which unshares the mountns
<mokomull>
zarvox: Yeah, I had just a 30 minute break to read through that. Things were abstracted so I couldn't tell what runs where.
fqtw has joined #sandstorm
<mokomull>
zarvox: I was slightly confused because FuseMount doesn't appear to actually be used in the "normal" case.
<zarvox>
there's a bunch of unsharing; I probably couldn't tell you what things share what namespace offhand
<zarvox>
Oh, yes, it's only needed for the dev mode tracing.
<zarvox>
Which is why Ubuntu 16.04 is fine for use in production, if you're not attempting to run `spk dev`
<zarvox>
(It's also a significant perf hit, so...another reason not to use it in the "normal" case)
<mokomull>
zarvox: I was trying to figure out where mount(... "fuse" ...) was called. It's already unshared from the initial-ns afaict, whereas the user's "spk dev" instantiation actually processes the I/O, while running in the initial-ns.
<mokomull>
zarvox: I also couldn't quite find any references to run-bundle.c++, yet.
<mokomull>
I understand that code must run somehow, I just missed it.
<zarvox>
run-bundle.c++ is the main entrypoint; see the KJ_MAIN macro on the last line
<zarvox>
Huh. I'd guess the answer is "yes", given that the issue was userns-specific.
dwrensha has joined #sandstorm
dwrensha has quit [Client Quit]
wolcen has joined #sandstorm
mnutt_ has quit [Ping timeout: 250 seconds]
dwrensha has joined #sandstorm
deviocitty has joined #sandstorm
<mokomull>
zarvox: dwrensha: the issue was _pid_ns specific.
<mokomull>
zarvox: Crap. I was looking at mount namespaces. I'm guessing the answer for pidns is similar, but ... I guess I'm going to double-check that work.
<mokomull>
Ok, yeah, the sandstorm daemon is running in a non-initial pidns too. Darn.
<mokomull>
Oh, huh. I think the I/O that makes it *immediately* fail with EIO is the read-the-manifest that happens like 10 lines after mounting FUSE in runDevSession -- that's why it *always* happens, rather than waiting for the application to do something.