Skip to content
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

How to run Che on Openshift 3.11 in a local network #16417

Closed
ultrafab opened this issue Mar 21, 2020 · 25 comments
Closed

How to run Che on Openshift 3.11 in a local network #16417

ultrafab opened this issue Mar 21, 2020 · 25 comments
Labels
area/doc Issues related to documentation area/install Issues related to installation, including offline/air gap and initial setup

Comments

@ultrafab
Copy link

ultrafab commented Mar 21, 2020

After reading:
#16280
i still was unable to start eclipse, using:

chectl server:start -n=che --platform=openshift --installer=operator --tls --self-signed-cert --che-operator-cr-patch-yaml=./patch.yaml

Inside patch.yaml

spec:
  server:
    selfSignedCert: true
    tlsSupport: true

From log the error is:

Exception while retrieving OpenId configuration from endpoint: https://keycloak-che.192.168.69.245.nip.io/auth/realms/che/.well-known/openid-configuration

Using wget the URL is working (apart an unsigned certificate exception).

I've created certs and installed with:

CA_CN=eclipse-che-signer
DOMAIN=*.192.168.69.245.nip.io
OPENSSL_CNF=/etc/ssl/openssl.cnf
openssl genrsa -out rootCA.key 4096
openssl req -x509 \
  -new -nodes \
  -key rootCA.key \
  -sha256 \
  -days 1024 \
  -out rootCA.crt \
  -subj /CN=${CA_CN} \
  -reqexts SAN \
  -extensions SAN \
  -config <(cat ${OPENSSL_CNF} \
      <(printf '[SAN]\nbasicConstraints=critical, CA:TRUE\nkeyUsage=keyCertSign, cRLSign, digitalSignature, keyEncipherment'))
openssl genrsa -out domain.key 2048
openssl req -new -sha256 \
    -key domain.key \
    -subj "/O=EclipseChe/CN=${DOMAIN}" \
    -reqexts SAN \
    -config <(cat ${OPENSSL_CNF} \
        <(printf "\n[SAN]\nsubjectAltName=DNS:${DOMAIN}\nbasicConstraints=critical, CA:FALSE\nkeyUsage=keyCertSign, digitalSignature, keyEncipherment\nextendedKeyUsage=serverAuth")) \
    -out domain.csr
openssl x509 \
-req \
-sha256 \
-extfile <(printf "subjectAltName=DNS:${DOMAIN}\nbasicConstraints=critical, CA:FALSE\nkeyUsage=keyCertSign, digitalSignature, keyEncipherment\nextendedKeyUsage=serverAuth") \
-days 365 \
-in domain.csr \
-CA rootCA.crt \
-CAkey rootCA.key \
-CAcreateserial -out domain.crt
oc login -u system:admin --insecure-skip-tls-verify=true
oc project default
oc delete secret router-certs
cat domain.crt domain.key > minishift.crt
oc create secret tls router-certs --key=domain.key --cert=minishift.crt
oc rollout latest router
oc create namespace che
cp rootCA.crt ca.crt
oc create secret generic self-signed-certificate --from-file=ca.crt -n=che

Openshift is running on a Ubuntu 18.04 server pristine VM.

@ultrafab ultrafab added the kind/bug Outline of a bug - must adhere to the bug report template. label Mar 21, 2020
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Mar 21, 2020
@sleshchenko
Copy link
Member

@ultrafab

Exception while retrieving OpenId configuration from endpoint: https://keycloak-che.192.168.69.245.nip.io/auth/realms/che/.well-known/openid-configuration

Could you share more? It's only error but the whole stack trace could also contain a cause of it, like missing SAN in cert,...

@ibuziuk ibuziuk added team/controller status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach severity/P1 Has a major impact to usage or development of the system. and removed status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. labels Mar 23, 2020
@ultrafab
Copy link
Author

Hello @sleshchenko

The only exception in the log file is:

