[caasp-beta] Antw: Re: kubeconfig download error
Martin.Weiss at suse.com
Fri Dec 8 02:48:55 MST 2017
just to be sure to be sure - could you check the dex logs for the error you see, there?
(I ran into a similar issue recently where the SSL certificates for the LDAP server were not correct and I have seen that dex comlains about that..)
As before you have to use the beta list for communication.
I saw a couple of people like Martin send you a couple of suggestions I don’t know if these were followed (I didn’t see any further emails) but please give these a try.
I know there are a few other colleagues in SAP have set this up successfully (for Vora) so you might wish to check in with them for assistance.
I can only log support tickets for paying customers however as I mentioned before you are free to log a bugzilla as you did before. If that bug hasn’t yet had any progress on it you are welcome to add a comment to it asking for an update.
As before really emailing myself and other colleagues is going to make it harder for us to help and I’m not in a position to help anyway so please use the beta list and bugzilla as per the known process.
Sent from my iPhone - please excuse any shortness
> On 7 Dec 2017, at 16:29, Ns, Rushi <rushi.ns at sap.com> wrote:
> Hi Rob,.
> Do you have time , I still have the issue downloading the kubeconfig and I filed the bug. , however no solution yet from SUSE.
> Best Regards,
> I MAY BE ONLY ONE PERSON, BUT I CAN BE ONE PERSON WHO MAKES A DIFFERENCE
> On 12/7/17, 7:25 AM, "caasp-beta-bounces at lists.suse.com on behalf of Rob de Canha-Knight" <caasp-beta-bounces at lists.suse.com on behalf of rob.decanha-knight at suse.com> wrote:
> It’s also worth mentioning that we have privileged containers enabled within CaaSP so the vast majority of debugging containers should work without issue when you pass —privileged into the docker run command.
> As Martin points out we try to keep the security surface as small as possible by only installing the bare minimum needed to run containers. MicroOS is designed to only run containers and isn’t recommended for running any kind of binary or package so a debug container is the best approach IMHO.
> If you have a specific issue with a specific tool inside of a privileged debug container please let us know as we can definitely look into this and try and fix any compatibility issues that may arise.
> Sent from my iPhone - please excuse any shortness
>> On 7 Dec 2017, at 15:57, Martin Weiss <Martin.Weiss at suse.com> wrote:
>>>>>> An other approach for all that debugging purposes could be to use a special
>>>>>> docker image / docker container that delivers all the trouble shooting tools
>>>>>> required and run that with proper elevated rights..
>>> That is either complex, as the container has not all capabilities needed
>>> for proper debugging purposes, or a security nightmare, or most probably
>> Yes - there is security and complexity assigned - but installing all the required debug packages on all the servers might be even worse from a security point of view and they might not be even part of the CaaSP delivery channels.
>> Advantage of a debug container is that it can be added on demand and cleanup is fully automated.. when installing all the debug packages these are a security problem while they are installed and the also need to be upgraded / patched etc.
>> So both ways have their pros and cons ;-)
>> caasp-beta mailing list
>> caasp-beta at lists.suse.com
> caasp-beta mailing list
> caasp-beta at lists.suse.com
caasp-beta mailing list
caasp-beta at lists.suse.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the caasp-beta