<paulproteus>
ckocagil: BTW your command line instructions things are way clearer than the ones for GitLab & Gitweb in Sandstorm. Thank you for making them so great.
<jacksingleton>
Does anyone know off the top of their head if it would be possible to create an AppArmor profile for sandstorm? I've just read here (http://www.insanitybit.com/2012/06/01/why-i-like-apparmor-more-than-selinux-5/) that the path based approach necessitates denying mount and namespace access, which I assume sandstorm needs.
<paulproteus>
Your goal is to jail Sandstorm itself, right, not the apps?
<ckocagil>
paulproteus: Thanks! I'm glad to hear that
<jacksingleton>
Yeah
<paulproteus>
jacksingleton: Sadly yeah, Sndstorm would need the ability to do mounts.
<paulproteus>
So I guess that means SELinux is the better route if you have to pick one.
<paulproteus>
It'd be pretty cool to do that, IMHO.
<paulproteus>
I would love to have docs on that for people who vaguely like Sandstorm but don't super-duper trust it.
<jacksingleton>
Yeah, we just found out that the SELinux default policies have not been brought over to Jessie though
<paulproteus>
Oh, interesting.
<paulproteus>
Arguably in your case you don't need any policies except the Sandstorm one that you write, though.
<jacksingleton>
Yeah I'm not actually sure how much work not having default policies would add
<jacksingleton>
I'm new to MAC systems in general
<jacksingleton>
We can do you one better re docs, we're planning to get some ansible scripts up on github
<fkautz>
oh, if you intend on using sandstorm on any fedora or rhel/centos system, you'll probably need selinux instead of apparmor. i don't think they come with apparmor
simonv3 has joined #sandstorm
<fkautz>
not that you can use sandstorm on a centos based system at this point... sandstorm relies on a newer kernel
<fkautz>
3.13 i think is the minimum required for sandstorm vs 3.10 on centos :x
<jacksingleton>
yup
<jacksingleton>
which is a bit of a shame as SELinux is much better supported on the redhat family
<paulproteus>
Yeah. Fedora, I wonder?
<paulproteus>
I just fixed an installer bug for Fedora users!
larjona has quit [Quit: Konversation terminated!]
<fkautz>
fedora is on 4.1.10
<jacksingleton>
I haven't heard of people running Fedora on servers, do they even have a server release?
<fkautz>
they do, it's a new thing
<fkautz>
they also have a cloud image
rustyrazorblade has joined #sandstorm
<jacksingleton>
seems like quite a lot of new stuff. ugh tradeoffs
<zarvox>
I've heard of people running current kernels atop Centos 5/6/7
<zarvox>
but there was some nontrivial porting effort involved
<paulproteus>
afk meeting
<jacksingleton>
zarvox: good to know… I think I saw there are more recent ones in http://elrepo.org/tiki/tiki-index.php - but I don't know much about Centos so not sure how solid that repo is and what the security update story is
<jacksingleton>
I want to find some kind of solution before we release SandForms (hopefully this month), and am about ready to hack around it which I think will require patching meteor-accounts-sandstorm ourselves
<zarvox>
Seeing multiple copies of the same app is definitely a bug, but do we want to keep the UserActions separate in the DB and uniq on the frontend, or should we dedup the UserActions collection?
<kentonv>
Hmm, depends on how much we care about restoring UserActions after unmerge, I suppose
larjona_afk has quit [Ping timeout: 246 seconds]
<kentonv>
if we consider unmerge to be a rare, disaster-recovery operation then it's not so bad to make the user re-install apps
<kentonv>
but de-duping in the front-end sounds relatively painless, too
<zarvox>
Yeah, I'm inclined to say the frontend should deal with it
<kentonv>
I guess another way to make un-merge work would be to leave the UserActions attached to the old account, and copy them over to the merged account iff the new account doesn't already have those actions
<zarvox>
oh yeah, if we just change userId to the new account, then there's no way to undo that migration
<kentonv>
indeed it looks like there's no identityId on UserActions
<kentonv>
which makes sense
<kentonv>
but means we can't expect to un-merge based on that anyhow
<kentonv>
so I think the answer is: on merge, we don't transfer UserActions, but we copy if the target account doesn't already have actions for that app
<zarvox>
and then the frontend does the right thing unmodified
<kentonv>
right
<zarvox>
I guess unmerge and autoupdates interact weirdly
<zarvox>
like, you may have grains that reference packages that you don't actually have userActions for
<zarvox>
I guess that's no different than the case now where you choose not to update grains but update the app
<kentonv>
right, that's always possible
<zarvox>
just with newer grains and older userActions instead of the other way around
<zarvox>
:q
<zarvox>
wrong window <_<
<paulproteus>
:wq
<dwrensha>
:wq!
<kentonv>
zarvox: you can get newer grains with older UserActions today by downgrading an app (Sandstorm refuses to downgrade grains).
<zarvox>
Yep, just got to that part of the testing checklist! :D
<zarvox>
also I'm maybe skipping all the admin stuff on testrock, since I'm not admin?
<paulproteus>
Maybe you can find a way _become_ admin!!
<dwrensha>
you're not admin you say?
<zarvox>
whelp, guess I am now
<zarvox>
darn
<dwrensha>
the UserActions behavior that kentonv described above is what I've actually implemented for accounts merging
<dwrensha>
i.e. old user keeps their actions
<dwrensha>
new user gets any that they didn't have already
<zarvox>
are you deduping by package ID, or (denormalized) app ID?
<dwrensha>
the demo user merging doesn't use my new code yet, though
jacksingleton has quit [Ping timeout: 246 seconds]
<zarvox>
because the "unique key" in classical database parlance would be on (userId, packageId), but you probably actually want to dedupe on appId in practice
<zarvox>
(this raises the question of whether tracking things by package rather than reference-to-app is actually useful)
<dwrensha>
well, we certainly need to know which package to run a particular grain with
<zarvox>
er, sorry, yeah, package is still needed
<zarvox>
I guess I mean tracking specific individual actions rather than reference-to-package (and package contains all the actions)
<zarvox>
this comes up because I already have to have the code to look up everything in the package to handle DevApps overriding apps, and I suspect users will have an easier time installing/removing/upgrading whole packages at a time, rather than specific actions
<zarvox>
so maybe we should just switch to launching new grains by package ID and action index everywhere, and then UserActions is really just UserPackages with (userId, packageId) tuples and maybe some denormalized info if useful
rustyrazorblade has joined #sandstorm
<paulproteus>
Waah why do I write such flakey tests.
<jparyani>
it may be just because that box is sad
<jparyani>
it has way too little ram for what we’re doing on it
<paulproteus>
Well that, and my sandcats tests are flaky.
<paulproteus>
I checked and it's the same reason though.
<paulproteus>
Travis-CI's OOM killer kills my things.
<jparyani>
:)
<paulproteus>
...so it works at non-peak hours, when there's less contention.