<polyfractal>
Hey all, i'm working on an app but having trouble with file permissions, locations, etc. the app downloads some tarballs in setup.sh, then I need to basically extract and move them to /var/foo. I've tried a number of combinations in setup.sh, build.sh and launcher.sh but inevitably run into some kind of permission issue
<polyfractal>
(launcher can't create the directories, or if setup untars, launcher can't access/see the files, etc)
<polyfractal>
any guidance on the best way to do this?
frigginglorious_ has joined #sandstorm
bemasc has quit [Ping timeout: 248 seconds]
bemasc has joined #sandstorm
frigginglorious has quit [Ping timeout: 250 seconds]
bodisiw has quit [Quit: This computer has gone to sleep]
bodisiw has joined #sandstorm
bemasc has quit [Ping timeout: 256 seconds]
bemasc has joined #sandstorm
sudoku__ has joined #sandstorm
notevil has joined #sandstorm
frigginglorious has quit [Quit: frigginglorious]
frigginglorious has joined #sandstorm
<dwrensha>
polyfractal: hi!
<polyfractal>
hiya dwrensha :)
<dwrensha>
dwrensha: I gather you are using vagrant-spk
<dwrensha>
dwrensha: setup.sh runs as root
<polyfractal>
ah, that explains some of the problems then :) what user does the build/launcher (and grain) run as? vagrant, or something else?
<dwrensha>
launcher.sh runs as a regular user, and so does build.sh, if I remember correctly
<dwrensha>
yeah, "vagrant"
<dwrensha>
if you need root in one of those scripts, using "sudo" would probably work
<dwrensha>
it won't require a password
<dwrensha>
but it'd be best to get all of the sudo'ing out of the way in setup.sh
<polyfractal>
oooh, ok. didn't know that was possible. or i could just chown the various directories to `vagrant` i suppose?
Lionel_Debroux has joined #sandstorm
<dwrensha>
yeah, chowning is a legit strategy
<polyfractal>
kk. related question, when does /var get created? e.g. can setup.sh move stuff into /var, or does that only get created when the grain launches?
<dwrensha>
ah
<dwrensha>
heh
<dwrensha>
the grain will see its own /var, distinct from the vagrant vm's /var
<dwrensha>
each new grain gets a new /var
<dwrensha>
so if you want to put something there, that needs to happen in launcher.sh or in some process that it launches
<polyfractal>
ah, that also explains some problems :)
<dwrensha>
it's common for apps to have first-launch logic
<polyfractal>
ok, so how about: setup.sh downloads some stuff, untars to /some/directory that's not /var, chown's it to `vagrant`, in launcher.sh those read-only directories are moved into /var of the grain?
<polyfractal>
(and probably some check for first-launch like you said)
<dwrensha>
does the app need to be able to modify those files?
<dwrensha>
if so, then yes, you need to copy them over to /var at some point
<polyfractal>
sorta. some of the sub-directories will need to be modified, but not all. so i could split it up so only the mutable ones get linked in, but it seemed simpler to just plop the whole directory into /var
<polyfractal>
(trying to setup a simple Elasticsearch + Kibana stack, if it's relevant :) )
<dwrensha>
yeah, that probably will be simpler
Telesight has joined #sandstorm
<dwrensha>
otherwise you will need symlinks
<polyfractal>
ok cool, i'll try it that way to start
<polyfractal>
thanks!
<polyfractal>
future question: i haven't gotten to this point yet, but is there a way for users to configure grains with custom settings? E.g. ES can be memory hungry, so users may want to increase the allocated heap size... but that'd have to happen before the grain is launched
<dwrensha>
currently only in an extremely coarse grained way...
<dwrensha>
your sandstorm-pkgdef can specify more than one "action"
<dwrensha>
where a `Manifest.Action` is a way to create a grain
<dwrensha>
all actions you specify show up in the Sandstorm UI for creating new grains.
<dwrensha>
e.g. Radicale has "create new calendar" and "create new addressbook"
<polyfractal>
ahh, i see. so it could be "create small" or "create large" as a coarse way to do it
<dwrensha>
yeah, but I think it would probably be better for you to make this configurable from within the app itself
<polyfractal>
does the grain run as the same user that runs launcher.sh? if that's the case, an extra admin panel may be able to restart the ES node and reconfigure it's heap size
<dwrensha>
I'm not sure I understand the question. launcher.sh is the entry point to the grain's code, so yes the grain runs as the same user.
<polyfractal>
poorly worded question, but that answered it for me :)
<polyfractal>
kk
<polyfractal>
(i just wanted to make sure the grain user had permissions to shutdown / restart processes started by launcher)
<dwrensha>
note that /proc will not be present in the sandbox, so you probably won't be able to do something like `killall`
<polyfractal>
yep, i can log a pid when it starts. discovered /proc limitation independently already though, part of Kibana's nodejs requires /proc so i'm attempting to spoof it via /fakeproc and source-map :)
<asheesh>
I have been eagerly waiting for an ELK package for some time :)
<polyfractal>
:D
<polyfractal>
scratching an itch, i've been wanting to consolidate server metrics/logs from across my various home and external machines, this seemed like a nice way to have a single point
evernite- has quit [Quit: ZNC 1.6.1 - http://znc.in]
<polyfractal>
ah, I wonder if ES is incompatible with sandstorm. ES tries to use seccomp itself, which i'm guessing isn't possible from inside a grain?
<polyfractal>
java.lang.UnsupportedOperationException: seccomp unavailable: CONFIG_SECCOMP_FILTER not compiled into kernel, CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER are needed
<zarvox>
Sandstorm applies a seccomp sandbox, which filters out seccomp.
<zarvox>
Is seccomp a hard requirement of ES?
<polyfractal>
yep :/ it's new in 5.0, but i dont see it going away. we use seccomp variously to help bolster java's security manager
<polyfractal>
iirc it's mainly used to prevent ES from calling execve(), fork(), and vfork(), under the assumption that there's a bug in the security manager. basically just a second-line of defense... but i dont see it going away or being configurable