OKD 3.11 pull from external registry and image stream
Hi All, We are checking our helm configuration to deploy the images taken from an external registry. We put into the image stream config and deployment config the link to external registry but the image has been deployed without fhe image stream update. Is it correct this behavior? Thanks, Marcello ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
OKD 3.10: import image from private repo helm
Hi All, we are trying to configure our DC managed by helm to permit the download via imagestream from a private repository hosted on Nexus. Actually we configured the YAML image stream definition like this: kind: ImageStream apiVersion: image.openshift.io/v1 metadata: name: nginx-porting namespace: "dummy-dev" labels: application: "nginx-porting-dev" spec: dockerImageRepository: "nexus.local:8187/application/nginx-porting" tags: - name: latest We noticed that the image stream can't resolve and pull the image but we didn't find some logs to perform the analysis. The are some documentation or tips related to this type of configuration? Thanks in advance, Marcello ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
OKD 3.10 : imagestream tag issue with sha
Hi All,
we use Helm 2.x to create new deployment configs on OKD 3.10 cluster and we
configure the image stream tag to deploy a new application pointing to a
specific tag. The template used for a deploy is reported below as example:
# Source: ocp-generic/templates/04_service.yaml
apiVersion: v1
kind: Service
metadata:
name: "test-api-dev"
namespace: "ocp-dev"
labels:
application: "test-api-dev"
spec:
ports:
- name: "http"
port: 8080
targetPort: 8080
protocol: "TCP"
- name: "https"
port: 443
targetPort: 443
protocol: "TCP"
selector:
deploymentconfig: "test-api-dev"
sessionAffinity: None
type: ClusterIP
---
# Source: ocp-generic/templates/03_deploymentconfig.yaml
apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
name: "test-api-dev"
namespace: "ocp-dev"
labels:
application: "test-api-dev"
spec:
replicas: 1
selector:
deploymentConfig: "test-api-dev"
strategy:
type: Rolling
rollingParams:
updatePeriodSeconds: 1
intervalSeconds: 1
timeoutSeconds: 180
triggers:
- type: ConfigChange
- type: ImageChange
imageChangeParams:
automatic: false
containerNames:
- "test-api-dev"
from:
kind: ImageStreamTag
name: "test-api:latest"
namespace: "ocp-dev"
template:
metadata:
labels:
deploymentConfig: "test-api-dev"
application: "test-api-dev"
date: "1591894524"
spec:
dnsPolicy: ClusterFirst
restartPolicy: Always
hostAliases:
securityContext: {}
terminationGracePeriodSeconds: 60
terminationMessagePath: /dev/termination-log
containers:
- name: "test-api-dev"
image: "docker-registry.default.svc:5000/ocp-dev/test-api:latest"
imagePullPolicy: Always
ports:
- containerPort: 8080
protocol: "TCP"
- containerPort: 443
protocol: "TCP"
env:
- name: "SYSLOG_LOGLEVEL"
value: "DEBUG"
readinessProbe:
initialDelaySeconds: 20
timeoutSeconds: 5
periodSeconds: 30
httpGet:
path: /actuator/health
port: 8080
scheme: HTTP
---
# Source: ocp-generic/templates/02_imagestream.yaml
kind: ImageStream
apiVersion: image.openshift.io/v1
metadata:
name: "test-api"
namespace: "ocp-dev"
labels:
application: "test-api-dev"
spec:
dockerImageRepository: "docker-registry.default.svc:5000/ocp-dev/test-api"
tags:
- name: "latest"
---
# Source: ocp-generic/templates/05_route.yaml
apiVersion: route.openshift.io/v1
kind: Route
metadata:
name: "test-api-dev"
namespace: "ocp-dev"
labels:
application: "test-api-dev"
spec:
host: "test-api-dev.test.local"
port:
targetPort: "http"
path: "/"
tls:
termination: edge
insecureEdgeTerminationPolicy: Redirect
certificate: |-
key: |-
caCertificate: |-
destinationCACertificate: |-
to:
kind: Service
name: "test-api-dev"
weight: 100
wildcardPolicy: None
After the first deploy we noticed that the configuration of deployments
config reports the image parameter under container section with the sha256
value and not the image tag value. We also noticed that the configuration
reports the lastTriggerImage parameter with the same value. If we tried to
release a new DC the configuration points to the first shs256 and not the
new one.
If we remove manually from the DC YAML config the lastTriggerImage param
and we override the image sha256 tag with the image stream tag the
deployment work fine and doesn't change the config.
Is it a normal behavior? Is it possible to avoid this config with the
sha256?
Thanks a lot in advance,
Marcello
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Re: how to deploy rocket-chat in openshift 3.11
Hi Aida,
if you installed rocketchat with a standalone mongodb instance, you have to
migrate it to a replicaset with one node configured. On our environment we
fixed this issue in this way.
Marcello
On Tue, May 26, 2020 at 4:06 PM SUBASHI Aida wrote:
> Dear all,
>
> we are trying to deploy rocketchat in openshift 3.11
>
>
> https://github.com/RocketChat/Rocket.Chat/blob/develop/.openshift/rocket-chat-ephemeral.json
> https://github.com/RocketChat/Rocket.Chat/blob/develop/.openshift/rocket-chat-ephemeral.json
>
> rocketchat version is 3.2 and mongodb is 3.6.3
>
>
> we are facing below error internally rocketchat pod.
> Please can someone provide a hit or suggestion how to resolve this issue ?
>
> LOGS of rocketchat pod:
>
> Setting default file store to GridFS
> {"line":"120","file":"migrations.js","message":"Migrations: Not migrating,
> already at version 188","time":{"$date":1590498456786},"level":"info"}
> ufs: temp directory created at "/tmp/ufs"
> Loaded the Apps Framework and loaded a total of 0 Apps!
> Updating process.env.MAIL_URL
> Using GridFS for custom sounds storage
> Using GridFS for custom emoji storage
> Browserslist: caniuse-lite is outdated. Please run next command `npm
> update`
> ➔ server.js:204 System ➔ error
> ➔
> +---+
> ➔ |SERVER
> ERROR |
> ➔
> +---+
> ➔
> |
> |
> ➔ | Rocket.Chat Version:
> 3.2.0-rc.2 |
> ➔ | NodeJS Version: 12.16.1 -
> x64 |
> ➔ | MongoDB Version:
> 3.6.3 |
> ➔ | MongoDB Engine:
> unknown |
> ➔ | Platform:
> linux |
> ➔ | Process Port:
> 3000|
> ➔ | Site URL: http://localhost:3000
> |
> ➔ | ReplicaSet OpLog:
> Disabled|
> ➔ | Commit Hash:
> 0520a3d480 |
> ➔ |Commit Branch:
> HEAD|
> ➔
> |
> |
> ➔ | OPLOG / REPLICASET IS REQUIRED TO RUN ROCKET.CHAT, MORE INFORMATION
> AT: |
> ➔ | https://go.rocket.chat/i/oplog-required
> |
> ➔
> |
> |
> ➔
> +---+
>
>
> Thanks and BR
> Aida
>
>
> ___
> Aida SUBASHI | DevOps Specialist | Scientific Games International GmbH
> | Klitschgasse 2-4, A-1130 Vienna | FN 157284 a,
> HG Wien | (O) +43 1 80100 - 0
>
> May be privileged. May be confidential. Please delete if not the addressee.
> ___
> 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
OKD 3.10 : issue renewal client certificates
Hi All, this morning we noticed that some nodes aren't in ready status and after some troubleshooting, we discovered that the client certificates were expired after one year. We used the steps described into the documentation https://docs.okd.io/3.10/install_config/redeploying_certificates.html but the playbook is not present into the github.com repo. We found the procedure into this bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1635251 and we fixed the problem. We noticed that after that on the master nodes there are other csr requests present in pending status. Is it normal? Thanks, Marcello ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
OKD 3.10 controller-manager restart pods
Hi All,
we have an Origin 3.10 cluster active with 3 master nodes, 2 infra nodes
and 8 app nodes installed withour errors. We noticed on the master nodes
that the controller-manager pods exited after some minutes from their
startup and return active for some time. This is the scenario present on
pods situation.
CONTAINER IDIMAGE
COMMAND
CREATED STATUSPORTS
NAMES
9b7675bc334f471250f836eb
"/usr/bin/service-..." 14 minutes ago Up 14 minutes
k8s_controller-manager_controller-manager-j2w9r_kube-service-catalog_5e206936-b02b-11e8-8aa7-005056802561_1004
18584a95847f471250f836eb
"/usr/bin/service-..." 17 minutes ago Exited (255) 14 minutes ago
k8s_controller-manager_controller-manager-j2w9r_kube-service-catalog_5e206936-b02b-11e8-8aa7-005056802561_1003
The logs for the crashed container are same:
I0424 11:15:12.911602 1 feature_gate.go:190] feature gates:
map[OriginatingIdentity:true]
I0424 11:15:12.911806 1 feature_gate.go:190] feature gates:
map[AsyncBindingOperations:true OriginatingIdentity:true]
I0424 11:15:12.911838 1 hyperkube.go:192] Service Catalog version
v3.10.0-0.1.19.1+52c569d-2-dirty (built 2018-08-31T22:04:46Z)
I0424 11:15:12.922488 1 leaderelection.go:175] attempting to acquire
leader lease kube-service-catalog/service-catalog-controller-manager...
I0424 11:15:12.964985 1 leaderelection.go:184] successfully acquired
lease kube-service-catalog/service-catalog-controller-manager
I0424 11:15:12.966937 1 event.go:218]
Event(v1.ObjectReference{Kind:"ConfigMap",
Namespace:"kube-service-catalog",
Name:"service-catalog-controller-manager",
UID:"ce600996-b02b-11e8-8aa7-005056802561", APIVersion:"v1",
ResourceVersion:"60834933", FieldPath:""}): type: 'Normal' reason:
'LeaderElection'
controller-manager-j2w9r-external-service-catalog-controller became leader
F0424 11:18:13.188671 1 controller_manager.go:232] error running
controllers: unable to start service-catalog controller: API GroupVersion {"
servicecatalog.k8s.io" "v1beta1" "clusterservicebrokers"} is not available;
found
map[schema.GroupVersionResource]bool{schema.GroupVersionResource{Group:"apps",
Version:"v1beta2", Resource:"statefulsets/scale"}:true,
schema.GroupVersionResource{Group:"policy", Version:"v1beta1",
Resource:"podsecuritypolicies"}:true, schema.GroupVersionResource{Group:"
admissionregistration.k8s.io", Version:"v1beta1",
Resource:"mutatingwebhookconfigurations"}:true,
schema.GroupVersionResource{Group:"image.openshift.io", Version:"v1",
Resource:"imagestreams"}:true, schema.GroupVersionResource{Group:"
image.openshift.io", Version:"v1", Resource:"imagestreamtags"}:true,
schema.GroupVersionResource{Group:"", Version:"v1",
Resource:"persistentvolumeclaims"}:true,
schema.GroupVersionResource{Group:"", Version:"v1",
Resource:"pods/exec"}:true, schema.GroupVersionResource{Group:"extensions",
Version:"v1beta1", Resource:"deployments/status"}:true,
schema.GroupVersionResource{Group:"extensions", Version:"v1beta1",
Resource:"replicationcontrollers/scale"}:true,
schema.GroupVersionResource{Group:"authorization.k8s.io",
Version:"v1beta1", Resource:"localsubjectaccessreviews"}:true,
schema.GroupVersionResource{Group:"quota.openshift.io", Version:"v1",
Resource:"clusterresourcequotas/status"}:true,
schema.GroupVersionResource{Group:"extensions", Version:"v1beta1",
Resource:"deployments/scale"}:true,
schema.GroupVersionResource{Group:"apps", Version:"v1",
Resource:"replicasets"}:true, schema.GroupVersionResource{Group:"apps",
Version:"v1beta1", Resource:"deployments"}:true,
schema.GroupVersionResource{Group:"apiextensions.k8s.io",
Version:"v1beta1", Resource:"customresourcedefinitions"}:true,
schema.GroupVersionResource{Group:"apps.openshift.io", Version:"v1",
Resource:"deploymentconfigs/scale"}:true,
schema.GroupVersionResource{Group:"network.openshift.io", Version:"v1",
Resource:"egressnetworkpolicies"}:true, schema.GroupVersionResource{Group:"
network.openshift.io", Version:"v1", Resource:"netnamespaces"}:true,
schema.GroupVersionResource{Group:"project.openshift.io", Version:"v1",
Resource:"projectrequests"}:true, schema.GroupVersionResource{Group:"
route.openshift.io", Version:"v1", Resource:"routes"}:true,
schema.GroupVersionResource{Group:"apps", Version:"v1",
Resource:"replicasets/scale"}:true,
schema.GroupVersionResource{Group:"apps", Version:"v1beta2",
Resource:"deployments"}:true, schema.GroupVersionResource{Group:"
authorization.k8s.io", Version:"v1beta1",
Resource:"selfsubjectaccessreviews"}:true,
schema.GroupVersionResource{Group:"rbac.authorization.k8s.io",
Version:"v1beta1", Resource:"clusterrolebindings"}:true,
schema.GroupVersionResource{Group:"storage.k8s.io", Version:"v1beta1",
Resource:"storageclasses"}:true, schema.GroupVersionResource{Group:"
admissionregistration.k8s.io", Version:"v1beta1",
[no subject]
Hi All,
we have noticed a global cluster issue after a system upgrade on our Origin
v3.10 cluster. The master nodes updated present this error repetead into
journal log:
ocp-devmaster01.test.local origin-node[6432]: W0204 10:54:36.5772596432
status_manager.go:498] Failed to update status for pod
"master-controllers-ocp-devmaster01.test.local_kube-system(75934eb3-2861-11e9-8714-005056802561)":
failed to patch status
"{\"status\":{\"conditions\":[{\"lastProbeTime\":null,\"lastTransitionTime\":\"2019-02-04T09:44:26Z\",\"status\":\"True\",\"type\":\"Initialized\"},{\"lastProbeTime\":null,\"lastTransitionTime\":\"2019-02-04T09:46:12Z\",\"status\":\"True\",\"type\":\"Ready\"},{\"lastProbeTime\":null,\"lastTransitionTime\":null,\"status\":\"True\",\"type\":\"ContainersReady\"},{\"lastProbeTime\":null,\"lastTransitionTime\":\"2019-02-04T09:44:26Z\",\"status\":\"True\",\"type\":\"PodScheduled\"}],\"containerStatuses\":[{\"containerID\":\"docker://fec09ea31a3d523ed2bce797db2e6b76b6c80e03bd6eb337019f20173f99e048\",\"image\":\"
docker.io/openshift/origin-control-plane:v3.10.0\
",\"imageID\":\"docker-pullable://
docker.io/openshift/origin-control-plane@sha256:a2c9a4739e3dcb8124dbca8b743b32bd7a37b5ff5066c8b800cbf2b56747a59d\",\"lastState\":{\"terminated\":{\"containerID\":\"docker://1b2f82c725acc91170de540d72a45f4be66206c4d444247d5136c566c1eb2320\",\"exitCode\":2,\"finishedAt\":\"2019-02-04T09:41:46Z\",\"reason\":\"Error\",\"startedAt\":\"2019-02-04T09:24:34Z\"}},\"name\":\"controllers\",\"ready\":true,\"restartCount\":6,\"state\":{\"running\":{\"startedAt\":\"2019-02-04T09:46:01Z\"}}}],\"hostIP\":\"192.168.1.100\",\"phase\":\"Running\",\"podIP\":\"192.168.1.100\",\"startTime\":\"2019-02-04T09:44:26Z\"}}"
for pod "kube-system"/"master-controllers-ocp-devmaster01.test.local": pods
"master-controllers-ocp-devmaster01.test.local" is forbidden: User
"system:node:ocp-devmaster01.test.local" cannot patch pods/status in the
namespace "kube-system": User "system:node:ocp-devmaster01.test.local"
cannot "patch" "pods/status" with name
"master-controllers-ocp-devmaster01.test.local" in project "kube-system"
We noticed that the docker.io/openshift/origin-pod version has been
updated from v3.10.0 to v3.11.0 on the updated nodes and only these nodes
are not working actually.
Could it be related to a permission issue from the different kubelet
version?
Regards,
Marcello
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
OKD 3.10 restartPolicy into DC
Hi All, we're trying to configure a DC with a pod executed in a batch mode. This pod completes its job and we would not restart it if the exit code is 0. We tried to configure the restartPolicy on DC configuration to Never but the master-api doesn't permit this change. Is it possible to configure this behavior on DC? Thanks a lot, Marcello ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
OC client slowness Windows
Hi All, we installed the newer version of oc-client on a Windows 7 machine and we tested the oc client commands via git bash shell. We noticed some seconds of waiting during the oc commands execution and with the --loglevel=8, the commands reported their output after some seconds of hang. Do you notice this behavior on your experience? We're trying to identify the cause of this issue. Thanks, Marcello ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Configure custom project roles OCP 3.10
Hi All, we tried to define some guidelines into the project grants for all users for a newer OCP cluster. In our previous experience we configured the admin role to system:authenticated group but the some users can edit the routes and deployment configs. What is the best way to configure the roles to permit only the container restart end view logs for some specified users? Thanks, Marcello ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Re: Openshift Origin cluster migration
Hi Aleks, thanks for the response. We would wait some weeks for the 3.10 installation. We required this information because the router and the master api into the 2 cluster are being defined with the same hostnames (after the manual migration of all deployment from old to the new cluster we'll move also the VIP managed via keepalived), and we noticed during the 3.6 installation that the playbook tries to contact the router and master APi during the installation, but we don't know if are used the services instead the external hostnames. Regards, Marcello On Fri, Aug 17, 2018 at 1:16 PM Aleksandar Lazic wrote: > Hi Marcello. > > Am 17.08.2018 um 10:18 schrieb Marcello Lorenzi: > > Hi All, > > > > we are checking the possibility to move an existing Openshift Origin 3.6 > > cluster hosted on a KVM environment to a newer Openshift Origin 3.9 > cluster > > hosted on VMWare environment with more servers and hardware optimized. > Into > > this migration we would maintain the wildcard DNS address and the master > API > > address. > > > > Is it possible to install via advanced installation the newer cluster or > the > > installer tries to contact the older cluster and it can creates issues? > > Yes you can install the new cluster via advanced install. > Why not 3.10 ? > > Normally 2 ocp/okd cluster does not talk to each other, afaik. > > If you mean with ' maintain the wildcard DNS address and the master API > address' > that you will reuse the current setup for the new cluster then you should > take > care about the DNS caches in the clients and that the old DNS setup does > not > point to the old one only to the new one. > > Regards > Aleks > > > Thanks, > > Marcello > > > > > > ___ > > 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 > ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Openshift Origin cluster migration
Hi All, we are checking the possibility to move an existing Openshift Origin 3.6 cluster hosted on a KVM environment to a newer Openshift Origin 3.9 cluster hosted on VMWare environment with more servers and hardware optimized. Into this migration we would maintain the wildcard DNS address and the master API address. Is it possible to install via advanced installation the newer cluster or the installer tries to contact the older cluster and it can creates issues? Thanks, Marcello ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Service Catalog and Openshift Origin 3.7
Hi All, we tried to install the newer version of Openshift Origin 3.7 but during the playbook execution we noticed this error: FAILED - RETRYING: wait for api server to be ready (120 retries left). The issue seems to be related to the service catalog but we don't know there this is running. Does someone notice this issue? Thanks, Marcello ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Openshift 3.6 and multicast support
Hi All, we tried to install a RVD agent into a container deployed on Openshift 3.6 but we noticed that the multicast feed pass from tun0 interface, but doesn't work correctly. Is the multicast address out of Origin nodes supported? Thanks, Marcello ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Re: Openshift router certificate chain
Hi Mateus,
this is the output reported:
# Prevent vulnerability to POODLE attacks
ssl-default-bind-options no-sslv3
# The default cipher suite can be selected from the three sets recommended
by https://wiki.mozilla.org/Security/Server_Side_TLS,
# or the user can provide one using the ROUTER_CIPHERS environment variable.
# By default when a cipher set is not provided, intermediate is used.
{{- if eq (env "ROUTER_CIPHERS" "intermediate") "modern" }}
# Modern cipher suite (no legacy browser support) from
https://wiki.mozilla.org/Security/Server_Side_TLS
tune.ssl.default-dh-param 2048
ssl-default-bind-ciphers
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
{{ else }}
{{- if eq (env "ROUTER_CIPHERS" "intermediate") "intermediate" }}
# Intermediate cipher suite (default) from
https://wiki.mozilla.org/Security/Server_Side_TLS
tune.ssl.default-dh-param 2048
ssl-default-bind-ciphers
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
{{ else }}
{{- if eq (env "ROUTER_CIPHERS" "intermediate") "old" }}
# Old cipher suite (maximum compatibility but insecure) from
https://wiki.mozilla.org/Security/Server_Side_TLS
tune.ssl.default-dh-param 1024
ssl-default-bind-ciphers
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP
{{- else }}
# user provided list of ciphers (Colon separated list as seen above)
# the env default is not used here since we can't get here with empty
ROUTER_CIPHERS
tune.ssl.default-dh-param 2048
ssl-default-bind-ciphers {{env "ROUTER_CIPHERS"
"ECDHE-ECDSA-CHACHA20-POLY1305"}}
{{- end }}
{{- end }}
{{- end }}
defaults
maxconn {{env "ROUTER_MAX_CONNECTIONS" "2"}}
# Add x-forwarded-for header.
{{- if ne (env "ROUTER_SYSLOG_ADDRESS" "") "" }}
{{- if ne (env "ROUTER_SYSLOG_FORMAT" "") "" }}
Marcello
On Fri, Nov 17, 2017 at 1:36 PM, Mateus Caruccio <
mateus.caruc...@getupcloud.com> wrote:
> Hey Marcello.
>
> Correct me if I'm wrong, but you could look into haproxy's config and set
> all ciphers you need:
>
> $ oc -n default rsh dc/router grep -C 10 ssl-default-bind-ciphers
> haproxy-config.template
>
> There is this env var `ROUTER_CIPHERS` you can choose standard profiles
> (modern|intermediate|old) or define your own list.
>
> Hope this help.
>
> Mateus
>
>
> --
> Mateus Caruccio / Master of Puppets
> GetupCloud.com
> We make the infrastructure invisible
> Gartner Cool Vendor 2017
>
> 2017-11-17 10:28 GMT-02:00 Marcello Lorenzi <cell...@gmail.com>:
>
>> Hi All,
>> we tried to configure a new route on Openshift Origin 3.6 to expose a pod
>> where the SSL termination is enabled. We have a problem to configure a
>> re-encrypt route because we noticed that the application is not present on
>> the router and after some investigation we discovered that the problem is
>> related to pod certificate chain. The chain is formed by:
>>
>> - root certificate sha1
>> - intermediate certificate sha256
>> - server certificate sha256
>>
>> We have update the root certificate to sha256 and all works fine.
>&g
Openshift router certificate chain
Hi All, we tried to configure a new route on Openshift Origin 3.6 to expose a pod where the SSL termination is enabled. We have a problem to configure a re-encrypt route because we noticed that the application is not present on the router and after some investigation we discovered that the problem is related to pod certificate chain. The chain is formed by: - root certificate sha1 - intermediate certificate sha256 - server certificate sha256 We have update the root certificate to sha256 and all works fine. Could you confirm if the Openshift router doesn't support the sha1 certificate? Thanks, Marcello ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Re: Origin 3.6 update master certificate issue
Hi; I can use this approach and remove the passthrough termination with the new re-encrypt termination using the wilcard certificate. The only problem is retrrieve the self signed CA generated by the registry. Marcello On Tue, Oct 31, 2017 at 2:38 AM, Louis Santillan <lsant...@redhat.com> wrote: > Try this solution [0]. It mentions metrics but the general procedure > should also work for registry-console. > > [0] https://docs.openshift.com/container-platform/3.6/ > admin_solutions/certificate_management.html#change-app- > cert-to-ca-signed-cert > > ___ > > LOUIS P. SANTILLAN > > SENIOR CONSULTANT, OPENSHIFT, MIDDLEWARE & DEVOPS > > Red Hat Consulting, NA US WEST <https://www.redhat.com/> > > lpsan...@gmail.comM: 3236334854 > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > > On Mon, Oct 30, 2017 at 12:30 PM, Marcello Lorenzi <cell...@gmail.com> > wrote: > >> Hi All, >> we tried to use the playbook /root/openshift-ansib >> le/playbooks/byo/openshift-cluster/redeploy-master-certificates.yml to >> deploy a custom certificates for the public hostname used for the master UI >> and API, but after the update via ansible the registry console doesn't work. >> >> We tried to restore the previous /etc/origin directory content on the >> master nodes and all works fine. >> >> Do we have to configure also the certificate for the registry before this >> update? >> >> Thanks, >> Marcello >> >> ___ >> 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
Re: Origin router and X-Forwarded-For
cure Policy:Redirect > >> Endpoint Port: 443-tcp > > >> Service:callcentergw-dev > >> Weight: 100 (100%) > >> Endpoints: 10.131.0.138:443, 10.131.0.138:80 > > > I miss the destinationCACertificate maybe it's shown with export. > > > oc export route -n dev-shared callcentergw-dev-external > > > You can add in the GUI (=> Webinterface ) all four values under > > "Security" settings. There is a section "Certificates" . > > > key: [as in edge termination] > > certificate: [as in edge termination] > > caCertificate: [as in edge termination] > > destinationCACertificate: ... > > > Please can you also show us the output of > > > curl -vk callcenter.test.local > > >> Marcello > > > Best Regards > > Aleks > > > >> Il 16 Ott 2017 20:45, "Aleksandar Lazic" <al...@me2digital.eu> ha > scritto: > > >> Hi Marcello. > > >> on Montag, 16. Oktober 2017 at 15:23 was written: > > >>> Hi, > >>> I have tried it and it worked fine but the problem is override the > >>> default wildcard certificate and configure a different certificate, > >>> because it's not possible to configure the intermediate CA chain into > >>> the admin panel. I tried to configure the CA cert with the root CA > and > >>> the subordinate CA files and the router is ok but if I navigate the > >>> new route I received a security error. > > >> do you use reencrypted or passthrough route > > >> please can you show us the output of. > > >> oc get route -n your-project > >> oc describe route -n your-project your-route > > >> Best Regards > >> Aleks > > > >>> Marcello > > >>> On Thu, Oct 12, 2017 at 1:14 PM, Aleksandar Lazic < > al...@me2digital.eu> wrote: > > >>> > >>> Hi Marcello Lorenzi. > > >>> have you used -servername in s_client? > > >>> The ssl solution is based on sni ( > >>> https://en.wikipedia.org/wiki/Server_Name_Indication ) > > >>> Regards > >>> Aleks > > >>> on Donnerstag, 12. Oktober 2017 at 13:02 was written: > > > > >>> Hi All, > >>> thanks for the response and we checked the configuration. If I tried > >>> to check the certificated propagate with the passthrough > configuration > >>> with openssl s_client and the certificate provided is the wilcard > >>> domain certificate and not the pod itself. Is it normal? > > >>> Thanks, > >>> Marcello > > >>> On Thu, Oct 12, 2017 at 10:34 AM, Aleksandar Lazic < > al...@me2digital.eu> wrote: > > >>> Hi. > > >>> Additionally to joel suggestion can you also use reencrypted route > >>> if you want to talk encrypted with apache webserver. > > >>> https://docs.openshift.org/3.6/architecture/networking/ > routes.html#re-encryption-termination > > >>> Regards > >>> Aleks > > >>> on Mittwoch, 11. Oktober 2017 at 15:51 was written: > > > >>> Sorry I meant it say, it *cannot modify the http request in any way. > >>> On Thu, 12 Oct 2017 at 12:51 am, Joel Pearson > >>> <japear...@agiledigital.com.au> wrote: > > >>> Hi Marcelo, > > >>> If you use Passthrough termination then that means that OpenShift > >>> cannot add the X-Forwarded-For header, because as the name suggests > it > >>> is just passing the packets through and because it’s encrypted it can > >>> modify the http request in anyway. > > >>> If you want X-Forwarded-For you will need to switch to Edge > termination. > > >>> Thanks, > > >>> Joel > >>> On Thu, 12 Oct 2017 at 12:27 am, Marcello Lorenzi < > cell...@gmail.com> wrote: > > >>> Hi All, > >>> we tried to configure a route on Origin 3.6 with a Passthrough > >>> termination to an Apache webserver present into a single POD but we > >>> can't notice the X-Forwarded-Header to Apache logs. We tried to > capture it without success. > > >>> Could you confirm if there are some method to extract it from the > POD side? > > >>> Thanks, > >>> Marcello > >>> ___ > >>> users mailing list > >>> users@lists.openshift.redhat.com > >>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users-- > >>> Kind Regards, > > >>> Joel Pearson > >>> Agile Digital | Senior Software Consultant > > >>> Love Your Software™ | ABN 98 106 361 273 > >>> p: 1300 858 277 | m: 0405 417 843 | w: agiledigital.com.au-- > >>> Kind Regards, > > >>> Joel Pearson > >>> Agile Digital | Senior Software Consultant > > >>> Love Your Software™ | ABN 98 106 361 273 > >>> p: 1300 858 277 | m: 0405 417 843 | w: agiledigital.com.au > > > > > > -- > Best Regards > Aleks > ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Openshift router per project
HI, we're discovering an installation of Openshift Origin 3.6 with some app nodes present on a VLAN (development) and some other app nodes on a public VLAN (UAT) and we would use the labels and node selector to deploy the pods for the 2 different projects on their specified nodes. The problem is related to the routes because we can't install different routers per projects on different VLANs. Is it possible to achieve this problem without the installation of a new cluster per environment? Thanks Marcello ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Re: Origin router and X-Forwarded-For
Hi Aleks, I already configured the 4 values and if I miss the intermediate CA into the destinationCACertificate field the Origin GUI shows to me a warning related to the certificate. The export of the command is : apiVersion: v1 kind: Route metadata: creationTimestamp: null name: callcentergw-dev-external spec: host: callcenter.fineco.it port: targetPort: 443-tcp tls: caCertificate: |- -BEGIN CERTIFICATE- …. -END CERTIFICATE- -BEGIN CERTIFICATE- … -END CERTIFICATE- certificate: |- -BEGIN CERTIFICATE- … -END CERTIFICATE- destinationCACertificate: |- -BEGIN CERTIFICATE- … -END CERTIFICATE- key: |- -BEGIN RSA PRIVATE KEY- … -END RSA PRIVATE KEY- termination: reencrypt to: kind: Service name: callcentergw-dev weight: 100 wildcardPolicy: None status: ingress: - conditions: - lastTransitionTime: 2017-10-18T07:54:22Z status: "True" type: Admitted host: callcenter.test.local routerName: router wildcardPolicy: None The second command results are the same in insecure and passing the cafile formed by intermediate + root CA certificates. * About to connect() to callcenter.test.local port 443 (#0) * Trying 192.168.10.10... * Connected to callcenter.test.local (192.168.10.10) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /tmp/new-cac.crt CApath: none * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: * subject: E=my.test.local,CN=callcenter.test.local,OU=test,O=Local=Milan,ST=Italy,C=IT * start date: Mar 31 11:54:54 2016 GMT * expire date: Mar 31 11:54:54 2018 GMT * common name: callcenter.test.local * issuer: CN=Local CA Subordinate,DC=milano,DC=test,DC=local,DC=it > GET / HTTP/1.1 > User-Agent: curl/7.29.0 > Host: callcenter.test.local > Accept: */* > < HTTP/1.1 302 Found < Date: Wed, 18 Oct 2017 08:29:17 GMT < Server: Apache/2.4.28 (Unix) OpenSSL/1.0.2k-fips < Location: https://callcenter.test.local/home < Content-Length: 228 < Content-Type: text/html; charset=iso-8859-1 Marcello On Tue, Oct 17, 2017 at 11:21 PM, Aleksandar Lazic <al...@me2digital.eu> wrote: > Hi Marcello. > > on Dienstag, 17. Oktober 2017 at 09:11 was written: > > > Hi, > > I'm using a re-encrypt configuration to preserve the x-forwrded-for > information. The configuration is: > > > > Name: callcentergw-dev-external > > Namespace: dev-shared > > Created:17 hours ago > > Labels: > > Annotations: > > Requested Host: callcenter.test.local > > exposed on router router 17 hours ago > > Path: > > TLS Termination:reencrypt > > Insecure Policy:Redirect > > Endpoint Port: 443-tcp > > > Service:callcentergw-dev > > Weight: 100 (100%) > > Endpoints: 10.131.0.138:443, 10.131.0.138:80 > > I miss the destinationCACertificate maybe it's shown with export. > > oc export route -n dev-shared callcentergw-dev-external > > You can add in the GUI (=> Webinterface ) all four values under > "Security" settings. There is a section "Certificates" . > > key: [as in edge termination] > certificate: [as in edge termination] > caCertificate: [as in edge termination] > destinationCACertificate: ... > > Please can you also show us the output of > > curl -vk callcenter.test.local > > > Marcello > > Best Regards > Aleks > > > Il 16 Ott 2017 20:45, "Aleksandar Lazic" <al...@me2digital.eu> ha > scritto: > > > Hi Marcello. > > > on Montag, 16. Oktober 2017 at 15:23 was written: > > >> Hi, > >> I have tried it and it worked fine but the problem is override the > >> default wildcard certificate and configure a different certificate, > >> because it's not possible to configure the intermediate CA chain into > >> the admin panel. I tried to configure the CA cert with the root CA and > >> the subordinate CA files and the router is ok but if I navigate the > >> new route I received a security error. > > > do you use reencrypted or passthrough route > > > please can you show us the output of. > > > oc get route -n your-project > > oc describe route -n your-project your-route > > > Best Regards > > Aleks > > > >> Marcello > > >> On Thu, Oct 12, 2017 at 1:14 PM, Aleksanda
Re: Origin router and X-Forwarded-For
Hi, I'm using a re-encrypt configuration to preserve the x-forwrded-for information. The configuration is: Name: callcentergw-dev-external Namespace: dev-shared Created:17 hours ago Labels: Annotations: Requested Host: callcenter.test.local exposed on router router 17 hours ago Path: TLS Termination:reencrypt Insecure Policy:Redirect Endpoint Port: 443-tcp Service:callcentergw-dev Weight: 100 (100%) Endpoints: 10.131.0.138:443, 10.131.0.138:80 Marcello Il 16 Ott 2017 20:45, "Aleksandar Lazic" <al...@me2digital.eu> ha scritto: > Hi Marcello. > > on Montag, 16. Oktober 2017 at 15:23 was written: > > > Hi, > > I have tried it and it worked fine but the problem is override the > > default wildcard certificate and configure a different certificate, > > because it's not possible to configure the intermediate CA chain into > > the admin panel. I tried to configure the CA cert with the root CA and > > the subordinate CA files and the router is ok but if I navigate the > > new route I received a security error. > > do you use reencrypted or passthrough route > > please can you show us the output of. > > oc get route -n your-project > oc describe route -n your-project your-route > > Best Regards > Aleks > > > > Marcello > > > On Thu, Oct 12, 2017 at 1:14 PM, Aleksandar Lazic <al...@me2digital.eu> > wrote: > > > > > Hi Marcello Lorenzi. > > > have you used -servername in s_client? > > > The ssl solution is based on sni ( > > https://en.wikipedia.org/wiki/Server_Name_Indication ) > > > Regards > > Aleks > > > on Donnerstag, 12. Oktober 2017 at 13:02 was written: > > > > > Hi All, > > thanks for the response and we checked the configuration. If I tried > > to check the certificated propagate with the passthrough configuration > > with openssl s_client and the certificate provided is the wilcard > > domain certificate and not the pod itself. Is it normal? > > > Thanks, > > Marcello > > > On Thu, Oct 12, 2017 at 10:34 AM, Aleksandar Lazic <al...@me2digital.eu> > wrote: > > > Hi. > > > Additionally to joel suggestion can you also use reencrypted route > > if you want to talk encrypted with apache webserver. > > > https://docs.openshift.org/3.6/architecture/networking/route > s.html#re-encryption-termination > > > Regards > > Aleks > > > on Mittwoch, 11. Oktober 2017 at 15:51 was written: > > > > Sorry I meant it say, it *cannot modify the http request in any way. > > On Thu, 12 Oct 2017 at 12:51 am, Joel Pearson > > <japear...@agiledigital.com.au> wrote: > > > Hi Marcelo, > > > If you use Passthrough termination then that means that OpenShift > > cannot add the X-Forwarded-For header, because as the name suggests it > > is just passing the packets through and because it’s encrypted it can > > modify the http request in anyway. > > > If you want X-Forwarded-For you will need to switch to Edge termination. > > > Thanks, > > > Joel > > On Thu, 12 Oct 2017 at 12:27 am, Marcello Lorenzi <cell...@gmail.com> > wrote: > > > Hi All, > > we tried to configure a route on Origin 3.6 with a Passthrough > > termination to an Apache webserver present into a single POD but we > > can't notice the X-Forwarded-Header to Apache logs. We tried to capture > it without success. > > > Could you confirm if there are some method to extract it from the POD > side? > > > Thanks, > > Marcello > > ___ > > users mailing list > > users@lists.openshift.redhat.com > > http://lists.openshift.redhat.com/openshiftmm/listinfo/users-- > > Kind Regards, > > > Joel Pearson > > Agile Digital | Senior Software Consultant > > > Love Your Software™ | ABN 98 106 361 273 > > p: 1300 858 277 | m: 0405 417 843 | w: agiledigital.com.au-- > > Kind Regards, > > > Joel Pearson > > Agile Digital | Senior Software Consultant > > > Love Your Software™ | ABN 98 106 361 273 > > p: 1300 858 277 | m: 0405 417 843 | w: agiledigital.com.au > ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Re: Origin router and X-Forwarded-For
Hi, I have tried it and it worked fine but the problem is override the default wildcard certificate and configure a different certificate, because it's not possible to configure the intermediate CA chain into the admin panel. I tried to configure the CA cert with the root CA and the subordinate CA files and the router is ok but if I navigate the new route I received a security error. Marcello On Thu, Oct 12, 2017 at 1:14 PM, Aleksandar Lazic <al...@me2digital.eu> wrote: > Hi Marcello Lorenzi. > > have you used -servername in s_client? > > The ssl solution is based on sni ( https://en.wikipedia.org/wiki/ > Server_Name_Indication ) > > Regards > Aleks > > on Donnerstag, 12. Oktober 2017 at 13:02 was written: > > > Hi All, > thanks for the response and we checked the configuration. If I tried to > check the certificated propagate with the passthrough configuration with > openssl s_client and the certificate provided is the wilcard domain > certificate and not the pod itself. Is it normal? > > Thanks, > Marcello > > On Thu, Oct 12, 2017 at 10:34 AM, Aleksandar Lazic <al...@me2digital.eu> > wrote: > > Hi. > > Additionally to joel suggestion can you also use reencrypted route if you > want to talk encrypted with apache webserver. > > https://docs.openshift.org/3.6/architecture/networking/ > routes.html#re-encryption-termination > > Regards > Aleks > > on Mittwoch, 11. Oktober 2017 at 15:51 was written: > > > Sorry I meant it say, it *cannot modify the http request in any way. > On Thu, 12 Oct 2017 at 12:51 am, Joel Pearson < > japear...@agiledigital.com.au> wrote: > > Hi Marcelo, > > If you use Passthrough termination then that means that OpenShift cannot > add the X-Forwarded-For header, because as the name suggests it is just > passing the packets through and because it’s encrypted it can modify the > http request in anyway. > > If you want X-Forwarded-For you will need to switch to Edge termination. > > Thanks, > > Joel > On Thu, 12 Oct 2017 at 12:27 am, Marcello Lorenzi <cell...@gmail.com> > wrote: > > Hi All, > we tried to configure a route on Origin 3.6 with a Passthrough > termination to an Apache webserver present into a single POD but we can't > notice the X-Forwarded-Header to Apache logs. We tried to capture it > without success. > > Could you confirm if there are some method to extract it from the POD side? > > Thanks, > Marcello > ___ > users mailing list > users@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/users -- > Kind Regards, > > Joel Pearson > Agile Digital | Senior Software Consultant > > Love Your Software™ | ABN 98 106 361 273 > p: 1300 858 277 | m: 0405 417 843 <0405417843> | w: agiledigital.com.au -- > > Kind Regards, > > Joel Pearson > Agile Digital | Senior Software Consultant > > Love Your Software™ | ABN 98 106 361 273 > p: 1300 858 277 | m: 0405 417 843 <0405417843> | w: agiledigital.com.au > ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Re: Origin router and X-Forwarded-For
Hi All, thanks for the response and we checked the configuration. If I tried to check the certificated propagate with the passthrough configuration with openssl s_client and the certificate provided is the wilcard domain certificate and not the pod itself. Is it normal? Thanks, Marcello On Thu, Oct 12, 2017 at 10:34 AM, Aleksandar Lazic <al...@me2digital.eu> wrote: > Hi. > > Additionally to joel suggestion can you also use reencrypted route if you > want to talk encrypted with apache webserver. > > https://docs.openshift.org/3.6/architecture/networking/ > routes.html#re-encryption-termination > > Regards > Aleks > > on Mittwoch, 11. Oktober 2017 at 15:51 was written: > > > Sorry I meant it say, it *cannot modify the http request in any way. > On Thu, 12 Oct 2017 at 12:51 am, Joel Pearson < > japear...@agiledigital.com.au> wrote: > > Hi Marcelo, > > If you use Passthrough termination then that means that OpenShift cannot > add the X-Forwarded-For header, because as the name suggests it is just > passing the packets through and because it’s encrypted it can modify the > http request in anyway. > > If you want X-Forwarded-For you will need to switch to Edge termination. > > Thanks, > > Joel > On Thu, 12 Oct 2017 at 12:27 am, Marcello Lorenzi <cell...@gmail.com> > wrote: > > Hi All, > we tried to configure a route on Origin 3.6 with a Passthrough > termination to an Apache webserver present into a single POD but we can't > notice the X-Forwarded-Header to Apache logs. We tried to capture it > without success. > > Could you confirm if there are some method to extract it from the POD side? > > Thanks, > Marcello > ___ > users mailing list > users@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/users -- > Kind Regards, > > Joel Pearson > Agile Digital | Senior Software Consultant > > Love Your Software™ | ABN 98 106 361 273 > p: 1300 858 277 | m: 0405 417 843 <0405417843> | w: agiledigital.com.au -- > > Kind Regards, > > Joel Pearson > Agile Digital | Senior Software Consultant > > Love Your Software™ | ABN 98 106 361 273 > p: 1300 858 277 | m: 0405 417 843 <0405417843> | w: agiledigital.com.au > ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Origin router and X-Forwarded-For
Hi All, we tried to configure a route on Origin 3.6 with a Passthrough termination to an Apache webserver present into a single POD but we can't notice the X-Forwarded-Header to Apache logs. We tried to capture it without success. Could you confirm if there are some method to extract it from the POD side? Thanks, Marcello ___ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
Re: Openshift Origin and fixed user ID
Hi Clayton I have into docker image this commands: && groupadd $APPLICATION_USER \ && useradd -g $APPLICATION_USER -m -d /home/$APPLICATION_USER -s /bin/bash -c 'Application user' $APPLICATION_USER \ && chown -R $APPLICATION_USER:$APPLICATION_USER $TOMCAT_PATH \ && chgrp -R 0 $TOMCAT_PATH \ EXPOSE $TOMCAT_HTTP_PORT USER $APPLICATION_USER On Origin configuration I added the user admin to nonroot SCC. oadm policy add-scc-to-user nonroot admin After this I execute the container but i received an entrypoint permission denied. Marcello On Wed, Sep 13, 2017 at 5:42 PM, Clayton Coleman <ccole...@redhat.com> wrote: > You would define that in your pod spec, or give the service accounts > in your namespace access to the "nonroot" SCC. > > > On Sep 13, 2017, at 11:33 AM, Marcello Lorenzi <cell...@gmail.com> > wrote: > > > > HI All, > > we have created some images with commands executed by user jboss and its > user id is fixed to 500 into the docker file. If we start the image on > Origin the image fails for the permission denied. We discovered that Origin > use a random uid assignment during the image creation, but is it possible > to fix the user id for a specific user like jboss for all the container? > > > > Thanks, > > Marcello > > ___ > > 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
