What are the appropriate URL-patterns to use for jira, confluence and stash?
We are running the services behind apache reverse proxy, and are using client certificates for extra security. The https-traffic is terminated at the proxy.
We have added separate connector in server.xml on all services to enable all services to speak to each other on the internal service network on HTTP (no proxyHost, etc. on this connector).
When setting up application links using the internal http-address, the automated procedure seamingly fails when setting up reverse link, due to the base url not being the same as the url used internally, although we have set the appropriate proxyHost=, sheme=, etc in server.xml. Temporarily setting the base url to the internal url when creating the link has not helped.
But the link is created, although dysfunctional. So we have added the IP-patterns and URL patterns manually as indicated in a different question and managed to get most of inter-application stuff working based on the info found here: https://answers.atlassian.com/questions/87355/what-are-the-appropriate-url-patterns-to-use-for-each-atlassian-tool-in-configuring-trusted-connections-between-applications-application-links Unfortuneately, this info seems not to be canonical and authorative and we are missing info in the URL patterns for stash (incoming).
So we would really want to know:
1) What are the appropriate URL-patterns to use for JIRA, Confluence and Stash.
2) Why do the automatic procedure for application links fail when we are accessing an application on a http-connector internally, and try to use the external connector (https)?
3) Are there other ways to do this which should be preferred? Do atlassian expect us to run the inter-app connection internally on HTTPS?
After several rounds of checking logs, I thought I had it all working, only to find there is a bug in stash preventing branch creation from JIRA to work properly (https://jira.atlassian.com/browse/STASH-4250).
So I solved it this way:
- Connector taking traffic from proxy is as before, with proxyHost, etc in server.xml.
<Connector port="8080" maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false" maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="true" redirectPort="443" acceptCount="100" disableUploadTimeout="true" proxyName="jira.mydomain.tld" proxyPort="443" scheme="https" />
- Connector for service network traffic is put on https and port 443. Jira and Confluence requires priviledges for this:
<Connector SSLEnabled="true" acceptCount="100" clientAuth="false" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" keyAlias="tomcat" keystoreFile="/opt/atlassian/certs/keystore.jks" keystorePass="********" keystoreType="JKS" maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="150" minSpareThreads="25" port="443" protocol="org.apache.coyote.http11.Http11Protocol" scheme="https" secure="true" sslProtocol="TLS" useBodyEncodingForURI="true"/>
$ setcap cap_net_bind_service+ep /opt/atlassian/confluence/jre/bin/java $ echo "/opt/atlassian/confluence/jre/lib/amd64/jli" > /etc/ld.so.conf.d/java-libjli.conf
- DNS is bypassed on the server hosts for the application FQDNs, such that internal traffic between the applications do not go via proxy. I added this to the /etc/hosts file:
192.168.2.20 confluence.mydomain.tld 192.168.2.30 jira.mydomain.tld 192.168.2.40 stash.mydomain.tld
Now application link creation is smooth, and I do not need to edit any trust-parameters.
Hi Olaf, I am currently looking into a similar configuration as you have described. My question to you is how do your internal users access Jira/Confluence? Do they have to through the firewall to the Apache Web Server only to be redirected back to Jira/Confluence Tomcat servers or did you setup a configuration where internal users access via Jira/Confluence Tomcat directly?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi, Adam. All users go through the same front end (Apache in our case). No redirection. You could of cource have multiple front ends if you alter the DNS lookup for clients from internal network. E.g. internally use a separate front end or just use the tomcat HTTPS-connector directly -- yourserver.tld -> internal IP, no client cert requirement on Apache front end or tomcat connector. And additionally an Apache with client cert requirement for external users -- yourserver.tld -> external IP with Apache front end. In our case, we have an auto enrollment certificate policy, so it is very simple for internal users to aquire a certificate. Also, our servers are on a network separated from both external and internal clients. We therefore so far have kept things simple and use only one front end for both external and internal clients with the same client certificate requirements.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for that Olaf. I believe we will go with Apache front end with SSL termination on Apache. I was thinking of using internal DNS entry for internal network users to access Jira and Confluence Tomcat servers directly with just HTTP, however; doesnt that mean external users and internal users will have different URL in their browsers and Jira and Confluence servers only allow 1 base URL (e.g. if base URL is external URL internal users will get base URL mismatch warnings )? Or if internal DNS entry will match external user URL there is the HTTP internal vs HTTPS external mismatch?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Adam,
Just use the HTTPS-connector internally, and you should be ok. The HTTP-connector you need additionally for an Apache front end if you have SSL-termination at Apache. This way the URL scheme is HTTPS for all clients, and this is compatible with the base URL you set in the applications.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey Olaf,
i have a similar setup. Let me give you my config as an example, maybe it helps you. I use JIRA and Stash behind haproxy to have nice URLs without ports and also for SSL offload. When adding the application link to JIRA i used the address "127.0.0.1:9191" and Stash was able to find JIRA on the local interface.
Stash connectors:
<Connector port="7990" protocol="HTTP/1.1" address="127.0.0.1" connectionTimeout="20000" useBodyEncodingForURI="true" redirectPort="443" compression="off" compressableMimeType="text/html,text/xml,text/plain,text/css,application/json,application/javascript,application/x-javascript" secure="true" scheme="https" proxyName="stash.mydomain.com" proxyPort="443" /> <Connector port="8990" protocol="HTTP/1.1" address="127.0.0.1" connectionTimeout="20000" useBodyEncodingForURI="true" redirectPort="8990" compression="off" compressableMimeType="text/html,text/xml,text/plain,text/css,application/json,application/javascript,application/x-javascript" />
Jira connectors:
<Connector acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" port="8181" address="127.0.0.1" protocol="HTTP/1.1" redirectPort="443" useBodyEncodingForURI="true" scheme="https" proxyName="jira.mydomain.com" proxyPort="443"/> <Connector port="9191" address="127.0.0.1" maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false" maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="true" acceptCount="100" disableUploadTimeout="true"/>
HAProxy config:
global log 127.0.0.1 local0 log 127.0.0.1 local1 notice maxconn 8192 chroot /usr/share/haproxy user haproxy group haproxy daemon defaults log global mode http option forwardfor option httplog option dontlognull option redispatch option tcp-smart-accept option tcp-smart-connect option httpchk retries 3 maxconn 6000 balance roundrobin timeout connect 5s timeout client 30s timeout server 120s compression algo gzip compression type text/html text/plain text/css backend jira server jira 127.0.0.1:8181 check inter 2000 maxconn 50 backend stash server stash 127.0.0.1:7990 check inter 2000 maxconn 50 frontend http-in bind :::80 bind :::443 ssl crt /etc/haproxy/haproxy.pem option http-server-close redirect scheme https if { hdr_beg(Host) -i jira stash } !{ ssl_fc } acl req_jira hdr(host) -i jira.mydomain.com acl req_stash hdr(host) -i stash.mydomain.com use_backend jira if req_jira use_backend stash if req_stash
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks, Phillip. I tried you setup. Still the reverse "application URL" ends up being wrong when I set up the link. They are automatically set to the base URL with https. And the result is that the reverse link is not created properly.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.