<div dir="ltr"><div class="gmail_default"><div class="gmail_default"><font face="monospace, monospace">I made a few more modifications in the way that the uid/gid are set on Fuego</font></div><div class="gmail_default"><font face="monospace, monospace">(<a href="https://bitbucket.org/profusionmobi/fuego/commits/fe24e93ce191c461f4efa55aaa345a319b1b8fd6">https://bitbucket.org/profusionmobi/fuego/commits/fe24e93ce191c461f4efa55aaa345a319b1b8fd6</a>)</font></div><div class="gmail_default"><font face="monospace, monospace">and also made the needed changes on fuego-release-test to match those.</font></div><div class="gmail_default"><font face="monospace, monospace">Hopefully they're more robust now. I plan to send all the new changes by e-mail</font></div><div class="gmail_default"><font face="monospace, monospace">to the list, but I just wanted to check if you're able to run it locally, so</font></div><div class="gmail_default"><font face="monospace, monospace">that you can get a feeling about this, before we move on.</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">Can you please try again with:</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">```</font></div><div class="gmail_default"><font face="monospace, monospace">git clone <a href="https://bitbucket.org/profusionmobi/fuego-release-test">https://bitbucket.org/profusionmobi/fuego-release-test</a></font></div><div class="gmail_default"><font face="monospace, monospace">cd fuego-release-test</font></div><div class="gmail_default"><font face="monospace, monospace">./build_and_run -c up</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">Then try to access fuego in localhost:8080/fuego/</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">```</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">And check if things go well this time?</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">Can you please also provide info about the distribution you're using along with</font></div><div class="gmail_default"><font face="monospace, monospace">the docker version? I'll try to find out if there's any similar issue reported</font></div><div class="gmail_default"><font face="monospace, monospace">by other users.</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">Thanks for your help, Tim.</font></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 22, 2018 at 5:19 PM, <span dir="ltr"><<a href="mailto:Tim.Bird@sony.com" target="_blank">Tim.Bird@sony.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
> -----Original Message-----<br>
> From: Guilherme Camargo<br>
</span><span class="">> On Wed, Feb 21, 2018 at 10:19 PM, <<a href="mailto:Tim.Bird@sony.com">Tim.Bird@sony.com</a><br>
</span><span class="">> <mailto:<a href="mailto:Tim.Bird@sony.com">Tim.Bird@sony.com</a>> > wrote:<br>
><br>
><br>
><br>
><br>
> > -----Original Message-----<br>
> > From: Guilherme Camargo<br>
> ><br>
><br>
</span><div><div class="h5">> > Hello, Tim, thanks for trying it out again and thanks for your time<br>
> > in debugging this issue and providing logs.<br>
> ><br>
> > This problem is happening because we're not using fuego-host-<br>
> scripts<br>
> > in the derived fuego-release-test, what ends up resulting in the<br>
> > jenkins' user not being properly mapped to the host's user.<br>
> ><br>
> > That's my fault, I forgot that this would be required in the<br>
> > derivate image as well.<br>
> ><br>
> > I temporarily added that logic to build_and_run.sh (as a fixup<br>
> commit)<br>
> ><br>
> > so that you're able to test it out, please see the patch below:<br>
> ><br>
> > diff --git a/build_and_run.sh b/build_and_run.sh<br>
> > index e448ddf..0134759 100755<br>
> > --- a/build_and_run.sh<br>
> > +++ b/build_and_run.sh<br>
> > @@ -50,6 +50,25 @@ fi<br>
> ><br>
> > if [ "$1" = "up" ]; then<br>
> > if [ -v clean_start ]; then<br>
> > + # FIXME: We should provide a simpler way of mapping jenkins<br>
> uid with<br>
> > + # hosts uid, that does not require the user (that's extending<br>
> > + # fuego-base) to have this logic in his docker build.<br>
> > + #<br>
> > + # Jenkins' uid/gid should probably be given as a docker-run<br>
> variable<br>
> > + # (as http_proxy/https_proxy, and set properly through<br>
> fuego-base<br>
> > + # entrypoint.)<br>
> > + #<br>
> > + if [ "${UID}" == "0" ]; then<br>
> > + uid=$(id -u "${SUDO_USER}")<br>
> > + gid=$(id -g "${SUDO_USER}")<br>
> > + else<br>
> > + uid="${UID}"<br>
> > + gid=$(id -g "${USER}")<br>
> > + fi<br>
> > +<br>
> > + sed -i "s/HOST_UID/${uid}/" ./fuego-ro/conf/fuego.conf<br>
> > + sed -i "s/HOST_GID/${gid}/" ./fuego-ro/conf/fuego.conf<br>
> > +<br>
> > docker build -t "${fuego_rt_image}" .<br>
> > docker rm -f "${fuego_rt_container}"<br>
> > docker run -dit --name ${fuego_rt_container} \<br>
> > diff --git a/fuego-ro/conf/fuego.conf b/fuego-ro/conf/fuego.conf<br>
> > index 0c95eae..96cdcc9 100644<br>
> > --- a/fuego-ro/conf/fuego.conf<br>
> > +++ b/fuego-ro/conf/fuego.conf<br>
> > @@ -1,3 +1,3 @@<br>
> > -docker_jenkins_uid=1000<br>
> > -docker_jenkins_gid=987<br>
> > +docker_jenkins_uid=HOST_UID<br>
> > +docker_jenkins_gid=HOST_GID<br>
> ><br>
> > As I mentioned in my FIXME message, its undesirable to require a<br>
> derivate<br>
> > image to contain specific build steps (as the one that's replacing the<br>
> id into<br>
> > fuego.conf),<br>
> > so we might need to come up with a better approach to make this<br>
> work.<br>
> ><br>
> > The patch has already been pushed to<br>
> > <<a href="https://bitbucket.org/profusionmobi/fuego-release-test" rel="noreferrer" target="_blank">https://bitbucket.org/<wbr>profusionmobi/fuego-release-<wbr>test</a><br>
> <<a href="https://bitbucket.org/profusionmobi/fuego-release-test" rel="noreferrer" target="_blank">https://bitbucket.org/<wbr>profusionmobi/fuego-release-<wbr>test</a>> ><br>
> ><br>
> > <a href="https://bitbucket.org/profusionmobi/fuego-release-test" rel="noreferrer" target="_blank">https://bitbucket.org/<wbr>profusionmobi/fuego-release-<wbr>test</a><br>
> <<a href="https://bitbucket.org/profusionmobi/fuego-release-test" rel="noreferrer" target="_blank">https://bitbucket.org/<wbr>profusionmobi/fuego-release-<wbr>test</a>> (master).<br>
> > Can you please re-sync and test again?<br>
><br>
><br>
> The jenkins uid and gid in the container now match those of my host<br>
> user,<br>
> but I'm getting the same start failure as before.<br>
><br>
> Even when I explicitly change permissions in the path:<br>
> /var/cache/jenkins/war/META-<wbr>INF/MANIFEST.MF, I still<br>
> get the same (Permission denied) message shown in the log (as<br>
> below).<br>
><br>
> I'm not sure what to try next.<br>
> -- Tim<br>
><br>
><br>
><br>
><br>
> Thanks for helping, Tim.<br>
><br>
> I'm taking a closer look to understand why this is happening.<br>
<br>
</div></div>I'm not sure what is the root cause of this, and fear it might be a docker bug.<br>
I have some notes I made when I was first integrating ProFusion's<br>
changes to Fuego to start from a base docker container (on Feb 1).<br>
<br>
In my notes I describe the same permission problem with<br>
/var/cache/jenkins/war/META-<wbr>INF/MANIFEST.MF.<br>
<br>
In my notes it says:<br>
"changed permissions, and it worked"<br>
then later<br>
"changed permissions back, and it still works (docker fs bug??)"<br>
<br>
But I may have done something else, unrelated to the permissions,<br>
which I didn't take note of at the time.<br>
However, I'm pretty sure the current issue has the same root cause<br>
as what I was seeing before.<br>
<br>
Hopefully that's helpful information.<br>
-- Tim<br>
</blockquote></div><br></div>