simonv3 has quit [Quit: Connection closed for inactivity]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 240 seconds]
jacksingleton has quit [Ping timeout: 256 seconds]
<dwrensha>
heh, I'm using vagrant-spk to try to build an app that uses nix to handle dependencies, and I still end up getting errors like "Perl API version v5.14.0 of Nix::Store does not match v5.20.0 at /usr/share/perl/5.20/XSLoader.pm line 92"
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 246 seconds]
home has joined #sandstorm
jadewang has joined #sandstorm
jadewang_ has joined #sandstorm
jadewang has quit [Ping timeout: 260 seconds]
home has quit [Quit: Leaving]
<paulproteus>
dwrensha: In theory, theory and practice are the same. In practice, they are not.
achernya has joined #sandstorm
<paulproteus>
Or, also
<paulproteus>
"Even in the future nothing works"
home has joined #sandstorm
gemlog has joined #sandstorm
<gemlog>
I think the upvotes for the apps should be moved to the grains from the appstore. Easier and create more buzz.
<paulproteus>
ooh
<gemlog>
also, the dropdown menus I think should disapear rather than remaining floating, even though the frame underneath has updated.
<gemlog>
I'm not whining! I'm very happy playing around now :-)
<paulproteus>
(-:
<paulproteus>
You should consider emailing sandstorm-dev; most of us are asleep!
<gemlog>
I don't think I'm on that one. I'm on a really low volume one.
<paulproteus>
I should probably make that configurable, and use port 25 if available, huh.
<gemlog>
Have to read a bit more, but does the roundcube grain honour that too?
<paulproteus>
Ya
<gemlog>
You're kidding!
<paulproteus>
I haven't personally tried it, though.
<paulproteus>
But I understand people do use this.
<gemlog>
I will try this tomorrow!
<gemlog>
Honestly, the whole spf dkim song and dance and random deferrals are driving me crazy.
<paulproteus>
Yeah, but that's only for outbound.
<paulproteus>
Outbound is the hard part.
<paulproteus>
Inbound is easy, so we already have that working.
<zarvox>
I've done the SPF dance, but I've never bothered with DKIM.
<gemlog>
I /almost/ did dkim the last time goog started to randomly defer my mails for days on end, but I ended up not having to do it. Sometimes it goes on for a week and then stops for months.
<paulproteus>
gemlog: You should tell Nathan Willis <nwillis at glyphography.com> that you wrote a blog post earlier this year about installing Sandstorm, and send him a link, and you recently did the Sandcats thing and you were hoping LWN would write a review of Sandstorm and the integrated HTTPS stuff.
<paulproteus>
Nathan writes for LWN.net and I really want them to write about the Sandcats stuff!
<gemlog>
is carla still there? that's why I quit writing for them
<gemlog>
I guess I'm over it
<gemlog>
;-)
<gemlog>
I haven't added to the top about the new ssl thing yet. been busy.
<gemlog>
I might still have a login there even.
<gemlog>
I have it up in a tab for tomorrow.
<paulproteus>
Wow, awesome. Thanks!
<gemlog>
'it' was just my post.
bb010g has joined #sandstorm
<gemlog>
Nope. They lost my login. Too long ago.
<gemlog>
I'll submit though.
<gemlog>
what tz are you in A?
<paulproteus>
I'm in US Pacific
<gemlog>
me too, near Alaska in BC
<paulproteus>
Oh, neat!
<gemlog>
It is really :-) Spirit bears and stuff. Love it here.
<gemlog>
So does the spk thing-builder just do an strace and parse that?
<paulproteus>
It uses its own tooling for that, based on a FUSE filesystem that we wrote.
<gemlog>
I use it for mounting, but I have no idea how fuse works actually.
<gemlog>
This is a 'beyond me' area forever I think.
<gemlog>
It reminds me of school actually. One day we had a whole day on site surveying, selective fading, multi-path and so on.
<gemlog>
Maybe it was more than one day. Forget. I'm old ;-)
<gemlog>
At the end the prof said it was all to teach us that it wasn't our area :-) Pass it on up.
<gemlog>
That's all I'm ever doing here. Passing it on up.
<paulproteus>
OK, vagrant-spk taking forever to download Debian packages is kind of a pain.
<paulproteus>
Yay it loaded
<gemlog>
it's default mirror or .deb in particular?
<gemlog>
its
<paulproteus>
I'm not super duper sure why it's slow; if it's a default mirror problem, or what.
<paulproteus>
It'd be nice if the debs were predownloaded though.
<gemlog>
Well, I have to be up by 161300z, so I'm out.
<gemlog>
as long as they were throttled
<gemlog>
nite
<paulproteus>
bd
gemlog has quit [Quit: Konversation terminated!]
<paulproteus>
Good luck!
jadewang_ has quit [Read error: Connection reset by peer]
jadewang has joined #sandstorm
nander-zzz is now known as nander
Miriana-Tor has joined #sandstorm
Miriana-Tor has quit []
home has quit [Remote host closed the connection]
jadewang has quit [Remote host closed the connection]
bb010g has quit [Quit: Connection closed for inactivity]
mort___ has joined #sandstorm
<ckocagil>
paulproteus: Hi Asheesh yt?
nander has quit [Quit: No Ping reply in 180 seconds.]
nander has joined #sandstorm
zeroish has joined #sandstorm
ar-jan has joined #sandstorm
rysiek|pl has joined #sandstorm
<rysiek|pl>
ohai
<rysiek|pl>
so, here's a question from sandstorm newbie: is it possible to configure groups and manage users?
<rysiek|pl>
and provide group-based access to apps and documents within apps?
<XgF>
rysiek|pl: not yets
<rysiek|pl>
right. any plans?
<rysiek|pl>
or is sandstorm mainly geared towards single users?
<ckocagil>
rysiek|pl: not at all. you can share app instances with anyone you want and use sandstorm's access control.
<rysiek|pl>
I am thinking of using sandstorm in an organisation
nander has quit [Quit: No Ping reply in 180 seconds.]
<rysiek|pl>
that means I as an admin need a decent way of:
<rysiek|pl>
- granting and revoking group access to apps
<rysiek|pl>
- granting and revoking group access to documents within apps
<rysiek|pl>
- granting and revoking particular users' access to apps/documents
<ckocagil>
"To fund Sandstorm’s development, we will be also starting a separate project – codenamed “Blackrock” – aimed specifically at building tools to maintain large Sandstorm clusters integrated with common enterprise-oriented infrastructure (such as Active Directory). Some of this may not be open source, but if it turns out that a feature of Blackrock is of interest to the community at large, we will look to move that code into Sandstorm
<ckocagil>
proper."
<rysiek|pl>
regardless of users' will of sharing a particular app/document ;)
nander has joined #sandstorm
<rysiek|pl>
right!
<ckocagil>
rysiek|pl: if you want to hear more about the enterprise stuff, you'll have to ask kentonv or anyother person who works at sandstorm
<rysiek|pl>
right, thanks
<rysiek|pl>
will Blackrock be FLOSS too?
<rysiek|pl>
or should I ask kentonv et all about that too?
<rysiek|pl>
*et al
<ckocagil>
Kenton said it was a possibility in that old blog post
<dwrensha>
rysiek|pl: how do you imagine a "group" being defined?
<dwrensha>
does the admin select the members?
<dwrensha>
or is it tied to an authentication method somehow?
<rysiek|pl>
dwrensha: as an admin, I'm gonna say "LDAP"
<rysiek|pl>
and auth method would be tied to LDAP (LDAP bind, preferably)
<rysiek|pl>
that would allow the admins to use all LDAP-related goodness (tools, best practices, etc)
<rysiek|pl>
but yeah, if that's outside of scope of sandstork, I'm gonna ask kentonv about that later
<dwrensha>
I think everything you mention is within scope of Sandstorm
<rysiek|pl>
cool
ar-jan has quit [Quit: Leaving.]
mort___ has quit [Quit: Leaving.]
<dwrensha>
(But note that I consider the "scope of Sandstorm" to include Blackrock, which might be somewhat misleading, because Blackrock in proprietary.)
<dwrensha>
In any case, we lots ideas and plans for improving the sharing model in Sandstorm.
<rysiek|pl>
ah. well, that does clear things up considerably
<dwrensha>
We also have lots of enterprise-y features we want to add
<dwrensha>
it's a bit unclear where we'll draw the line on some things
mort___ has joined #sandstorm
mort___ has quit [Quit: Leaving.]
mort___ has joined #sandstorm
natea has joined #sandstorm
natea has quit [Quit: natea]
natea has joined #sandstorm
natea has quit [Remote host closed the connection]
natea has joined #sandstorm
natea has quit [Quit: natea]
mort___ has quit [Quit: Leaving.]
mort___ has joined #sandstorm
mort___ has quit [Client Quit]
xet7 has quit [Ping timeout: 240 seconds]
larjona has joined #sandstorm
mort___ has joined #sandstorm
mort___ has left #sandstorm [#sandstorm]
bb010g has joined #sandstorm
GeorgeHahn has joined #sandstorm
<paulproteus>
Hi ckocagil In a few minutes I have to go to my birthday party!
<paulproteus>
Hi rysiek|pl Do consider emailing support@sandstorm.io with your desires, fwiw.
ErikJJ has joined #sandstorm
ErikJJ has quit [Client Quit]
<rysiek|pl>
paulproteus: happy birthday! :)
<rysiek|pl>
and thanks, will probably do
<paulproteus>
Thanks! And great!
<paulproteus>
To be specific about your requests here, fwiw, since I do have a sec:
<paulproteus>
" - granting and revoking particular users' access to apps/documents" -- this does indeed work right now, and it's really fun to test out, imho.
<paulproteus>
You can make two accounts on e.g. oasis.sandstorm.io, share a doc with that one, then look in the sharing interface for "See who has access" (or similar) and then revoke them, and their access vanishes.
<paulproteus>
"- granting and revoking group access to apps" - As David said, there's no concept of groups yet.
<paulproteus>
As for "- granting and revoking group access to documents within apps" , Sandstorm has separate access control for each document within an app.
<paulproteus>
In that sense, there is no (current) revoking of access to an app, but there is definitely revoking access to a document.
<paulproteus>
In the Sandstorm model, if someone creates a new document, but it has no privileged information, we don't particularly have an admin-level way to revoke that at the moment.
<paulproteus>
e.g. If you have a shared todo list with someone, and you revoke their access to that, that's doable.
<paulproteus>
But you can't (currently) stop them from making new todo lists themselves.
<paulproteus>
If you take our view, that's not a security issue, since it's not like creating a todo list by itself creates risk. So (e.g.) after you revoke their work shared todo list on the day they're fired, they could use still make (e.g.) make a new TODO list for how they'll empty out their desk, and then after they leave, you'd be able to remove their account (which does already work).
<paulproteus>
"on the day they're fired" by this I mean "on (for example) the morning they're fired"
<paulproteus>
So in that sense, it's documents (aka app instances, aka grains) that we care about controlling access to, although some apps really just have one meaningful grain.
<paulproteus>
I should write this up somewhere, clearly.
<paulproteus>
Anyway, rysiek|pl, let me know if that's helpful, and if you're willing to email support@, that'd be great.
jacksingleton has joined #sandstorm
<rysiek|pl>
paulproteus: I am talking about granting/revoking access by admins, not by users themselves
<paulproteus>
If the admin happens to own the thing that got shared with the user, then that's straightforward.
<paulproteus>
But I see now -- you want the admin to be able to handle revocation even if they aren't the one who created the grain.
<rysiek|pl>
but that would mean that admin would have to own everything
<rysiek|pl>
yes
<paulproteus>
++
<rysiek|pl>
there might be several admins
<rysiek|pl>
and there needs to be a way to handle groups
<rysiek|pl>
well, anyway
<rysiek|pl>
much appreciate the time you took to answer :)
<rysiek|pl>
I'm also looking at yunohost and arkos, but these seem... problematic as we have dedicated servers that we do not have [hysical access to
<paulproteus>
You're welcome. Thanks for spelling out what you're after.
<rysiek|pl>
and the security model seems lacking
<rysiek|pl>
so currently we're throwing something together with docker
<rysiek|pl>
which is not ideal (user namespaces would be great) but it's better than nothing
<rysiek|pl>
anywhoo
<rysiek|pl>
have a great party :)
<paulproteus>
Thanks! And I hope you'll briefly email us right now so we don't lose touch, and I can think about this more post-party.
<paulproteus>
support at sandstorm.io / ciao!
<rysiek|pl>
ack, ciao
<kentonv>
rysiek|pl: "organizational access control", in which the admin can control and audit access to other people's docs, and set policies (like "no sharing outside the organization"), is the kind of thing we plan to put in Blackrock.
<rysiek|pl>
right
<rysiek|pl>
Blackrock is going to be closed-source, right?
<kentonv>
most likely, unless we can figure out some other workable business model around it
<kentonv>
I don't like the idea of wring closed-source code, but selling software aligns priorities better than a lot of other models. E.g. a "support" model would encourage us to make blackrock harder to use so that people have a reason to pay us for support.
<kentonv>
is open source a requirement in your case?
<rysiek|pl>
yes
<rysiek|pl>
if Blackrock were FLOSS I would be able to contribute time to it
jacksingleton has quit [Ping timeout: 244 seconds]
larjona has quit [Ping timeout: 240 seconds]
larjona has joined #sandstorm
exius has joined #sandstorm
<exius>
Hey
<dwrensha>
exius: hi!
<exius>
dwrensha: hello
<exius>
i'm looking for some help getting my self-hosted domain to work. it seems i'm missing something
<dwrensha>
where are you hitting touble?
<dwrensha>
*trouble
<exius>
first, i spun up a linode w/ 4.1.5-x86_64-linode61 kernal and centos 7. then, i ran the curl installer. i was able to access my subdomain through sandcats.io and create an admin account via github o_auth.
<exius>
i could add grains and use them, but later I found out i could use my own domain by changing the /opt/sandstorm/sandstorm.conf file. so i tried to do so, but it didn't work. i tried running the installer again, but this time entering "none" into the sandcats.io prompt, then filled out the domain and wildcard domain, etc. and confirmed to reuse th
<exius>
e same installation, it still didn't work.
<dwrensha>
are you willing to show me what's in your sandstorm.conf file?
<exius>
sure
<exius>
oooookay, so i finally got my domain working with sandstorm. it just had to strictly follow the template used for when generating sandcats.io subdomain config file but comment out the last line.
<exius>
i have actually come across a different issue now.
<dwrensha>
I'm curious what that last line was.
<exius>
a previously added Wordpress grain won't startup. and new ones cannot be started up on initial boot.
<exius>
#SANDCATS_BASE_DOMAIN=sandcats.io
<dwrensha>
can you successfully start any grain?
<exius>
nope, i cannot start any grain
<dwrensha>
any errors in /opt/sandstorm/var/log/sandstorm.log ?
<dwrensha>
or in your browser console?
<kentonv>
most likely a problem with wildcard dns
<exius>
i can access the app market and download and install apps, but when i try adding the grain, it doesn't get anywhere
<kentonv>
yeah, that usually indicates that the wildcard host is not working properly
<kentonv>
the grain interfaces are served from randomly-generated hosts in the wildcard
<kentonv>
typically either wildcard DNS is not set up or, when using SSL, it could be that the certificate isn't a wildcard cert or doesn't cover the correct wildcard
<kentonv>
if you're willing to share your WILDCARD_HOST value I can help debug
<exius>
here's a print of tail -n 50 /opt/sandstorm/var/log/sandstorm.log...
<exius>
at Object.Future.wait (/programs/server/node_modules/fibers/future.js:398:15)
<exius>
at waitPromise (app/server/proxy.js:124:35)
<exius>
at maybeAuditArgumentChecks (packages/ddp/livedata_server.js:1617:1)
<exius>
at packages/ddp/livedata_server.js:648:1
<exius>
at [object Object]._.extend.withValue (packages/meteor/dynamics_nodejs.js:56:1)
<exius>
at [object Object].Meteor.methods.keepSessionAlive (app/server/proxy.js:302:7)
<exius>
at packages/ddp/livedata_server.js:647:1
<exius>
at [object Object]._.extend.withValue (packages/meteor/dynamics_nodejs.js:56:1)
<exius>
at [object Object]._.extend.protocol_handlers.method (packages/ddp/livedata_server.js:646:1)
<exius>
at packages/ddp/livedata_server.js:546:1
<exius>
that repeats 3-4 times
<exius>
i actually don't have a wildcard ssl installed
<kentonv>
are you trying to access sandstorm over HTTPS?
<kentonv>
or just HTTP?
<exius>
i do have my wildcard dns working though, try pinging anything.firelite.net
<kentonv>
ah hah, I see the problem
<exius>
my admin area is all http://
<kentonv>
you should remove :6080 from your WILDCARD_HOST, since you're actually running on port 80
<exius>
i get ERR_CONNECTION_REFUSED for https://
<exius>
kentonv: you're spot on! after removing :6080 it worked
<kentonv>
yay
<exius>
thanks man!
<kentonv>
unfortunately if you want SSL you'll need to buy a wildcard certificate, which is expensive ($100-ish)
<exius>
and thanks to dwrensha too
<kentonv>
(or switch back to sandcats where it's free)
<kentonv>
no problem, let us know if you have any other issues
<exius>
is it possible to use a built-in wildcard SSL?
gemlog has joined #sandstorm
<exius>
with ssl errors of course
<exius>
or warnings*
<kentonv>
what do you meant "built-in"?
<kentonv>
mean*
<kentonv>
you can use a self-signed certificate which you manually load into your browser certificate store and set as trusted
<exius>
using self-signed SSL certificates
<exius>
would sandstorm be able to generate a self-signed cert?
<gemlog>
@paulproteus just saw a *really* nice oauth login at discuss.erpnext.com , you should check it out. Allays all worries about what is shared and gives more control to user, but is still very simple.
<kentonv>
(the instructions say sandcats but are not specific to sandcats; in fact they're now obsolete for sandcats. We should probably fix that.)
<exius>
gotcha
<gemlog>
Not only is it cumbersome to implement, but even your closest friends will be terrified by the errors and warnings thrown by their browser.
<exius>
nginx doesn't seem to be an active service on my machine
<gemlog>
I have done it a few times.
<gemlog>
They switched from nginx
<exius>
do you know which webserver sandstorm is using now?
<kentonv>
exius: you'll need to install it separately; it's not bundled with sandstorm
<kentonv>
sandstorm never actually used nginx
<kentonv>
it was just suggested as something you could set up in front of sandstorm
<kentonv>
it's still probably the best way to go if you want to set up your own ssl
<gemlog>
right. but it was in the old docs
<kentonv>
this does mean you'll want to move Sandstorm back to port 6080 so that nginx can take port 80
<exius>
ohh i see
<exius>
sandstorm is essentially its own webserver
<gemlog>
no way I'd mess with my own ssl. so awesome that sandstorm now works behind nat.
<gemlog>
with ssl
<exius>
i have to get used to that idea
<gemlog>
which?
<exius>
that sandstorm is kinda like a webserver in itself
<gemlog>
I like to think of it as a 'wrapper'
<kentonv>
sandstorm is built on node, but yeah, you can't share its web server with other non-sandstorm things
<kentonv>
this is actually typical for node-based things, but pretty different from the old CGI / PHP / etc. world
<gemlog>
I feel like a dinasaur ;-)
<exius>
i love the idea and how oasis even offers an easy way to spin up new accounts.
<gemlog>
I find it difficult to explain what it is to people.
<exius>
is the customer quota/accounting feature in oasis proprietary or open source?
<kentonv>
exius: Oasis is based on Blackrock, which will be the "enterprise" version of Sandstorm. Unfortunately we haven't thought of a way to open source it and still make money.
<kentonv>
the quota enforcement is currently based on the Blackrock-specific storage stack
<kentonv>
gemlog: yeah, we find it surprisingly difficult too. :/
<gemlog>
I think it's the dual meaning of sharing involved. i.e. sharing the server to install your own server(s) and sharing an instance (grain) of a server... It's just too meta.
<gemlog>
Since you're here... about the recent worries over DH primes and the sandstorm rotating keys?
<kentonv>
gemlog: embarrassingly (to me at least), we actually don't support DHE (nor ECDHE) in the first place, because we're on Meteor which is stuck on the 0.10 branch of Node which does not support either.
<exius>
kentov: that's totally fair. you guys are spearheading something phenomenal which should come with incentives for you guys to continue this path.
<exius>
you reap what you sow
<kentonv>
gemlog: as soon as we can get on a version of node which can do [EC]DHE (aka forward secrecy), we'll make sure that we use unique DH params
<gemlog>
I'm not performing banking transactions or similar, that's totally fine, but good to know. ... and you already answered my next question. Thanks.
<kentonv>
fwiw sandstorm.io itself (and oasis, etc.) has this configured correctly. :)
<gemlog>
I'm a bear of very little brain and didn't even convieve of ppl reusing primes until the news this past week. Good to know you guys are on top of it. I see sandstorm as a very Big Thing for folks.
<kentonv>
exius: thanks. We're trying to stick to the rule that any feature useful for a personal or small-group server (where either there's only one person with rights to create files, or a small number of people presumed to be trusted friends) will be open source. That way the ideal future where everyone has their own personal server does not rely on any proprietary code.
<gemlog>
However, we are still stuck with exius' original problem of self-signing. Even sandstorm is beholden to a CA.
<gemlog>
ultimately
<exius>
lol yeah. the hierarchy of the internets
<exius>
interwebs
<kentonv>
I'm hopeful that capability-based security can make web-of-trust-like authentication more usable, but that's definitely experimental and long-term
<kentonv>
if every time you send a link to someone, the link included the target host's public key, then you wouldn't need CAs
<kentonv>
(though by "every time" I mean even when you're speaking a domain name aloud or printing it on a billboard)
<gemlog>
thinking...
<gemlog>
yes
<gemlog>
it could be just another field
<gemlog>
you'd still need a directory though no?
<gemlog>
and that would get you back to a defacto ca
<kentonv>
CA's prove that "this site is associated with this domain", but that doesn't imply trust unless you trust the domain a priori. Trust in a domain comes from having been introduced to it by other people, advertisements, etc. -- so if all those things came with keys, then the CA is not doing anything useful.
<gemlog>
brb
<kentonv>
well it's much easier to build a system addressed by keys rather than names, since there's no race to get the best keys.
<kentonv>
you don't need a centralized trusted authority involved
<gemlog>
[CA's prove that "this site is associated with this domain"] just so. And as you point, the only other way is by a 'web of trust'. I have zero pgp/gpg keys signed by others.
<gemlog>
It keeps coming back to an authority
<kentonv>
when I say "web of trust" I don't mean PGP specifically, just the general idea that you trust things because you heard about them from other sources you trust
<gemlog>
Me too
<gemlog>
There's just a dearth of private auth.
<kentonv>
in the "real world" (outside of cryptography or even computers), web of trust happens all the time. We just aren't capturing it very well with our current PKI
<gemlog>
I agree.
<gemlog>
It's just the case that we do NOT sign friends keys -- heck most people don't even have keys or know why to sign or not.