No, just update the scl_enable on the ones that currently take advantage of
it so that the user is resolveable when you exec in.  Wouldn't touch the
ones that don't already do nss magic.


On Tue, Jan 19, 2016 at 11:12 AM, Honza Horak <hho...@redhat.com> wrote:

> Would that mean to install nss_wrapper into all images?
>
> Honza
>
> On 01/19/2016 05:05 PM, Ben Parees wrote:
>
>> That's a good point.  We do have the mechanism in place to do that.
>>
>> Michal, any objection to adding the NSS env definitions to our
>> scl_enable script?
>>
>>
>>
>> On Tue, Jan 19, 2016 at 11:02 AM, Mateus Caruccio
>> <mateus.caruc...@getupcloud.com <mailto:mateus.caruc...@getupcloud.com>>
>> wrote:
>>
>>     Yep, just tried centos images and it is working fine.
>>
>>     It took me a while to understand the whole thing. I was simply "oc
>>     exec-ing" into the pod, but those NSS vars are create by sti/run.
>>     It may be good if those vars would be available from any shell.
>>
>>     Thanks.
>>
>>
>>     *Mateus Caruccio*
>>     Master of Puppets
>>     +55 (51) 8298.0026
>>     gtalk: _mateus.caruc...@getupcloud.com
>>     <mailto:diogo.goe...@getupcloud.com>
>>     twitter: @MateusCaruccio <https://twitter.com/MateusCaruccio>
>>
>>     _
>>     This message and any attachment are solely for the intended
>>     recipient and may contain confidential or privileged information
>>     and it can not be forwarded or shared without permission.
>>     Thank you!
>>
>>
>>     On Tue, Jan 19, 2016 at 1:52 PM, Ben Parees <bpar...@redhat.com
>>     <mailto:bpar...@redhat.com>> wrote:
>>
>>         Ok, can you try the centos image (centos/python-34-centos7)?
>>
>>
>>         Honza:  do you know when the RHEL SCL python images(2.7 and 3.4)
>>         will be updated to fix the missing nss rpm issue?
>>
>>
>>         On Tue, Jan 19, 2016 at 10:27 AM, Mateus Caruccio
>>         <mateus.caruc...@getupcloud.com
>>         <mailto:mateus.caruc...@getupcloud.com>> wrote:
>>
>>             Yes, we are using rhel images.
>>
>>             Thanks!
>>
>>             *Mateus Caruccio*
>>             Master of Puppets
>>             +55 (51) 8298.0026
>>             gtalk: _mateus.caruc...@getupcloud.com
>>             <mailto:diogo.goe...@getupcloud.com>
>>             twitter: @MateusCaruccio <https://twitter.com/MateusCaruccio>
>>
>>             _
>>             This message and any attachment are solely for the intended
>>             recipient and may contain confidential or privileged
>> information
>>             and it can not be forwarded or shared without permission.
>>             Thank you!
>>
>>
>>             On Tue, Jan 19, 2016 at 1:15 PM, Ben Parees
>>             <bpar...@redhat.com <mailto:bpar...@redhat.com>> wrote:
>>
>>                 Yes there is a trick, documented here:
>>
>>
>> https://docs.openshift.org/latest/creating_images/guidelines.html#openshift-specific-guidelines
>>
>>                 see the section on "*Support Arbitrary User IDs" *which
>>                 describes how to use nss wrapper to work around this.
>>
>>                 That said, the openshift python image already does the
>>                 nss trick.  I think we had an issue with the rhel image
>>                 not containing the right package, are you using the rhel
>>                 image or the centos image?
>>
>>                 For the moment you might try the centos image if you
>>                 haven't already, until we get the rhel image updated.
>>
>>
>>
>>                 On Tue, Jan 19, 2016 at 9:53 AM, Mateus Caruccio
>>                 <mateus.caruc...@getupcloud.com
>>                 <mailto:mateus.caruc...@getupcloud.com>> wrote:
>>
>>                     Hi.
>>
>>                     Regarding openshift policy for safely running
>>                     images, it's recommended to disable scc for
>>                     unprivileged user. This may causes some issues while
>>                     reading from password database since EUID of the
>>                     running user is generated by openshift and can't be
>>                     found inside the container:
>>
>>                     bash-4.2$ pip install memcache
>>                     Traceback (most recent call last):
>>                        File "/opt/rh/rh-python34/root/usr/bin/pip", line
>>                     7, in <module>
>>                          from pip import main
>>                        File
>>
>> "/opt/rh/rh-python34/root/usr/lib/python3.4/site-packages/pip/__init__.py",
>>                     line 9, in <module>
>>                          from pip.util import
>>                     get_installed_distributions, get_prog
>>                        File
>>
>> "/opt/rh/rh-python34/root/usr/lib/python3.4/site-packages/pip/util.py",
>>                     line 16, in <module>
>>                          from pip.locations import site_packages,
>>                     running_under_virtualenv, virtualenv_no_global
>>                        File
>>
>> "/opt/rh/rh-python34/root/usr/lib/python3.4/site-packages/pip/locations.py",
>>                     line 96, in <module>
>>                          build_prefix = _get_build_prefix()
>>                        File
>>
>> "/opt/rh/rh-python34/root/usr/lib/python3.4/site-packages/pip/locations.py",
>>                     line 65, in _get_build_prefix
>>                          __get_username())
>>                        File
>>
>> "/opt/rh/rh-python34/root/usr/lib/python3.4/site-packages/pip/locations.py",
>>                     line 60, in __get_username
>>                          return pwd.getpwuid(os.geteuid()).pw_name
>>                     KeyError: 'getpwuid(): uid not found: 1000180000'
>>
>>                     How can I circumvent this obstacle? Should I rebuild
>>                     all sti scripts to include this user into the image?
>>                     There is any trick to allow passwd readers to read
>>                     from a mock?
>>
>>
>>                     Thanks,
>>
>>
>>                     *Mateus Caruccio*
>>                     Master of Puppets
>>                     +55 (51) 8298.0026
>>                     gtalk: _mateus.caruc...@getupcloud.com
>>                     <mailto:diogo.goe...@getupcloud.com>
>>                     twitter: @MateusCaruccio
>>                     <https://twitter.com/MateusCaruccio>
>>
>>                     _
>>                     This message and any attachment are solely for the
>>                     intended
>>                     recipient and may contain confidential or privileged
>>                     information
>>                     and it can not be forwarded or shared without
>>                     permission.
>>                     Thank you!
>>
>>
>>                     _______________________________________________
>>                     dev mailing list
>>                     dev@lists.openshift.redhat.com
>>                     <mailto:dev@lists.openshift.redhat.com>
>>
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>>
>>
>>
>>                 --
>>                 Ben Parees | OpenShift
>>
>>
>>
>>
>>
>>         --
>>         Ben Parees | OpenShift
>>
>>
>>
>>
>>
>> --
>> Ben Parees | OpenShift
>>
>>


-- 
Ben Parees | OpenShift
_______________________________________________
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Reply via email to