1) Error injecting constructor, java.lang.RuntimeException: Exception while retrieving OpenId configuration from endpoint: https://keycloak-che.192.168.69.245.nip.io/auth/realms/che/.well-known/openid-configuration
  at org.eclipse.che.multiuser.keycloak.server.KeycloakSettings.<init>(KeycloakSettings.java:70)
  at org.eclipse.che.multiuser.keycloak.server.KeycloakSettings.class(KeycloakSettings.java:53)
  while locating org.eclipse.che.multiuser.keycloak.server.KeycloakSettings
    for the 1st parameter of org.eclipse.che.multiuser.keycloak.server.KeycloakServiceClient.<init>(KeycloakServiceClient.java:73)
  at org.eclipse.che.multiuser.keycloak.server.KeycloakServiceClient.class(KeycloakServiceClient.java:66)
  while locating org.eclipse.che.multiuser.keycloak.server.KeycloakServiceClient
    for the 1st parameter of org.eclipse.che.workspace.infrastructure.openshift.multiuser.oauth.IdentityProviderConfigFactory.<init>(IdentityProviderConfigFactory.java:76)
  at org.eclipse.che.workspace.infrastructure.openshift.multiuser.oauth.IdentityProviderConfigFactory.class(IdentityProviderConfigFactory.java:62)
  while locating org.eclipse.che.workspace.infrastructure.openshift.multiuser.oauth.IdentityProviderConfigFactory
  while locating org.eclipse.che.workspace.infrastructure.openshift.OpenShiftClientConfigFactory
Caused by: java.lang.RuntimeException: Exception while retrieving OpenId configuration from endpoint: https://keycloak-che.192.168.69.245.nip.io/auth/realms/che/.well-known/openid-configuration
	at org.eclipse.che.multiuser.keycloak.server.KeycloakSettings.<init>(KeycloakSettings.java:104)
	at org.eclipse.che.multiuser.keycloak.server.KeycloakSettings$$FastClassByGuice$$e0d0786b.newInstance(<generated>)
	at com.google.inject.internal.DefaultConstructionProxyFactory$FastClassProxy.newInstance(DefaultConstructionProxyFactory.java:89)
	at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:114)
	at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:91)
	at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:306)
	at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
	at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:168)
	at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:39)
	at com.google.inject.internal.SingleParameterInjector.inject(SingleParameterInjector.java:42)
	at com.google.inject.internal.SingleParameterInjector.getAll(SingleParameterInjector.java:65)
	at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:113)
	at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:91)
	at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:306)
	at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
	at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:168)
	at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:39)
	at com.google.inject.internal.SingleParameterInjector.inject(SingleParameterInjector.java:42)
	at com.google.inject.internal.SingleParameterInjector.getAll(SingleParameterInjector.java:65)
	at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:113)
	at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:91)
	at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:306)
	at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
	at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:168)
	at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:39)
	at com.google.inject.internal.FactoryProxy.get(FactoryProxy.java:62)
	at com.google.inject.internal.InternalInjectorCreator.loadEagerSingletons(InternalInjectorCreator.java:211)
	at com.google.inject.internal.InternalInjectorCreator.injectDynamically(InternalInjectorCreator.java:182)
	at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:109)
	at com.google.inject.Guice.createInjector(Guice.java:87)
	at org.everrest.guice.servlet.EverrestGuiceContextListener.getInjector(EverrestGuiceContextListener.java:140)
	at com.google.inject.servlet.GuiceServletContextListener.contextInitialized(GuiceServletContextListener.java:45)
	at org.everrest.guice.servlet.EverrestGuiceContextListener.contextInitialized(EverrestGuiceContextListener.java:85)
	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4699)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5165)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:743)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:719)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705)
	at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:970)
	at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1841)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.UnknownHostException: keycloak-che.192.168.69.245.nip.io
	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:184)
	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
	at java.net.Socket.connect(Socket.java:607)
	at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:666)
	at sun.security.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:173)
	at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:463)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:558)
	at sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:264)
	at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:367)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:191)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1162)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1056)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1570)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1498)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:268)
	at java.net.URL.openStream(URL.java:1067)
	at org.eclipse.che.multiuser.keycloak.server.KeycloakSettings.<init>(KeycloakSettings.java:97)
	... 45 more

