<div dir="ltr">Thanks!<div><br></div><div>For the scc issue, based on "This can cause problems for applications that expect to be able to look up their user ID.", I made an assumption that since named seemed to run happily as-is, perhaps it does not need to look up its own user ID.</div><div><br></div><div>How common is that? Should we assume that all apps might want to look up their user in /etc/passwd, unless proven otherwise? Is it a good idea to add the entrypoint logic in all cases?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 14, 2017 at 10:04 AM, Jason Montleon <span dir="ltr"><<a href="mailto:jmontleo@redhat.com" target="_blank">jmontleo@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't think your app container will run in a restricted scc unless you do the rest of the steps; specify the user numerically and create an entrypoint with the snippet of code they specified:<br>
<br>
"<br>
Because the user ID of the container is generated dynamically, it will not have an associated entry in /etc/passwd. This can cause problems for applications that expect to be able to look up their user ID. One way to address this problem is to dynamically create a passwd file entry with the container’s user ID as part of the image’s start script. This is what a Dockerfile might include:<br>
<br>
RUN chmod g=u /etc/passwd<br>
ENTRYPOINT [ "uid_entrypoint" ]<br>
USER 1001<br>
<br>
Where uid_entrypoint contains:<br>
<br>
if ! whoami &> /dev/null; then<br>
  if [ -w /etc/passwd ]; then<br>
    echo "${USER_NAME:-default}:x:$(id -u):0:${USER_NAME:-default} user:${HOME}:/sbin/nologin" >> /etc/passwd<br>
  fi<br>
fi<br>
"<br>
<br>
I think we've used a different variant of this as well:<br>
USER_ID=$(id -u)<br>
if [ ${USER_UID} != ${USER_ID} ]; then<br>
  sed "s@${USER_NAME}:x:\${USER_ID}:<wbr>@${USER_NAME}:x:${USER_ID}:@g" ${BASE_DIR}/etc/passwd.templat<wbr>e > /etc/passwd<br>
fi<br>
<br>
With additional ENV stuff set in the Dockerfile:<br>
ENV USER_NAME=www-data \<br>
    USER_UID=1001 \<br>
    BASE_DIR=/home/www-data<br>
ENV HOME=${BASE_DIR}<br>
<br>
<br>
apb base and mediawiki are two app containers maintained by us where we deal with this. It looks like apb-base entrypoint is using similar to the example in the docs you mentioned in the Dockerfile.<br>
<br>
<a href="https://github.com/fusor/dockerfiles/blob/master/mediawiki123:latest" rel="noreferrer" target="_blank">https://github.com/fusor/docke<wbr>rfiles/blob/master/mediawiki12<wbr>3:latest</a><br>
<a href="https://github.com/ansibleplaybookbundle/apb-base" rel="noreferrer" target="_blank">https://github.com/ansibleplay<wbr>bookbundle/apb-base</a><br>
<br>
Bind could be a nice neat example of multiple plans. One for caching only, another that sets up persistent storage and creates a ddns zone or zones, rndc key for managing it, etc.<div><div class="h5"><br>
<br>
On 12/13/2017 03:28 PM, Michael Hrivnak wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Because we don't have enough overloaded terminology, I decided to make my first APB install "bind", the DNS service. I would appreciate your review, and please don't hold back! I'm relatively new to openshift and ansible, so you can help me out by pointing out anything you would have done differently and why.<br>
<br>
<a href="https://github.com/mhrivnak/bind-apb" rel="noreferrer" target="_blank">https://github.com/mhrivnak/bi<wbr>nd-apb</a><br>
<a href="https://hub.docker.com/r/mhrivnak/bind-apb/" rel="noreferrer" target="_blank">https://hub.docker.com/r/mhriv<wbr>nak/bind-apb/</a><br>
<br>
One specific question came up. DNS traffic defaults to UDP, which limits my options for exposing the service externally. I went with the LoadBalancer approach, which assigns a dedicated IP from a pool of external addresses. Is that reasonable? Is there another option you would have used?<br>
<br>
I also hit some funny errors trying to expose both TCP and UDP on the loadbalancer service. I didn't try many iterations of it, but if you have a suggestion or idea, I'm all ears.<br>
<br>
Going through the exercise of making this has been very helpful for getting familiar with much of the stack. I appreciate everyone's help pointing me in the right direction.<br>
<br>
Thanks!<br>
<br>
-- <br>
<br>
Michael Hrivnak<br>
<br>
Principal Software Engineer, RHCE<br>
<br>
Red Hat<br>
<br>
<br>
<br></div></div>
______________________________<wbr>_________________<br>
Ansible-service-broker mailing list<br>
<a href="mailto:Ansible-service-broker@redhat.com" target="_blank">Ansible-service-broker@redhat.<wbr>com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/ansible-service-broker" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/ansible-service-<wbr>broker</a><br>
<br><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
-- <br>
Jason Montleon     | email: <a href="mailto:jmontleo@redhat.com" target="_blank">jmontleo@redhat.com</a><br>
Software Engineer  | gpg key: 0x069E3022<br>
Red Hat, Inc.      | irc: jmontleo<br>
desk: <a href="tel:978-392-3930" value="+19783923930" target="_blank">978-392-3930</a> | cell: <a href="tel:508-496-0663" value="+15084960663" target="_blank">508-496-0663</a><br>
<br>
______________________________<wbr>_________________<br>
Ansible-service-broker mailing list<br>
<a href="mailto:Ansible-service-broker@redhat.com" target="_blank">Ansible-service-broker@redhat.<wbr>com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/ansible-service-broker" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/ansible-service-<wbr>broker</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Michael</span> <span style="margin:0px!important;padding:0px!important">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Principal Software Engineer</span><span style="margin:0px!important;padding:0px!important">, <span style="margin:0px!important;padding:0px!important">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important">Red Hat</p></div></div>
</div>