Re: S2I with wildfly: keycloak adapter
Why do you think it doesn't support it. There should be no problem adding it. WHich part are you stuck on? Thanks Steve On Mon, Dec 4, 2017 at 10:11 PM, jelmer van amen wrote: > Hi, > > > > We’re migrating our software to OpenShift. We have a maven (well, actually > gradle, but we’re ok with moving to maven) J2EE war application secured > using keycloak adapter in a wildfly instance. > > > > We’d like to use s2i for this application. Our first guess would be > https://github.com/openshift-s2i/s2i-wildfly , but that does not (seem > to) support adding the keycloak adapter (http://www.keycloak.org/docs/ > 3.0/securing_apps/topics/oidc/java/jboss-adapter.html#_jboss_adapter). > > > > What would be the best way to go? > > > > Thanks! > > ___ > users mailing list > users@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/users > > ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
S2I with wildfly: keycloak adapter
Hi, We’re migrating our software to OpenShift. We have a maven (well, actually gradle, but we’re ok with moving to maven) J2EE war application secured using keycloak adapter in a wildfly instance. We’d like to use s2i for this application. Our first guess would be https://github.com/openshift-s2i/s2i-wildfly , but that does not (seem to) support adding the keycloak adapter ( http://www.keycloak.org/docs/3.0/securing_apps/topics/oidc/java/jboss-adapter.html#_jboss_adapter ). What would be the best way to go? Thanks! ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
RE: login debug?
Turns out I had incorrectly configured the origin/master/master-config.yaml file. I needed to have a full section for each identity provider. Duplicating from name down was silently taking the second set of inputs for the section without any error messages. Note: Turning debug up to max level didn't provide any insight into the problem. From: Brigman, Larry Sent: Thursday, November 30, 2017 1:13 PM To: 'users@lists.openshift.redhat.com' Subject: login debug? I had LDAP auth working with Active Directory. I didn't like the id mapping and decided to change it. I wiped out the old identities from the system and did a restart of the master service. Now I cannot login. Reverted my change on id attribute and restarted. Still cannot login. No errors anywhere. I have a second identity provider using htpasswd which still works as expected. oc version oc v3.6.1+008f2d5 kubernetes v1.6.1+5115d708d7 features: Basic-Auth GSSAPI Kerberos SPNEGO Server https://lab-stack1.lab.c-cor.com:8443 openshift v3.6.1+008f2d5 kubernetes v1.6.1+5115d708d7 This is similar to https://github.com/openshift/origin/issues/14506 but I did delete both the user and identity. Also new users from LDAP aren't being allowed in either. ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Re: GlusterFS Autoprovisioning with Heketi - Permission Problem/Question
Hi,
I found a possible solution/workaround for the problem:
one can use init containers to perform operations before the "real"
container is started...
https://docs.openshift.org/latest/architecture/core_concepts/pods_and_services.html#pods-services-init-containers
...
initContainers:
command: ['sh', '-c', 'chmod 0777 /var/lib/mysql/data']
image: busybox
imagePullPolicy: IfNotPresent
name: init
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /var/lib/mysql/data
...
On 21.11.2017 11:44, Andreas Germeroth wrote:
Hello,
we are new to OpenShift and are "playing" with it in our lab.
We have setup Openshift Origin 3.6 with a dedicated 3 node Glusterfs
storage (CentOS based) with distributed/replicated.
Due to the excellent documentation we have achieved to setup
autoprovisioning according to this guide here:
https://docs.openshift.org/latest/install_config/storage_examples/dedicated_gluster_dynamic_example.html
It works and the storage is automatically provisioned and can be used
in our pods!
But for instance if we use the MariaDB (Persistent) Template we run
into permission issues on the mounted glusterfs volume.
Even a privileged pod does not help.
The pod log:
mkdir: cannot create directory '/var/lib/mysql/data/mysql': Permission
denied
Fatal error Can't create database directory '/var/lib/mysql/data/mysql'
When I debug it in a terminal the permission problems occur as well:
sh-4.2$ ps waux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mysql 1 0.0 0.0 4316 352 ? Ss 09:47 0:00 sleep
3600
sh-4.2$ ls -la /var/lib/mysql/data/
total 8
drwxr-xr-x. 4 root root 4096 Nov 17 16:23 .
drwxrwxr-x. 3 mysql root 18 Oct 31 13:14 ..
drwxr-xr-x. 3 root root 4096 Nov 17 16:23 .trashcan
sh-4.2$ touch test
touch: cannot touch 'test': Permission denied
The Pod runs as mysql user and has no access rights to write here.
When I set the permissions manually outside the pod on the mount it
works, but that is not a good solution for autoprovisioning
... or run mariadb as root... not so good as well.
We have not found any possibility to set the permissions with heketi
or somewhere in the yaml.
So what is would be the correct solution here?
Thanks for your help!
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