And it's repeated about 40 times, once for every try to read from keycloack.
The other log files are clean.
Which kind of insight i can provide?

@sleshchenko sleshchenko added area/install Issues related to installation, including offline/air gap and initial setup team/deploy and removed team/controller labels Mar 23, 2020
@sleshchenko
Copy link
Member

@ultrafab You already provided needed log entry, it's:

Caused by: java.net.UnknownHostException: keycloak-che.192.168.69.245.nip.io

For some reason, keycloak-che.192.168.69.245.nip.io is not available from Che container... I don't see how it's related to TLS and self-signed cert, for me it seems that you have some DNS configuration issues on your OpenShift 3.11

@ultrafab
Copy link
Author

Thank you! The URL is working locally, trying to use WGET i got a response, but i've to use the "--no-check-certificate", so i tought was something related.

ERROR: cannot verify keycloak-che.192.168.69.245.nip.io's certificate, issued by ‘CN=eclipse-che-signer’:
  Unable to locally verify the issuer's authority.
To connect to keycloak-che.192.168.69.245.nip.io insecurely, use `--no-check-certificate'.

I'll try to better check for a DNS issue. Anyway, could you provide me any hint, i'm quite new with Openshift.

@tolusha
Copy link
Contributor

tolusha commented Mar 24, 2020

@ultrafab
chectl version ?

@ultrafab
Copy link
Author

@tolusha
chectl/7.10.0 linux-x64 node-v10.19.0

oc v3.11.0+0cbc58b
kubernetes v1.11.0+d4cacc0
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://192.168.69.245:8443
kubernetes v1.11.0+d4cacc0

@ultrafab
Copy link
Author

ultrafab commented Mar 24, 2020

Hello! Yes, i can confirm i've followed the provided doc.

Here #16417 (comment) there are the scripts i've made to launch the commands chain.

The only difference is that i've used --platform=openshift instead --platform=minishift

@tolusha tolusha added this to the Backlog - Deploy milestone Mar 24, 2020
@mmorhun
Copy link
Contributor

mmorhun commented Mar 24, 2020

@ultrafab could you please clarify which infrastructure exactly you are using? I mean is it running on real Openshift 3.11 cluster or inside Minishift or other environment.

@ultrafab
Copy link
Author

Hello,

It's an Openshift 3.11 single node, installed on a Ubuntu 18.04 server, inside a private network.
The server is a KVM machine, with only docker and openshift installed.

I've installed Openshift, following this guide: https://www.techrepublic.com/article/how-to-install-openshift-origin-on-ubuntu-18-04/

The needing is to have a Eclipse Che multiuser installation to test on a private network.

Here you can find chectl and oc versions: #16417 (comment)

@tolusha tolusha removed status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach team/deploy labels Mar 24, 2020
@sleshchenko
Copy link
Member

sleshchenko commented Mar 26, 2020

@ultrafab Could you share /etc/resolv.conf? I guess you have local DNS server set up and it's not available from a docker container...
P.S. Could you also try request internet from Che Server, like github.com, google.com...

@ultrafab
Copy link
Author

Hello,
this is my /etc/resolv.conf

nameserver 127.0.0.53
nameserver 192.168.69.206 #private DNS server which resolve k8s.bishop.lan to 192.168.69.245
options edns0

I can ping and browse internet without problem from this host.

But there's an update. To complete the infrastructure i've create a bind9 DNS on another network server, pointing the k8s.bishop.lan to the 192.168.69.245 ip address (the Openshift virtual machine), then recreate the certs with the new domain and delete/recreate the cluster with: oc cluster up --public-hostname=k8s.bishop.lan --routing-suffix=k8s.bishop.lan

Right now i'm able to reach the https://keycloak-che.k8s.bishop.lan/auth/realms/che/.well-known/openid-configuration across all the local network (same machine and other machines), and trying to open with Firefox (after installing the ca.cert) i can download this:

{
  "issuer": "https://keycloak-che.k8s.bishop.lan/auth/realms/che",
  "authorization_endpoint": "https://keycloak-che.k8s.bishop.lan/auth/realms/che/protocol/openid-connect/auth",
  "token_endpoint": "https://keycloak-che.k8s.bishop.lan/auth/realms/che/protocol/openid-connect/token",
  "token_introspection_endpoint": "https://keycloak-che.k8s.bishop.lan/auth/realms/che/protocol/openid-connect/token/introspect",
  "userinfo_endpoint": "https://keycloak-che.k8s.bishop.lan/auth/realms/che/protocol/openid-connect/userinfo",
  "end_session_endpoint": "https://keycloak-che.k8s.bishop.lan/auth/realms/che/protocol/openid-connect/logout",
  "jwks_uri": "https://keycloak-che.k8s.bishop.lan/auth/realms/che/protocol/openid-connect/certs",
  "check_session_iframe": "https://keycloak-che.k8s.bishop.lan/auth/realms/che/protocol/openid-connect/login-status-iframe.html",
  "grant_types_supported": [
    "authorization_code",
    "implicit",
    "refresh_token",
    "password",
    "client_credentials"
  ],
  "response_types_supported": [
    "code",
    "none",
    "id_token",
    "token",
    "id_token token",
    "code id_token",
    "code token",
    "code id_token token"
  ],
  "subject_types_supported": [
    "public",
    "pairwise"
  ],
  "id_token_signing_alg_values_supported": [
    "PS384",
    "ES384",
    "RS384",
    "HS256",
    "HS512",
    "ES256",
    "RS256",
    "HS384",
    "ES512",
    "PS256",
    "PS512",
    "RS512"
  ],
  "userinfo_signing_alg_values_supported": [
    "PS384",
    "ES384",
    "RS384",
    "HS256",
    "HS512",
    "ES256",
    "RS256",
    "HS384",
    "ES512",
    "PS256",
    "PS512",
    "RS512",
    "none"
  ],
  "request_object_signing_alg_values_supported": [
    "PS384",
    "ES384",
    "RS384",
    "ES256",
    "RS256",
    "ES512",
    "PS256",
    "PS512",
    "RS512",
    "none"
  ],
  "response_modes_supported": [
    "query",
    "fragment",
    "form_post"
  ],
  "registration_endpoint": "https://keycloak-che.k8s.bishop.lan/auth/realms/che/clients-registrations/openid-connect",
  "token_endpoint_auth_methods_supported": [
    "private_key_jwt",
    "client_secret_basic",
    "client_secret_post",
    "client_secret_jwt"
  ],
  "token_endpoint_auth_signing_alg_values_supported": [
    "RS256"
  ],
  "claims_supported": [
    "aud",
    "sub",
    "iss",
    "auth_time",
    "name",
    "given_name",
    "family_name",
    "preferred_username",
    "email"
  ],
  "claim_types_supported": [
    "normal"
  ],
  "claims_parameter_supported": false,
  "scopes_supported": [
    "openid",
    "microprofile-jwt",
    "web-origins",
    "roles",
    "phone",
    "address",
    "email",
    "profile",
    "offline_access"
  ],
  "request_parameter_supported": true,
  "request_uri_parameter_supported": true,
  "code_challenge_methods_supported": [
    "plain",
    "S256"
  ],
  "tls_client_certificate_bound_access_tokens": true,
  "introspection_endpoint": "https://keycloak-che.k8s.bishop.lan/auth/realms/che/protocol/openid-connect/token/introspect"
}

@sleshchenko
Copy link
Member

@ultrafab But Che Server is still not as lucky as you and can't access keycloak?

@mmorhun
Copy link
Contributor

mmorhun commented Mar 27, 2020

@ultrafab could you try to reach keycloak url from within Che server container ?

To simplify the task, you may use plugin registry container (as they are in the same pod):

  • from VM with Openshift: docker ps | grep plugin and get the container id near quay.io/eclipse/che-plugin-registry.
  • then exec into it: docker exec -it <id> bash
  • finally curl -vk <url-to-keycloak>, where keycloak url should be taken from che server error log (that with Open ID error)

@mmorhun
Copy link
Contributor

mmorhun commented Mar 27, 2020

@ultrafab also please check whether /home/user/self-signed.crt exists in Che server container (exec into it and cat the file)

@ultrafab
Copy link
Author

ultrafab commented Mar 27, 2020

Hi @mmorhun , thanks for the insight.

Here you can find the curl/ping against the keycloack service, and against phisical ID of the KVM machine and the phisical host (just to test the container network):

bash-4.2$ curl -vk https://keycloak-che.k8s.bishop.lan/auth/realms/che/.well-known/openid-configuration
* Could not resolve host: keycloak-che.k8s.bishop.lan; Unknown error
* Closing connection 0
curl: (6) Could not resolve host: keycloak-che.k8s.bishop.lan; Unknown error

bash-4.2$ ping k8s.bishop.lan
ping: k8s.bishop.lan: Name or service not known

bash-4.2$ ping 192.168.69.206
PING 192.168.69.206 (192.168.69.206) 56(84) bytes of data.
64 bytes from 192.168.69.206: icmp_seq=1 ttl=63 time=0.100 ms
64 bytes from 192.168.69.206: icmp_seq=2 ttl=63 time=0.113 ms
64 bytes from 192.168.69.206: icmp_seq=3 ttl=63 time=0.127 ms
^C
--- 192.168.69.206 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2026ms
rtt min/avg/max/mdev = 0.100/0.113/0.127/0.014 ms

bash-4.2$ ping 192.168.69.245
PING 192.168.69.245 (192.168.69.245) 56(84) bytes of data.
64 bytes from 192.168.69.245: icmp_seq=1 ttl=64 time=0.050 ms
64 bytes from 192.168.69.245: icmp_seq=2 ttl=64 time=0.046 ms
^C
--- 192.168.69.245 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1005ms
rtt min/avg/max/mdev = 0.046/0.048/0.050/0.002 ms

It seems i cannot resolve the host name.

Also there is the cert file in: /home/user/self-signed.crt and doing cat i can see the fingerprint of the cert.

@ultrafab
Copy link
Author

UPDATE:
I've modified the /etc/docker/daemon.json adding the custom DNS server:

{
    "dns": ["192.168.69.206","8.8.8.8"],
    "insecure-registries" : [ "172.30.0.0/16" ]
}

but CHE server is raising the same exception, not resolving keycloak endpoint.

Deploying a blank Alpine image inside the same machine, and logging i can ping and resolve the k8s.bishop.lan domain.

@mmorhun
Copy link
Contributor

mmorhun commented Mar 29, 2020

@ultrafab I've faced the same situation: I can ping both, but cannot resolve the hostname inside Che pod. The curious fact is that when I start a container in the VM (which is NOT part of the Openshiift 3.11 cluster) I can resolve the domain name and query keycloak via curl and get response.
So

curl -vk https://keycloak-che.che.openshift.lan/auth/realms/che/.well-known/openid-configuration

works from within a container in the VM and doesn't work from within a container (pod) which belongs to Openshift cluster.
The conclusion is that we didn't configure Openshift cluster in the correct way.
It is required for Che to be able to resolve components (like keycloak) domain name.

Presence of the self-signed certificate in the Che server container confirms that Che processed TLS part in the correct expected way. Error might happen only if certificate is wrong (usually has other (wrong) CN and/or SAN (most likely) ).

@mmorhun
Copy link
Contributor

mmorhun commented Mar 29, 2020

Also, after modifying docker configuration by adding your DNS, have you tried to curl keycloak by domain name from Che pod? What's inside resolv.conf in the Che server container? Does it see your DNS ?

@ultrafab
Copy link
Author

Hello @mmorhun ,

logging inside the k8s_POD_che-********* container i cannot resolve the k8s domain, but i can ping the internal DNS server, so it's reachable but not used.

doing a cat of /etc/resolv.conf:

nameserver 172.30.0.2
search che.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

@ultrafab
Copy link
Author

@mmorhun update it works now

referring to docs in: https://docs.openshift.com/container-platform/3.11/install/prerequisites.html i've found that Openshift 3.11 just inject DNS servers found in /etc/resolv.conf of host machines.

I've create a static /etc/resolv.conf in Ubunu 18.04 host. so it's not rewritten and added the IP address of the private DNS i've setup.

Now Eclipse CHE starts and it's reachable via https://che-che.[privatedomain.lan]

Now i'm testing if it's fully functional

@mmorhun
Copy link
Contributor

mmorhun commented Mar 30, 2020

I got it working in a bit different way. In my case, I didn't change VM's resolv.conf but instead added new DNS to local network one (on my router). And added record for new DNS server (which serves only local Che domain) in the docker config in the VM.

@mmorhun
Copy link
Contributor

mmorhun commented Mar 30, 2020

Just for case, posting my steps (which worked for me in my home network) here:

  1. Setup dedicated server with local IP (real or virtual)

  2. Install docker on it.

  3. Install Openshift Origin on it (I used version 3.11, could be found here). Actually the installation process is just unpacking of the archive and putting oc and kubectl binaries into your path (usually /usr/local/bin/). And we need a folder from which we'll start the cluster and which will hold some cluster data. Say ~/openshift-origin-3.11.

  4. Setup DNS record for Che domain. This step requires some details to explain.
    Actual goal is to make our Che domain (local one) to be resolvable in the local network.
    Say, we want Che to be accessible in the local network by che.local.net domain. Then each host in the local network from which Che should be accessible should be able to resolve che.local.net to the server (from step 1) IP.
    To reach that, I setup new DNS server which can resolve only one record: che.local.net to the server IP. To make things simpler, we may assign static IP to the server in the local network and just configure static resolution in our new DNS. Then add this new DNS to the main DNS in local network (I added it into my router configuration).
    To check if this works, one may run host che.local.net command from terminal. Note, that all subdomains of che.local.net should be resolvable as well, i.e. host route.che.local.net should also point to the server IP.

  5. Add our new DNS into docker config on the server (from step 1). This supposes to add IP address of our new DNS into dns section of docker config file (do not forget comma if you have other records there, it's json). In my case, new DNS server resolves only Che domain, so I have to add second value which points to local DNS or 8.8.8.8.
    Restart docker service:

sudo systemctl restart docker
  1. Navigate to the Openshift folder (in my case ~/openshift-origin-3.11 from step 3) and start the cluster with command:
oc cluster up --public-hostname=che.local.net --routing-suffix=che.local.net
  1. Generate self-signed certificate for the cluster. Actually the steps could be found in Che docs, but I'm adding them here as well (change DOMAIN value to yours):
CA_CN=eclipse-che-signer
DOMAIN=*.che.local.net
OPENSSL_CNF=/etc/ssl/openssl.cnf

# Generate CA key
openssl genrsa -out ca.key 4096

# Generate root CA certificate
openssl req -x509 -new -nodes  -key ca.key -sha256 -days 1024 -out ca.crt -subj /CN=${CA_CN} -reqexts SAN -extensions SAN -config <(cat $OPENSSL_CNF <(printf '[SAN]\nbasicConstraints=critical, CA:TRUE\nkeyUsage=keyCertSign, cRLSign, digitalSignature'))

# Generate server key
openssl genrsa -out domain.key 2048

# Create certificate request for the domain
openssl req -new -sha256 -key domain.key -subj "/O=Local Eclipse Che/CN=${DOMAIN}" -reqexts SAN -config <(cat $OPENSSL_CNF <(printf "\n[SAN]\nsubjectAltName=DNS:${DOMAIN}\nbasicConstraints=critical, CA:FALSE\nkeyUsage=digitalSignature, keyEncipherment, keyAgreement, dataEncipherment\nextendedKeyUsage=serverAuth")) -out domain.csr

# Create certificate for the domain
openssl x509 -req -extfile <(printf "subjectAltName=DNS:${DOMAIN}\nbasicConstraints=critical, CA:FALSE\nkeyUsage=digitalSignature, keyEncipherment, keyAgreement, dataEncipherment\nextendedKeyUsage=serverAuth") -days 365 -in domain.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out domain.crt

Note, that for Fedora OPENSSL_CNF should be /etc/pki/tls/openssl.cnf

  1. Pre-create self-signed secret in Che namespace. Here we suppose, that Che is going to be deployed into che namespace:
oc login -u system:admin --insecure-skip-tls-verify=true
oc project default
oc delete secret router-certs
cat domain.crt domain.key > minishift.crt
oc create secret tls router-certs --key=domain.key --cert=minishift.crt
oc rollout latest router
oc create namespace che
oc create secret generic self-signed-certificate --from-file=ca.crt -n=che
  1. Download and install chectl (might be found here). Actually, chectl might be just used from bin directory.

  2. Run Che with the following command:

chectl server:start --platform=openshift --installer=operator --multiuser --self-signed-cert -n che
  1. Import ca.crt into browser (actually should be done for each host accessing Che). Che docs explain this in details.

  2. From the browser with ca.crt imported open Che url which chectl printed (should look like: https://che-che.che.local.net/ (in che pod, che server under che.local.net domain) ).


P.S.
One may or may not run into the bug. To workaround it, go to ~/openshift-origin-3.11 directory in our case, delete Che namespace with

oc delete namespace che

stop the cluster with

oc cluster down

edit config and run the cluster again, so go to step 6 (steps 7 and 9 don't have to be run twice).

Also it is possible to configure DNS in a different way as @ultrafab suggested.
Then one doesn't have to edit local network settings, but instead should edit network configuration (by adding our new DNS) of each host which should access Che. Also, before starting Openshift cluster, it is required to add new DNS in the server's (from step 1) resolv.conf (please note, that on most systems it is auto generated and will be rewritten, so make sure that the record is permanent).
@ultrafab please correct me if I misunderstood or miss something in your way of resolving Che domain.

@mmorhun
Copy link
Contributor

mmorhun commented Mar 30, 2020

@ultrafab thank you for this issue and for being active in the resolution process!

I am changing the title as the problem doesn't related to TLS.

@mmorhun mmorhun changed the title Error starting under Openshift 3.11 with self signed certificate How to run Che on Openshift 3.11 in a local network Mar 30, 2020
@mmorhun mmorhun added area/doc Issues related to documentation and removed kind/bug Outline of a bug - must adhere to the bug report template. severity/P1 Has a major impact to usage or development of the system. labels Mar 30, 2020
@mmorhun mmorhun closed this as completed Mar 30, 2020
@tolusha tolusha mentioned this issue Mar 30, 2020
45 tasks
@tolusha tolusha removed this from the Backlog - Deploy milestone Mar 30, 2020
@ultrafab
Copy link
Author

@ultrafab please correct me if I misunderstood or miss something in your way of resolving Che domain.

It's all correct!

Just a last insight, we (usually) don't need to modify DNS provided by the office DHCP server for two reasons: only the developers are using the Che/k8s domain and also we usually connect with a VPN client to the server, so we let the opevnp script to push the custom DNS. So we prefer to hack the single developers machines. Otherwise let the DHCP server provide also the custom DNS seems to be the best way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/doc Issues related to documentation area/install Issues related to installation, including offline/air gap and initial setup
Projects
None yet
Development

No branches or pull requests

6 participants