-
Notifications
You must be signed in to change notification settings - Fork 447
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security Realm settings being reset on new rollout #1702
Comments
Thank you for opening an issue about this, we love it when our users share their enhancement ideas with us! I like where you are going with this idea, but am not in love with the implementation. I am open to any thoughts you might have about this implementation. Thanks! |
Thanks @coreydaley, that sounds great. Not exactly the same, but my first version was similar to your suggestion but I was worried about backwards compatibility and settled on this instead for it's conciseness. I'll put something together and post back here. |
I look forward to reviewing and collaborating on it |
Hi @coreydaley, I've been testing the various options based on your suggestion however it's not as straight forward as it appears. Firstly, I thought this was as clean as I could get it,
However, after testing, I realised that the regardless of what is set, if the OpenShift Login plugin is enabled, it will override what we configure if
Not as elegant as I was hoping. If the plugin worked in the opposite manner; it is active when These were the test scenario's I started with but abandoned them once I realised what was going on, with the plugin enabled.
It would be helpful to hear your thoughts on how to move this forward. |
I wonder if we could do something similar to this:
|
I had considered it but thought it might be a bit weird for the user having explicitly set the |
Hmmm, I am not seeing where anyone only using the OPENSHIFT_ENABLE_OAUTH env var would be affected by this change. Can you elaborate? |
bump |
Thanks for the bump, been wanting to get back to this. What I'm unsure about is the "side-effect" of changing the environment variable under-the-hood. If I set and environment variable, I expect it to be there as I set it. If we do it for the user as part of this, it could make it quite tricky to troubleshoot if you didn't know about this repository (which I didn't until I google'd my error message). Perhaps it's okay if we explicitly mention that it's being flipped because JENKINS_AUTH_PROVIDER variable has been set so if that's an acceptable solution, then happy to raise a PR. |
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
@openshift-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Having the same issue - can this be reopened? |
/remove-lifecycle rotten |
@larsknutson: You can't reopen an issue/PR unless you authored it or you are a collaborator. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Hi team,
We've noticed an issue with the s2i
run
script which causes ourSecurity Realm
to be wiped out whenever a new rollout is performed on OpenShift.We have a need to use LDAP auth instead of the OpenShift OAuth flow. With the current public image, we were finding the LDAP settings were getting lost intermittently. It wasn't until a new rollout was done out of hours that we could pinpoint when it was being reset, after a new rollout (when we did a graceful reboot of Jenkins via the Jenkins UI, we didn't lose the settings).
In the end, it comes down to this logic on line
590
injenkins/2/contrib/s2i/run
.It assumes when
false
is set forOPENSHIFT_ENABLE_OAUTH
, it should wipe the security realm tree inconfig.xml
.To make this work for us, we've updated this script to the following, that allows us to specify
alternative
which simply skips the block.If you're okay with this suggestion, I'm happy to raise a PR otherwise open to exploring alternative options.
The text was updated successfully, but these errors were encountered: