Polyspace Access ETL and Web Server services do not start

Issue

You start the Polyspace^® Access services but after a moment, the ETL and Web Server services stop. You might see a HTTP 403 error message in your web browser when you try to connect to Polyspace Access.

Possible Cause: Hyper-V Network Configuration Cannot Resolve Local Host Names

On Windows^®, if you installed Polyspace Access inside a virtual machine (VM), that VM is managed by Hyper-V. Depending on your network configuration, Hyper-V might not resolve local host names. The Polyspace Access ETL and Polyspace Access Web Server services cannot connect to the host that you specify with these host names.

To test whether Hyper-V can resolve host name myHostname on a machine that is connected to the Internet, at the command line, enter:

docker run --rm -it alpine ping myHostname

If Hyper-V cannot resolve the host name, you get an error message.

Solution

Stop and restart the admin-docker-agent binary without using the --hostname option.

• If you are on a trusted network or you do not want to use the HTTPS protocol:

  1. At the command-line, enter:

     docker stop admin
     
     admin-docker-agent --restart-gateway

  2. In the Cluster Admin web interface, click Restart Apps.

• If you want to use the HTTPS protocol, generate certificates with a subject alternative name (SAN) that includes the IP address of the cluster operator node on which the services are running.

  1. Copy this configuration file to a text editor and save it on your machine as openssl.cnf.

      Configuration file

     [ req ]
     req_extensions = v3_req  
     distinguished_name = req_distinguished_name
     prompt = no
     
     [ req_distinguished_name ]
     countryName = US
     stateOrProvinceName = yourState
     organizationName = myCompany
     organizationalUnitName = myOrganization
     emailAddress = [e-mail]
     commonName = hostName
     
     [ v3_req ]
     basicConstraints = CA:FALSE
     keyUsage = nonRepudiation, digitalSignature, keyEncipherment
     subjectAltName = @alt_names
     
     [ alt_names ]
     DNS.1 = hostName
     DNS.2 = fullyQualifiedDomainName
     IP.1 = nodeIPAddress

     hostName is the host name of the server that hosts Polyspace Access. fullyQualifiedDomainName is the corresponding fully qualified domain name. nodeIPAddress is the IP address of the node on which you run the admin-docker-agent binary.

     You do not need to edit the value of the other fields in the [ req_distinguished_name ] section of openssl.cnf. Updating the value of these fields does not affect the configuration.

  2. In the Cluster Dashboard, click Configure Nodes. The IP address listed in the Hostname field corresponds to nodeIPAddress in the openssl.cnf file. If there is more than one node listed, add an additional line in the [ alt_names ] section of openssl.cnf for each IP address. For example:

     [ alt_names ]
     DNS.1 = hostName
     DNS.2 = fullyQualifiedDomainName
     IP.1 = nodeIPAddress
     IP.2 = additionalNodeIPAddress

  3. Generate a certificate signing request (CSR) by using your openssl.cnf configuration file. At the command line, enter:

     openssl req -new -out myReqest.csr -newkey rsa:4096 \
     -keyout myKey.key -nodes -config openssl.cnf

     The command outputs a private key file myKey.key and the file myRequest.csr.

  4. To generate a signed certificate:

     • If you use your organization's certificate authority, submit myRequest.csr to the certificate authority. The certificate authority uses the file to generate a signed server certificate. For instance, server_cert.cer.

     • If you use self-signed certificates, at the command line, enter:

       openssl x509 -req -days 365 -in myRequest.csr -signkey myKey.key \
       -out self-cert.pem -extensions v3_req -extfile openssl.cnf

       The command outputs self-signed certificate self-cert.pem.

  5. Stop and restart the admin-docker-agent binary with this command:

     Windows PowerShell	./admin-docker-agent --restart-gateway ` --ssl-cert-file certFile1 ` --ssl-key-file keyFile ` --ssl-ca-file trustedStoreFile
     Linux®	./admin-docker-agent --restart-gateway \ --ssl-cert-file certFile1 \ --ssl-key-file keyFile \ --ssl-ca-file trustedStoreFile

     certFile1 is the full path of the file you obtained in step 4.keyFile is the file you generated in step 3. trustedStoreFile is the file you generated in step 4 if you used self-signed certificates. Otherwise, it is the trust store file you use to configure HTTPS. See Save your changes.

  6. In the Cluster Admin web interface, click Restart Apps.