Is this change going to be required for all mesos installations that would run Myriad with remote distribution? I guess I'd like to respectfully challenge that notion that to use remote distribution we need to make a cluster wide change to all of our slave nodes that would require a restart of the mesos slaves. That seems to me to be quite a large requirement.
What's strange to me, is at one point I had this working without the that requirement, but I can't reproduce how I created the tgz to make it work. Where does the requirement to have the /tmp not be world writable come into play? This is seems like a strange requirement in that as a executor, it's world should start at the root of it's container. I.e. how does it even know that that it's parent directory has different permissions? Can we just just traverse frameworks up? If I had a command that said rm -rf ../../* would that work? Maybe I just didn't dig into what the sandbox was before this, but my thought that from the perspective of the executors / was, for example: /tmp/mesos/slaves/20151007-102829-1660987584-5050-15078-S5/frameworks/d9aab75d-1a74-489d-976d-805ce55364ff-0011/executors/myriad_executord9aab75d-1a74-489d-976d-805ce55364ff-0011d9aab75d-1a74-489d-976d-805ce55364ff-O18052420151007-102829-1660987584-5050-15078-S5/runs/70c6ba08-5c7a-4399-bf5a-34ac328e66e1/ as a ls of that directory shows me the unpacked tgz etc. How does the nodemanager know that the parent directories, specifically /tmp is world writable, and why does it care? I am not trying to be belligerent, I just want to understand this without just changing a cluster wide setting/restarting mesos. On Tue, Nov 17, 2015 at 1:53 PM, yuliya Feldman <yufeld...@yahoo.com.invalid > wrote: > Please change workdir directory for mesos slave to one that is not /tmp > and make sure that dir is owned by root. > There is one more caveat with binary distro and MapR - in Myriad code for > binary distro configuration is copied from RM to NMs - it doe snot work for > MapR since we need hostname (yes for the sake of local volumes) to be > unique. > MapR will have Myriad release to handle this situation. > From: John Omernik <j...@omernik.com> > To: dev@myriad.incubator.apache.org > Sent: Tuesday, November 17, 2015 11:37 AM > Subject: Re: Struggling with Permissions > > Oh hey, I found a post by me back on Sept 9. I looked at the Jiras and > followed the instructions with the same errors. At this point do I still > need to have a place where the entire path is owned by root? That seems > like a an odd requirement (a changed of each node to facilitate a > framework) > > > > > > On Tue, Nov 17, 2015 at 1:25 PM, John Omernik <j...@omernik.com> wrote: > > > Hey all, I am struggling with permissions on myriad, trying to get the > > right permissions in the tgz as well as who to run as. I am running in > > MapR, which means I need to run as mapr or root (otherwise my volume > > creation scripts will fail on MapR, MapR folks, we should talk more about > > those scripts) > > > > But back to the code, I've had lots issues. When I run the Frameworkuser > > and Superuser as mapr, it unpacks everything as MapR and I get a > > "/bin/container-executor" must be owned by root but is owned by 700 (my > > mapr UID). > > > > So now I am running as root, and I am getting the error below as it > > relates to /tmp. I am not sure which /tmp this refers to. the /tmp that > my > > slave is executing in? (i.e. my local mesos agent /tmp directory) or my > > MaprFS /tmp directory (both of which are world writable, as /tmp > typically > > is... or am I mistaken here?) > > > > Any thoughts on how to get this to resolve? This is when nodemanager is > > trying to start running as root and root for both of my Myriad users. > > > > Thanks! > > > > > > Caused by: ExitCodeException exitCode=24: File /tmp must not be world or > group writable, but is 1777 > > > > > > > > > > > >
