# Jira Notes

# TLS Setup for RDS

First need to update `dbconfig.xml` to tell it to use TLS and what root certs to use:

```
    <url><![CDATA[jdbc:postgresql://jira.cm5pc4cb8hlj.us-east-1.rds.amazonaws.com:5432/jira?sslmode=verify-full&sslrootcert=/opt/atlassian/jira/rds-root-chain.pem]]></url>

```

Then in `/opt/atlassian/jira/rds-root-chain.pem` you need the root cert(s) for RDS.  Use something like this:

```
#!/bin/bash

URLS="https://s3.amazonaws.com/rds-downloads/rds-ca-2019-root.pem"
URLS="${URLS} https://s3.amazonaws.com/rds-downloads/rds-ca-2015-root.pem"
URLS="${URLS} https://s3-us-gov-west-1.amazonaws.com/rds-downloads/rds-ca-us-gov-east-1-2017-root.pem"
URLS="${URLS} https://s3-us-gov-west-1.amazonaws.com/rds-downloads/rds-ca-us-gov-west-1-2017-root.pem"

rm rds-root-chain.pem

for i in $URLS; do
        echo "# `basename $i`"
        curl -s $i
done >> rds-root-chain.pem


```
see [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html]()

There is mention of ways with newer versions of the PostgreSQL JDBC driver to use the 
standard Java keystore for root certs.  This does not work with the version of the JDBC 
driver skipping with Jira version 7.13, as the class needed is missing.  (There's no
DefaultJavaSSLFactory in `postresql-9.4.1212.jar`)

One handy trick:

```
openssl s_client -starttls postgres -connect my.postgres.host:5432 # etc...
```


# Proxy setup

In `JIRA_HOME/bin/setenv.sh`

```
JVM_SUPPORT_RECOMMENDED_ARGS=" -Dhttp.proxyHost=proxy.msoc.defpoint.local -Dhttp.proxyPort=80 -Dhttps.proxyHost=proxy.msoc.defpoint.local -Dhttps.proxyPort=80 -Dhttp.nonProxyHosts='*.defpoint.local|localhost|127.0.0.1|169.254.169.254|*.amazonaws.com'"
```

Without this, JIRA cannot download new plugins and things from the Atlassian repositories.

# Okta stuff

Okta appears to have provided their own SAML implementation for JIRA.  Which is weird, I
expected JIRA to have their own.

[https://saml-doc.okta.com/Provisioning_Docs/Okta_Jira_Authenticator_Configuration_Guide.html]()

There's a config file in `/opt/atlassian/jira/atlassian-jira/WEB-INF/classes/seraph-config.xml`
that refers to another config file `/opt/docker/okta-config-jira.xml`.  That is where the actual
SAML magic is stored.

# Load Balancer Stuff

There's stuff in web.xml that tells it that it's in front of a load balancer.  The 
proxyName and proxyPort settings matter, because they will cause redirects when
you connect to the wrong name.  Note that in the current config, the load balancer 
terminates TLS and sends plain HTTP back to JIRA itself.


```
        <Connector
        port="8080"
        relaxedPathChars="[]|"
        relaxedQueryChars="[]|{}^\`&quot;&lt;&gt;"
        maxThreads="150"
        minSpareThreads="25"
        connectionTimeout="20000"
        enableLookups="false"
        maxHttpHeaderSize="8192"
        protocol="HTTP/1.1"
        useBodyEncodingForURI="true"
        redirectPort="443"
        acceptCount="100"
        disableUploadTimeout="true"
        bindOnInit="false"
        proxyName="jira.mdr-test.defpoint.com"
        proxyPort="443"
        scheme="https"
        secure="true"
    />
```


# Useful links

[https://confluence.atlassian.com/adminjiraserver085/setting-properties-and-options-on-startup-981155694.html]()
[https://confluence.atlassian.com/jirakb/change-the-base-url-of-jira-server-in-the-database-733940375.html]()


# Undockerizing

* Fix the split attachments dir
* Move attachments out to something like EFS
* Load balancer expects to connect to port 80, which is being forwarded by docker to 8080 inside the container.