How can I configure Jira to listen on ipv4 instead of ipv6?

[admin admin]

I have a Jira server I am testing which is delivered by tar.gz.

The server is running on CentOS 7, and when I run sudo netstat -tulnp I get 
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 6064/sshd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 6295/master
tcp6 0 0 127.0.0.1:8005 :::* LISTEN 29050/java
tcp6 0 0 :::8080 :::* LISTEN 29833/java
tcp6 0 0 :::22 :::* LISTEN 6064/sshd
tcp6 0 0 ::1:25 :::* LISTEN 6295/master
udp 0 0 127.0.0.1:323 0.0.0.0:* 5492/chronyd
udp6 0 0 ::1:323 :::* 5492/chronyd

I note that Jira is running as process 29050, and that this process is using tcp6

SO, if my assumption is correct, as my local network is not using ipv6, I would like to know how I can configure Jira to be backwards compatible with ipv4, ideally without installing an ipv4 -> ipv6 proxy.

[Robert Swift]

At the risk of bringing an old thread back to life, I've just been looking at a really peculiar issue whereby I wasn't able to login to Confluence, with Jira as my user directory.

The behaviour was that I could successfully test, get a green notification, but clicking save, failed. every. single. time.

I noticed in the Jira access log the following:

127.0.0.1 549x1630x1 - [10/Apr/2020:09:09:34 +0100] "POST /rest/usermanagement/1/search?entity-type=user&start-index=0&max-results=1&expand=user HTTP/1.0" 200 92 52 "-" "Apache-HttpClient/4.5.6 (Java/11.0.6)" "1op9wdr"
0:0:0:0:0:0:0:1 549x1631x1 - [10/Apr/2020:09:09:36 +0100] "POST /rest/usermanagement/1/search?entity-type=user&start-index=0&max-results=1&expand=user HTTP/1.0" 403 10976 11 "-" "Apache-HttpClient/4.5.6 (Java/11.0.6)" "-"

note that the 200 was the test, the 403 the save. What I spotted was that the test always originated from localhost (this a local setup on macOS + Jira 8.8 + Confluence 7.3.4 + Java 11 + PostgreSQL 10).

Adding 0:0:0:0:0:0:0:1 to the list of IP addresses Jira will accept connections from, and boom, problem vanished.

It's taken quite a bit of digging for this, I've probably missed a note somewhere and lots of rolling eyes from others - but I thought I'd share in case this is useful to someone...

[Andy Heinzer]

Hi Shane,

I see that you are looking at the ports and protocols in use by Jira, and have some concerns about which protocol is actually being used by Jira.

Jira is actually using two ports in this example: 8080 and 8005.  8080 is the default port for the web server, and 8005 is the default control port (this is used to start/stop/monitor the Jira service).   Both of these ports are being opened by tomcat, Java application that Jira uses to serve up its content.  

The 8005 port is the server component.  More details in https://tomcat.apache.org/tomcat-8.5-doc/config/server.html From that page:

address

The TCP/IP address on which this server waits for a shutdown command. If no address is specified, localhost is used.

So in this case, you could define that address parameter in the $JIRAINSTALL/conf/server.xml file to tell it specifically to listen to an ipv4 address if you wanted to, such as 127.0.0.1

For the 8080 port, this is controlled by the connector directive.  More details in https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#Common_Attributes

address

For servers with more than one IP address, this attribute specifies which address will be used for listening on the specified port. By default, the connector will listen all local addresses. Unless the JVM is configured otherwise using system properties, the Java based connectors (NIO, NIO2) will listen on both IPv4 and IPv6 addresses when configured with either 0.0.0.0 or ::. The APR/native connector will only listen on IPv4 addresses if configured with 0.0.0.0 and will listen on IPv6 addresses (and optionally IPv4 addresses depending on the setting of ipv6onlyv6) if configured with ::.

Which tells me that Jira will try to listen to both ipv4 and ipv6 requests if these protocols are available to Jira when it starts up.   So I'm not certain there is a need yet to force Jira to only listen to ipv4, because it sounds like its going to be listening to both.  But it looks like you could force the protocol if you wanted to by making changes to this server.xml file to specify ipv4 addresses, saving those changes, and then restarting Jira to have those take affect.

Alternatively to editing the server.xml directly to do this, you could also try to set the a JVM startup parameter of:

-Djava.net.preferIPv4Stack=true

This JVM parameter tells Java on startup to prefer the use of ipv4 in this JVM.  This could be a different means to force the application to use ipv4 when starting up.  I think I would actually try this method first before trying to set specific addresses.

Please let me know if this helps.

Andy

[admin admin]

Hi Andy,

Presumably this '-Djava.net.preferIPv4Stack=true' argument is installed as a prefix to the JAVA_OPTS env var in the bin/setenv.sh file?

If so, I note that this option is already in place, as below;

JAVA_OPTS= $JAVA_OPTS -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses

So, going back to my OP, I have verified again with netstat which protocols and ports my server is listening to , and unfortunately this is still as it was; Listening to an ipv4 address with an ipv6 protocol, as below;

# netstat -tulnp
tcp6 0 0 127.0.0.1:8005 :::* LISTEN 15044/java
tcp6 0 0 127.0.0.1:8080 :::* LISTEN 15044/java

[Andy Heinzer]

Hi Shane,

The Jira documentation on making startup option changes states to always use the JVM_SUPPORT_RECOMMENDED_ARGS= for Linux/Unix installs in the setenv.sh file instead of JAVA_OPTS directly, but given that the later calls the former, you should be fine in that regard.  If you are unsure if this JVM option is being applied, you can look closer at the $JIRAHOME/log/atlassian-jira.log file at the time of startup (search for 'Jira starting' no quotes).  This startup section of the log will show all the JVM parameters that are getting passed when the application starts.

Thanks for posting your steps and output to the netstat again.  From looking at this, I would agree that the process is using an IPv6 protocol when you see 'tcp6', but I disagree that IPv4 clients cannot connect to that address in this case.  They can.  The process is listening on an IPv4 address.  And in turn, tcp6 does support both IPv4 and IPv6 protocols.  So if your primary fear is is the inability of IPv4 clients to connect to this Jira site, fear not.  There is not a need for a proxy to handle this protocol conversion, IPv6 can handle both types natively.

Some references about tcp6 protocol and the use of IPv4 can be found here in

• https://unix.stackexchange.com/questions/120543/tcp6-in-the-output-netstat
• https://unix.stackexchange.com/questions/237731/why-are-ipv4-tcp-connections-showing-as-tcp6/237747

I hope this helps to clarify.

Please let me know if this helps.

Andy

[admin admin]

So, as the server is not coming up, this means that something else is wrong :-(
Let me run through my script again to see if I may have missed something.

[Andy Heinzer]

Sorry to hear that.  If Jira isn't starting up as expected, try checking the $JIRAINSTALL/logs/catalina.out file.  This is a file created by the tomcat process that Jira calls on startup. 

It tends to have more details that might not make it to the $JIRAHOME/log/atlassian-jira.log file in cases where something is not working correctly on startup.