OpenShift FAQs ¶

Permission errors when starting containers ¶

If you encounter the following log message upon starting the container, disregard it as it is not indicative of a critical error:

INFO:root:Generating /opt/atlassian/confluence/conf/server.xml from template server.xml.j2
WARNING:root:Permission problem writing '/opt/atlassian/confluence/conf/server.xml'; skipping
INFO:root:Generating /opt/atlassian/confluence/confluence/WEB-INF/classes/seraph-config.xml from template seraph-config.xml.j2
WARNING:root:Permission problem writing '/opt/atlassian/confluence/confluence/WEB-INF/classes/seraph-config.xml'; skipping
INFO:root:Generating /opt/atlassian/confluence/confluence/WEB-INF/classes/confluence-init.properties from template confluence-init.properties.j2
WARNING:root:Permission problem writing '/opt/atlassian/confluence/confluence/WEB-INF/classes/confluence-init.properties'; skipping

The issue arises because the container's entrypoint script tries to generate and save server.xml and seraph-config.xml files but is unable to due to insufficient permissions. This is a normal behavior when Atlassian DC containers run as a non-root user. Note that both server.xml and seraph-config.xml are generated by Helm and mounted as read-only files within the container. If you need to change the default values for the server.xml, you can do it in the <product>.tomcatConfig stanza in the Helm values file.

No pods have been created ¶

This can happen when deploying Atlassian DC Helm charts to OpenShift with the default settings, and the service account has not been granted any SCC other than restricted. You will typically find the following error in Kubernetes events:

Error creating: pods "jira-0" is forbidden:
unable to validate against any security context constraint:
[provider "anyuid": Forbidden: not usable by user or serviceaccount,
provider restricted-v2: .spec.securityContext.fsGroup: 
Invalid value: []int64{2001}: 2001 is not an allowed group, provider "restricted":
Forbidden: not usable by user or serviceaccount, provider "nonroot-v2":
Forbidden: not usable by user or serviceaccount, provider "nonroot":
Forbidden: not usable by user or serviceaccount, provider "hostmount-anyuid":
Forbidden: not usable by user or serviceaccount, provider "machine-api-termination-handler":
Forbidden: not usable by user or serviceaccount, provider "hostnetwork-v2":
Forbidden: not usable by user or serviceaccount, provider "hostnetwork":
Forbidden: not usable by user or serviceaccount, provider "hostaccess":
Forbidden: not usable by user or serviceaccount, provider "node-exporter":
Forbidden: not usable by user or serviceaccount, provider "efs-csi-scc":
Forbidden: not usable by user or serviceaccount, provider "privileged":
Forbidden: not usable by user or serviceaccount]

To fix this error, set openshift.runWithRestrictedSCC to true in Helm values.

Another possible error in the events:

Error: container has runAsNonRoot and
image will run as root (pod: "jira-0_atlassian", container: container)

This can happen if the ServiceAccount has been granted nonroot SCC privileges, but runAsUser has not been set in securityContext. To fix the error, use the following Helm values:

jira:
  securityContext:
    fsGroup: 2001
    runAsUser: 2001

See the complete list of Helm values for the Nonroot SCC.

What's the difference between restricted and nonroot SCC? ¶

From the security/compliance standpoint, Restricted SCC enforces a more secure set of rules, or rather limitations. However, running DC containers as nonroot users does not expose any security threats either. The only two disadvantages are that the ServiceAccount needs to be granted nonroot SCC privileges, and there are more Helm values to be overridden. See: Nonroot SCC.

Running with a Restricted SCC is the recommended way to deploy Atlassian DC Helm charts. See: Restricted SCC

NFS permission fixer is Disabled, how can I make shared home writable? ¶

When running Atlassian DC containers with a restricted or nonroot SCC, it is not possible to run the nfs-permission fixer container because it runs as root. You need to make sure the volume is writable either for an unprivileged restricted SCC user or a user defined in securityContext (with UID like 2001, 2002, 2003 depending on the product).

If you run NFS server, you may either change permissions directly on the NFS server instance, or create a temporary ServiceAccount, grant it anyuid SCC privileges, create a pod that uses this ServiceAccount, mounts shared-home volume and recursively changes owner of the shared home directory. It can take longer for larger volumes.

Can I use a custom certificate and key for my route? ¶

By default, all Routes that the Helm charts create will use the default OpenShift Router certificate and key. If you want to use a custom crt-key pair for an individual Route, create a TLS secret with tls.crt, tls.key and ca.crt (optional) in data and provide the secret name in Helm values:

ingress:
  create: true
  openShiftRoute: true
  tlsSecretName: my-tls-secret

How can I configure OpenShift routes? ¶

You can provide custom annotations for your Routes in the ingress Helm values stanza. For example, to increase connection timeout, annotate your route:

ingress:
  create: true
  openShiftRoute: true
  annotations:
    haproxy.router.openshift.io/timeout: 60s

You will find a list of available Route-specific annotations in the official documentation.

Route HTTP Headers can be configured in the ingress Helm values stanza:

ingress:
  create: true
  openShiftRoute: true
  routeHttpHeaders:
    <your-actions>

What route TLS termination types are supported? ¶

Atlassian DC Helm charts only support Edge TLS termination, i.e. TLS termination is performed by the OpenShift router.

Passthrough and Reencrypt TLS termination isn't currently supported. See: Secured Routes