<ocdtrekkie>
I'm kinda curious how this clocks 20 megs though.
<paulproteus>
You know, we should be like auto-Tweeting the new apps.
<paulproteus>
ocdtrekkie: It's meatier
<ocdtrekkie>
Probably.
<zarvox>
meatier-spk
<ocdtrekkie>
:D
<paulproteus>
vagrant-spk --stack meatier
<ocdtrekkie>
I am a little sad that it clocks 20 megs. But sometimes I use Etherpad grains for stuff stupidly simple for Etherpad.
<ocdtrekkie>
And this loads faster.
<ocdtrekkie>
(An Etherpad grain exists that contains nothing but 20x20x1, because I always forget what size my furnace filter is when I'm at the hardware store.)
<paulproteus>
: D
gopar has quit [Quit: Leaving]
<dwrensha>
we could probably shave off some Megabytes by not including niscud
<dwrensha>
it's like 10MB uncompressed, and not needed in this case because no migration is necessary
<dwrensha>
why did I capitalize "megabyte"?
simonv3 has joined #sandstorm
<kentonv>
we should compile niscud with -Os (optimize for size)
<kentonv>
maybe we could shed some dependencies, too
losvedir has joined #sandstorm
<zarvox>
today's weirdness: my libvirt VMs are pausing exactly 1 minute after being started up. And then refusing to unpause.
gopar has joined #sandstorm
jacksingleton has quit [Ping timeout: 250 seconds]
gopar has quit [Quit: Leaving]
mcpherrin has quit [Read error: Connection reset by peer]
<mrdomino>
is there any access to the sandcats.io DNS? i think i need to add an spf record for mailgun. root cause: want to send email as people from mrdomino.sandcats.io.
<paulproteus>
i,i more like mail gnu
<paulproteus>
So there currently isn't programmatic access to the sandcats.io DNS.
<paulproteus>
I can probably sneak a record into the database...
<paulproteus>
Maybe what I should actually do is expose a set SPF record API endpoint.
<paulproteus>
Doubly so since I want mailgun integration to just be a thing we offer.
<paulproteus>
I'd kind of rather have a /setmailgunspfrecord endpoint instead actually, since it'll probably be mailgun.
<paulproteus>
mrdomino: Out of curiosity, is the SPF record the same thing that everyone would have to add there?
<paulproteus>
That is to say, is it approximately safe if I do it for everyone?
<paulproteus>
oh whoa mrdomino nice reverse DNS you've got there!
<paulproteus>
Geez. Very impressive.
<mrdomino>
it is "v=spf1 include:mailgun.org ~all" but they also want you to set a smtp._domainkey.yourname.sandcats.io and i don't know if they use the same key for everyone
<paulproteus>
nod, interesting.
<mrdomino>
yeah, DO automatically does reverse DNS for you
<mrdomino>
digitalocean that is
<paulproteus>
Ya
<mrdomino>
they also insist (i.e. don't mark "optional") that you CNAME email.yourname.sandcats.io to mailgun.org
<paulproteus>
WHOA huh.
<paulproteus>
That's fascinating.
<mrdomino>
yeah that last one is a bit strange
<mrdomino>
they apparently are doing some click tracking
<paulproteus>
It's not obviously wrong but we should plan for it, at the very least.
<paulproteus>
You... don't happen to feel like submitting a patch to my janky Meteor+PowerDNS client cert authenticated dyndns system, do you...?
<paulproteus>
The fact that you want this reminds me of the fact that I do really want to do it for everyone.
<mrdomino>
lol, would love to but i have few spare spoons... dayjob is in insane crunch marathon at the moment
<paulproteus>
np
<paulproteus>
I think for now my answer is "no but file a bug".
<mrdomino>
right on, will do
<paulproteus>
github.com/sandstorm-io/sandcats
<paulproteus>
It used to be the case that if you didn't like our dyndns and were smart, you could presumably replace it easily enough.
<paulproteus>
I guess the HTTPS certs do make it harder to leave!
simonv3 has quit [Quit: Connection closed for inactivity]
<mrdomino>
for posterity: github.com/sandstorm-io/sandcats/issues/107
<mrdomino>
i am now setting up tor on this DO droplet. sandstorm already has me thinking of this as my own internet machine that i can do arbitrary cool things with.
simonv3 has joined #sandstorm
gopar has joined #sandstorm
home has joined #sandstorm
losvedir has quit [Quit: losvedir]
home has quit [Quit: Leaving]
jacksingleton has joined #sandstorm
gopar has quit [Remote host closed the connection]
simonv3 has quit [Quit: Connection closed for inactivity]
jacksingleton has quit [Ping timeout: 265 seconds]
larjona has joined #sandstorm
richard has joined #sandstorm
richard is now known as Guest52948
Guest52948 is now known as rchrd2
soulshake has joined #sandstorm
mort___ has joined #sandstorm
jadewang has quit [Remote host closed the connection]
dwrensha has quit [Quit: ChatZilla 0.9.92 [Firefox 41.0/20150917150946]]
jacksingleton has joined #sandstorm
jacksingleton has quit [Ping timeout: 256 seconds]
losvedir has joined #sandstorm
eternaleye has joined #sandstorm
<eternaleye>
Hey, just a heads up - it seems that ekam's bootstrap is subtly incorrect, though it can be fixed by a two-line change. Currently, in compiling intercept.so, it hardcodes "gcc". I'm on Exherbo, which since its multiarch migration _only_ has tuple-prefixed toolchains - altering the script to use "${CC}" fixes the issue.
<eternaleye>
Also, during the further build of sandstorm, GCC 4.9 barfs on -Wglobal-constructors, which is used unconditionally without checking if the compiler accepts it. Using tuple-prefixed clang works, but it may be worth fixing.
<eternaleye>
Another thing - is there a way to _constrain_ parallelism of ekam in the top-level sandstorm "make" command? Because it's thrashing my disk, and the instructions' blithe assertion of "(Note: You should not use -j, as we only use make as a meta-build system. The major components will utilize all CPU cores.)" is not helpful.
<eternaleye>
Ah, various rules also hardcode "nm", rather than using the (relatively) standard $NM
<eternaleye>
Ah, just compile.ekam-rule, it just printed it lots of times due to parallelism...
larjona has quit [Quit: Konversation terminated!]
<eternaleye>
g-f-p with one patch for each of the intercept CC issue and compile NM issue: http://ix.io/l93
cevi_ has quit [Ping timeout: 264 seconds]
cevi has joined #sandstorm
<eternaleye>
Also, it might be good for the sandstorm repo to use submodules, and the makefile can then do submodule init/update/etc if need be
<eternaleye>
Since that way, it actually pins the right commits and avoids skew
<eternaleye>
Since currently it's barfing about /ekam-provider/c++header/kj/async-inl.h:314:12: error: no matching function for call to 'from'
<eternaleye>
Which seems to be caused by the very newest capnproto commit
cevi has quit [Ping timeout: 244 seconds]
cevi has joined #sandstorm
cevi has quit [Ping timeout: 268 seconds]
<eternaleye>
Oh, no, I'd misread. The code that's exploding with that dates back to May...
<paulproteus>
Right now you can't "share by identity" which is to say you can only give out a "sharing link" by email, but it'd be nicer to add people specifically.
<paulproteus>
If that's not a showstopper, that's good. It means that participating in the Gerrit requires action from participants.
<paulproteus>
Similarly there's no built-in way to make, like, gerrit.yourorganization.com redirect to, or be, the Gerrit instance.
<mrdomino>
yeah, that's probably okay for now. the lack of shortlinks is a bit of a pain but i'm sure y'all are working on it.
<mrdomino>
like a mydomain.co/gerrit url would already be pretty rad
<mrdomino>
maybe that's even already there and i just haven't noticed how to do it yet
<zarvox>
One pretty significant limitation would be that we can't support git over SSH yet, and Gerrit by default has you clone/push/pull over that socket.
<mrdomino>
how hard is that to do?
<paulproteus>
Right, yeah. You can look at how e.g. GitWeb and Gogs use "offer templates" to generate special-purpose API tokens for each user which get used as git auth over HTTP(S).
<zarvox>
I don't know if gerrit supports push/pull over http(s).
<mrdomino>
like i guess a grain bogarting the SSH port is not exacly desirable?
<mrdomino>
oh, problem solved then...
<zarvox>
Yeah, generally, we don't let grains expose raw sockets to the outside world. Administrators can grant an "IpInterface" capability, but the UX for that is currently incomplete
<paulproteus>
Yeah, bogarting the SSH port isn't super desireable. If you are willing to live with HTTPS push, then I would go the offer templates route and see if you can make that work. If not, then you should get on a video call with Kenton until you design a SSH-comaptible object capability-pure access control strategy for SSH access to grains.
<zarvox>
and we'd probably want to have a sandstorm-ip-bridge or something
<paulproteus>
Which is honestly not going to be that hard IMHO it's just that no one has thought for 3 straight hours about it yet I think.
<mrdomino>
b
<zarvox>
I think the other Hard Part for exposing SSH to grains is the bit where if you're using publickey authentication it's not clear which grain you're supposed to be talking to
<mrdomino>
right short of just stupid username based segmentation or something
<zarvox>
oh, I guess we could randomize usernames. You provide the publickey, Sandstorm picks a random username...
bb010g has quit [Quit: Connection closed for inactivity]
<paulproteus>
"you provide the pubkey, Sandstorm decides the username" sounds like a deal on TV
<zarvox>
hahaha
<zarvox>
but seriously, I think you're right and that could work!
<paulproteus>
I'm imagining a photo of me and zarvox pointing at each other and grinning
<mrdomino>
or hell you could just reg the pubkey at the instance level and sandstorm picks a new username for each grain that wants one
<zarvox>
ssh driver app would store a list of (publickey, account-id, randomly-generated-username, grain-id)
<zarvox>
step one is do handshake with ssh client with any trusted public key
<paulproteus>
I still want this photo of zarvox and me pointing at each other and grinning though
<mrdomino>
yeah me too
<paulproteus>
Anyway I think your idea works.
<zarvox>
paulproteus: come to the office and maybe we can take one
<paulproteus>
b eta 1:35
<zarvox>
;)
isd has joined #sandstorm
isd has quit [Ping timeout: 246 seconds]
jadewang has quit [Ping timeout: 244 seconds]
jadewang has joined #sandstorm
<XgF>
paulproteus: I'd totally like a way to expose a grain's dynamic content on another domain/subdomain/etc
rchrd2 has joined #sandstorm
darius has quit [Ping timeout: 250 seconds]
<eternaleye>
mrdomino: zarvox: There's also the option of using SSH "Subsystem" functionality
<eternaleye>
mrdomino: zarvox: That's probably a better match for a grain regardless...
<rchrd2>
Hello. Are there any environment variables available to apps? In particular, I need to know what the serving domain is for this app. Eg something like 'myapp123.me.sandcats.io'.
NOTevil has quit [Quit: boing!]
isd has quit [Quit: Leaving.]
<paulproteus>
Hi rchrd2!
<paulproteus>
It's in the headers, not env vars.
<paulproteus>
Let me dig those up.
<paulproteus>
I don't see a mention of X-Sandstorm-Base-Path in the docs which shocks me.
<rchrd2>
Ah. Thanks. It'll be great if these ever make it into ENV so they can be used outside of the request/response cycle.
<paulproteus>
One problem with that is that the Base-Path is per-user.
<paulproteus>
It's convenient if you can get away with using the empty string as the base path, fwiw.
<paulproteus>
I'm pretty distractable today because HTTPS now seemingly works.
<rchrd2>
Awesome. Thanks for getting back to me so quickly. I have to step into meeting a 3pm. I'll try this out later and see if you're still distractable then.