Chapter 1. JIRA Server Administration

In this chapter, we will cover:

Installing JIRA for production use
Upgrading JIRA with an installer
Upgrading JIRA manually
Migrating JIRA to another environment
Setting up the context path for JIRA
Setting up SSL
Installing SSL certificates from other applications
Resetting the JIRA administrator password
Generating test data in JIRA
Anonymizing JIRA exports

Introduction

Atlassian JIRA is a popular issue-tracking system used by many companies across the world. One of its strengths, unlike most other enterprise software, is it does not take days or weeks to install and implement, and it is very simple to upgrade and maintain.

We will assume that you, the reader, already know how to install a brand new JIRA. So, we will explore common administration tasks, such as upgrading and migrating your JIRA, looking at different options, from using the new automated upgrade utility provided by Atlassian to doing everything from scratch.

We will also look at some other neat tricks you can do as an administrator, such as resetting the admin password to get you out of sticky situations.

Installing JIRA for production use

In this recipe, we will look at how to install and set up JIRA in a production environment. This includes setting up a dedicated user to run JIRA under and using an external database.

We will be using the standalone archive distribution, as the steps are consistent across both Windows and Linux platforms.

Getting ready

The following things need to be checked before you start with this recipe:

Download the latest JIRA archive distribution from https://www.atlassian.com/software/jira/download and click on the All JIRA Download Options link.
Make sure your server environment meets JIRA's requirements by visiting the following link: https://confluence.atlassian.com/display/JIRA/Supported+Platforms.
Install Java on the system. At the time of writing, JIRA 6 required Java 7. Make sure you get the latest update for Java, unless it is explicitly stated as unsupported by JIRA.
Make sure the JAVA_HOME or JRE_HOME environment variable is configured.
Have a database system available, either on the server hosting JIRA or a different server accessible over the network. For this recipe, we will be using MySQL; if you are using a different database, change the commands and queries accordingly.
Download the necessary database driver. For MySQL, you can download it from https://dev.mysql.com/downloads/connector/j.

How to do it…

We first need to create an empty MySQL database for JIRA:

Open up a new command prompt on the MySQL server.
Run the following command (you can also use another user instead of root as long as the user has permission to create new users and databases):
```
mysql -u root -p
```
Enter the password for the user when prompted.
Create a new database for JIRA by running the following command:
```
create database jiradb character set utf8;
```
Create a new user for JIRA in the database and grant the user access to the jiradb database we just created using the following command:
```
grant all on jiradb.* to 'jirauser'@'localhost' identified by 'jirapassword';
```
In the previous five steps, we have created a new database named jiradb and a new database user named jirauser. We will be using these details later to connect JIRA with MySQL. The next step is to install JIRA.
Create a dedicated user account to run JIRA under. If you're using Linux, run the following command as root or with sudo:
```
useradd --create-home --comment "Dedicated JIRA account" --shell /bin/bash jira
```
Note
It is a good practice to reduce security risks by locking down the user account so that it does not have login permissions.
Create a new directory on the filesystem where JIRA will be installed in. This directory will be referred to as JIRA_INSTALL.
Create another directory on the filesystem. This will be used for JIRA to store its attachments, search indexes, and other information. You can create this directory on a different drive with more hard disk capacity, such as a network drive (this could slow down the performance). This directory will be referred to as JIRA_HOME.
Note
It is a good practice to keep the JIRA_INSTALL and JIRA_HOME directories separate, that is, the JIRA_HOME directory should not be a subdirectory inside JIRA_INSTALL. This will make future upgrading and maintenance easier.
Unzip the JIRA archive file in the JIRA_INSTALL directory.
Change both the JIRA_INSTALL and JIRA_HOME directories' owner to the new JIRA user.
Open the JIRA_INSTALL/atlassian-jira/WEB-INF/classes/jira-application.properties file in a text editor.
Locate the jira.home= line in this file.
Cut and paste this in the full path to the JIRA_HOME directory and remove the # symbol if present. Make sure you use the forward slash (/). The following line shows how it looks on a Linux system:
```
jira.home=/opt/data/jira_home
```
Note
Windows uses the backward slash (\) in the file path. You should still use the forward slash (/) while specifying the jira.home directory.
Copy the database driver JAR file to the JIRA_INSTALL/lib directory.
Start up JIRA by running the start-jira.sh (for Linux) or start-jira.bat (for Windows) script from the JIRA_INSTALL/bin directory as the JIRA user.
JIRA comes with a setup wizard that will help guide us through the final phase of the installation.
Open up a browser and go to http://host:8080. By default, JIRA runs on port 8080. You can change this by changing the connector port value in the JIRA_INSTALL/conf/server.xml file.
The first step is to select the language JIRA will use for its user interface.
The second step is to set up the database information. Select the My Own Database (recommended for production environments) option.
Select a value for the Database Type option. For this recipe, select the MySQL option.
Enter the details for our new jiradb database.
Click on Test Connection to check whether JIRA is able to connect to the database.
Click on Next to move to the second step of the wizard as shown in the following screenshot:
Enter the title for this JIRA instance.
Select Public if you would like to let people sign up for accounts, or select Private if you want only administrators to create accounts. For most organizations that use JIRA to track internal projects, it will be the Private mode.
Set the Base URL option. The base URL is the one that users will use to access JIRA. Usually, this should be a fully qualified domain name or the hostname, that is, not a localhost or an IP address.
Click on Next to go to the third step of the wizard, as shown in the following screenshot:
Enter your JIRA license key.
Select the I don't have an account option if you do not have a valid JIRA license and you do not have an account on my.atlassian.com.
Select the I have an account but no key option if you have an account on my.atlassian.com but you do not have a valid JIRA license key.
Select the I have a key option if you have a valid JIRA license key handy.
Click on Next to go to the fourth step of the wizard, as shown in the following screenshot:
Enter the details for the initial administrator account. The user account will have access to all configuration options in JIRA, so make sure you do not lose its login credentials.
Click on Next to go to the fifth and final step of the wizard, as shown in the following screenshot:
Choose if you want to set up an outgoing SMTP server now or later. If you do not have an SMTP server ready right now, you can always come back and configure it later.
Click on Finish to complete the setup process, as shown in the following screenshot:

Once JIRA finishes the final setup procedures, you will be automatically logged in with the initial administrator account you created.

There's more…

By default, JIRA is set to use a maximum of 768 MB of memory. For a production deployment, you might need to increase the amount of memory allocated to JIRA. You can increase this by opening up the setenv.sh (on Linux) or setenv.bat (on Windows) file in the JIRA_INSTALL/bin directory and changing the value for the JVM_MAXIMUM_MEMORY parameter. For example, if we want to set the maximum memory to 2 GB, we will change it to JVM_MAXIMUM_MEMORY="2048m". You will need to restart JIRA after performing this change. For production uses, it is recommended that you allocate at least 2 GB of memory to the JIRA JVM.

If you are using LDAP for user management in your organization, refer to the Integrating with LDAP for authentication only recipe in Chapter 4, User Management.

Upgrading JIRA with an installer

In this recipe, we will show you how to upgrade your JIRA instance with the standard JIRA installer.

Getting ready

Since the JIRA installer is only available for standalone installations on Windows and Linux, we will be running you through the installer on Windows for this recipe:

Check the upgrade notes for any special instructions as well as the target JIRA version to make sure you can perform a direct upgrade.
Make sure you have a valid JIRA license.
Verify whether your current host environment is compatible with the target JIRA version. This includes the Java version, database, and operating system.
Verify whether your operating environment is compatible with the target's JIRA version, specifically the browser requirements.
Make sure that the add-ons you are using are compatible with the new version of JIRA.
Tip
You can use the Universal Plugin Manager's JIRA update check utility to check for add-on compatibility.
Download the installer binary for your target JIRA version.

How to do it…

Upgrade your JIRA with the installer using the following steps:

Take your current JIRA offline; for example, by running the stop-jira.bat script.
Back up the JIRA database with its native backup utility.
Launch the installer and select the Upgrade an existing JIRA installation option.
Select the directory where the current JIRA is installed:
Check the Back up JIRA home directory option and click on the Next button.
Review the upgrade checklist and click on the Upgrade button:
Wait for the installer to complete the upgrade process. Once the upgrade is complete, the installer will automatically launch JIRA.
Update add-ons once JIRA has successfully started.

The installer will detect and provide you with a list of customized files in the JIRA_INSTALL directory, which you will need to manually copy after the upgrade.

Upgrading JIRA manually

If you find yourself in a situation where you cannot use the JIRA installer to upgrade JIRA, for example, you are hosting JIRA on an OS that does not have an installer binary such as Solaris, or if you are using the WAR distribution, then you need to manually upgrade your JIRA instance.

Getting ready

The general prerequisite tasks for upgrading JIRA manually will remain the same as that of the installer. Refer to the previous recipe for the common tasks involved. Since the installer automates many of the backup tasks while upgrading JIRA manually, you will have to do the following:

Back up the JIRA database with its native backup utility
Back up the JIRA_INSTALL directory
Back up the JIRA_HOME directory
Get a list of all the customized files in the JIRA_INSTALL directory from the System Info page in JIRA
For the WAR distribution, prepare and configure the installation files

How to do it…

To manually upgrade your JIRA instance, perform the following steps:

Take your current JIRA offline.
Install the new version of JIRA.
Edit the jira-application.properties file in this version of JIRA, located in the JIRA_INSTALL/atlassian-jira/WEB-INF/classes directory.
Update the value of jira.home to the current JIRA_HOME directory or to a copy of that directory.
Copy any modified files.
Start up the new JIRA.
Update the add-ons once JIRA starts successfully.
Remove the previous installation directory to avoid confusion.

How it works…

What we are doing here is essentially setting up a new instance of JIRA and pointing it to the old JIRA's data. When we start up the new JIRA, it will detect that the database it is connecting to contains data from an older version of JIRA by reading the dbconfig.xml file from the JIRA_HOME directory. It will also proceed to make all the necessary schema changes.

Migrating JIRA to another environment

Now that we have gone through upgrading a JIRA instance, we will look at how to move a JIRA instance to another server environment. This is a common use case when you need to move an application to a virtualized environment or data warehouse.

Getting ready

The following things need to be checked before you start with this recipe:

Make sure you have a valid JIRA license.
Check whether your new environment is compatible with JIRA system requirements.
Ensure both the old and new JIRA are of the same major or minor version. If you intend to run a newer version of JIRA in the new environment, it is recommended that you upgrade after the migration is successful.
Tip
Migrating a system can be very disruptive for users. Make sure you communicate this to your users and allocate enough time for rollbacks.

How to do it…

To migrate an existing JIRA to another server, perform the following steps:

Download and install a brand new JIRA instance in your new environment with an empty database.
Take your current JIRA offline.
Back up your current JIRA database with its native backup utility.
Back up your current JIRA_HOME directory.
Take your new JIRA offline.
Copy over your JIRA_HOME backup and replace the new JIRA_HOME directory with it.
Update the dbconfig.xml file with the new JIRA database details.
Copy your database backup and restore the new JIRA database.
Start up the new JIRA.
Note
If you have made modifications to your JIRA configuration files, you can get a complete list of the modified files from JIRA's System Info page.
Log in to JIRA as a JIRA administrator.
Select System Info from the Administration panel.
Note down the files listed in the Modified Files and Removed Files sections.
Review and apply the same changes to the new JIRA instance.

The following screenshot shows how the output will look:

Setting up the context path for JIRA

If you have multiple web applications running on the same domain, you might want to set up a context path for JIRA; for example, http://example.com/jira.

How to do it…

Perform the following steps to set up a context path for JIRA:

Shut down JIRA if it is running.
Open up JIRA_INSTALL/conf/server.xml in a text editor.
Locate the following line and enter the context path for the path attribute, for example, path="/jira":
```
<Context path="" docBase="${catalina.home}/atlassian-jira" reloadable="false" useHttpOnly="true">
```
Save the file and restart JIRA.
If you have updated the context path for JIRA after it is installed, you will have to update JIRA's Base URL option so that all its links will reflect the change.
Log in to JIRA as an administrator.
Navigate to Administration | Systems | General Configuration.
Click on the Edit Settings button.
Enter the fully qualified URL into JIRA, including the context path in the Base URL field.
Click on Update to apply the change.

After you have all this set up, you will be able to access JIRA with the new context path.

Setting up SSL

By default, JIRA runs with a standard, nonencrypted HTTP protocol. This is acceptable if you are running JIRA in a secured environment such as an internal network. However, if you plan to open up access to JIRA over the Internet, you need to tighten up the security by encrypting sensitive data, such as the usernames and passwords that are being sent, by enabling HTTP over SSL (HTTPS).

This recipe describes how to install SSL on the JIRA Tomcat application server. If you have an HTTP web server such as Apache in front of JIRA, you can install the SSL certificate in the web server instead.

Getting ready

You need to have the following set up before you can step through this recipe:

Obtain a valid SSL certificate. You can either use a self-signed certificate or obtain one from a Certificate Authority (CA) such as VeriSign. Using a self-signed certificate will display a warning message when users first visit the site, as shown in the following screenshot:
Ensure that the JAVA_HOME environment variable is set properly.
Make sure you know which JDK/JRE JIRA is using. You can find this information from the System Info page, where you need to look for the java.home property.
Make sure your JRE/JDK's bin directory is added to your PATH environment variable, and the keytool command will output its usage, as shown in the following screenshot:

How to do it…

Perform the following steps to import an SSL certificate:

Open up a command window and go to the directory where the certificate file resides.
Generate a Java KeyStore (JKS) for JIRA by running the keytool -genkey -alias jira -keyalg RSA -keystore JIRA_INSTALL/jira.jks command.
Import the certificate into KeyStore by running the keytool –import –alias jira –keystore JIRA_INSTALL/jira.jks –file file.crt command, where file.crt is the certificate file.
Open the server.xml file located in the JIRA_INSTALL/conf directory in a text editor.
Locate and uncomment the following XML configuration snippet:
```
<Connector port="8443" maxHttpHeaderSize="8192" SSLEnabled="true"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" useBodyEncodingForURI="true"/>
```
Note
Downloading the example code
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

Add a few new attributes to the Connector tag and save the file:

keystoreFile="PATH_TO_YOUR_KEYSTORE"
keystorePass="PASSWORD_FOR_YOUR_KEYSTORE"
keyAlias="jira"
keystoreType="JKS"

Restart JIRA to apply the changes.

How it works…

We first created a new Java KeyStore for JIRA to store its own SSL certificate with Java's keytool utility. During this step, you are prompted to provide information about the certificate as well as a password to access KeyStore.

Note

Do not lose the password to KeyStore.

After we created KeyStore, we imported the certificate and then enabled an additional connector to listen for HTTPS connections by uncommenting the connector XML tag. We also added new attributes to the tag so that Tomcat will know where our new KeyStore is and how to access it to get to the certificate.

You can also change the port number for the connector if you want to run HTTPS on the more common port 443 instead of the default 8443, and your final XML snippet will look something like the following:

<Connector port="443" maxHttpHeaderSize="8192" SSLEnabled="true"maxThreads="150" minSpareThreads="25" maxSpareThreads="75"enableLookups="false" disableUploadTimeout="true"acceptCount="100" scheme="https" secure="true"clientAuth="false" sslProtocol="TLS" useBodyEncodingForURI="true" keystoreFile="/opt/jira/jira.jks" keystorePass="changeme" keyAlias="jira" keystoreType="JKS"/>

There's more…

At this point, users can access JIRA with both HTTP and HTTPS, and you need to configure JIRA so that it will automatically redirect all the HTTP traffic to HTTPS. JIRA comes with a handy configuration utility that can help you set up this configuration.

Tip

You should first make sure your HTTPS configuration is working correctly before attempting this recipe.

Note that this utility is only available for standalone installations; if you are running a WAR installation, you can skip the following steps and move on to the manual setup section:

Open the command prompt and go to the JIRA_INSTALL/bin directory.
Depending on your OS, run the config.bat or config.sh file.
Select the Web Server tab from the JIRA Configuration Tool window.
Select the HTTP and HTTPs (redirect HTTP to HTTPs) option for Profile.
Click on the Save button at the bottom of the window as shown in the following screenshot.
Restart JIRA to apply the change.

If you cannot use JIRA Configuration Tool, you can perform the following steps to manually set up the configuration:

Open the web.xml file located in the JIRA_INSTALL/atlassian-jira/WEB-INF directory.

Add the following XML snippet at the end of the file, just before the closing </webapp> tag:

<security-constraint>
    <display-name>HTTP to HTTPs Redirection</display-name>
    <web-resource-collection>
        <web-resource-name>all-except-attachments</web-resource-name>
        <url-pattern>*.jsp</url-pattern>
        <url-pattern>*.jspa</url-pattern>
        <url-pattern>/browse/*</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

Restart JIRA to apply the change.

Installing SSL certificates from other applications

You might need to connect JIRA to other services such as LDAP, mail servers, and other websites. Often, these services make use of SSL. In such cases, the connection will fail, and you will see the following errors in your JIRA log file:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Getting ready

For this recipe, we will be using the Java keytool utility, so make sure you have the following configuration set up:

Obtain the SSL certificate from the target system.
Ensure that the JAVA_HOME environment variable is set properly.
Make sure you know which JDK/JRE JIRA is using. You can find this information from the System Info page, where you need to look for the java.home property.
Make sure your JRE/JDK's bin directory is added to your PATH environment variable, and the keytool command will output its usage.
Obtain the password for the Java trust store used by JIRA.

How to do it…

In this recipe, let's assume we want to connect JIRA to an LDAP server that is running on SSL. Perform the following steps to make it a trusted site inside JIRA:

Open up a command prompt and go to the directory where the certificate file resides.
Import the certificate into the trust store by running the keytool –import –alias tomcat –file file.cer JAVA_HOME\jre\lib\security\cacerts command, where file.cer is the certificate file.
Restart JIRA to apply the changes.

How it works…

When JIRA attempts to connect to an SSL-protected service, it will first determine whether the target service can be trusted by checking if the service's certificate is present in what is called the trust store. If the certificate is not present, the connection will fail.

The trust store is typically a KeyStore called cacerts and is located in the $JAVA_HOME/lib/security directory on the server.

We used the keytool utility to import the certificate to our local trust store, so the target service will be registered as a trusted service and allows JIRA to successfully connect to it.

There's more…

Manually downloading the certificate and running the keytool command every time can be a hassle. To make life easier for you, there is a free add-on called SSL for JIRA from Atlassian Labs that can help you automate some of the steps. You can download this add-on from the following link:

https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugin.jirasslplugin

Perform the following steps to use the SSL for JIRA add-on:

Log in to JIRA as a JIRA administrator.
Navigate to Administration | System | Configure SSL.
Type in the target system's address in the Rules textbox in the host:port format (for example, smtp.gmail.com:465).
Tip
You can add multiple systems by specifying each one on a new line.
Click on Save certificates as shown in the following screenshot.
Follow the instruction on the screen to copy over the cacerts file to the target location.
Restart JIRA to apply the changes.
Note
Do not confuse this add-on with running JIRA over SSL.

Resetting the JIRA administrator password

Sometimes, you might forget or lose the password to the account with the JIRA Administrator or JIRA System Administrator permission, and you cannot retrieve it using the password-reset option. For example, suppose JIRA does not have an SMTP server configured, or you are restoring JIRA from a data dump and do not know the account and/or password. In these cases, you need to reset the administrator password directly in the database.

Note

This recipe only applies to JIRA instances that use the default internal user directory option. External user management such as LDAP will not work with this recipe.

Getting ready

Since we will reset the password in JIRA's database, make sure you do the following:

Connect to the JIRA database either via the command line or a GUI
Update the JIRA database records

How to do it…

Let's assume we use the default mysql command-line tool and MySQL as the backend database for JIRA. If you are using a different database, you may need to change the following SQL statements accordingly:

Connect to the JIRA database with a client tool by running the mysql -u jirauser -p command, where jirauser is the username to access the JIRA database.
Tip
You can find JIRA's database details from the dbconfig.xml file located at JIRA_HOME.
Change to the JIRA database by running the use jiradb command, where jiradb is the name of JIRA's database.
Determine the groups that have the JIRA System Administrators global permission with the following SQL statement:
```
select perm_parameter from schemepermissions where PERMISSION=44;
```
Find users that belong to the groups returned in step 3 using the following SQL statement, where jira-administrators is a group returned from step 3:
```
select child_name, directory_id from cwd_membership where parent_name='jira-administrators';
```

Reset the user's password in the database with the following SQL statement, where admin is a user returned in step 4:

update cwd_user set credential='uQieO/1CGMUIXXftw3ynrsaYLShI+GTcPS4LdUGWbIusFvHPfUzD7CZvms6yMMvA8I7FViHVEqr6Mj4pCLKAFQ==' where user_name='admin';

Restart JIRA to apply the change.

How it works…

With JIRA's internal user directory, all the user and group data are stored in the JIRA database. The value 44 is the ID for the JIRA System Administrators global permission.

If you do not know what groups or users have been granted the JIRA System Administrators global permission, we will first have to find this information using steps 3 and 4. Otherwise, you can skip to step 5 in order to reset the password.

JIRA's user password information is stored in the cwd_user table. Since JIRA only stores the hash value of the password, we changed the user's admin password to uQieO/1CGMUIXXftw3ynrsaYLShI+GTcPS4LdUGWbIusFvHPfUzD7CZvms6yMMvA8I7FViHVEqr6Mj4pCLKAFQ==, which is the hash value of sphere.

Generating test data in JIRA

For many production JIRA instances, it is often important to understand how it will perform under an anticipated load, how well it scales as the usage grows, and whether the hardware will be able to support the anticipated growth.

This can be tricky for new installations, as an empty JIRA cannot realistically provide any performance indication. In this recipe, we will look at how we can generate any arbitrary amount of test data to simulate an anticipated data size. For example, we will be able to measure the average response time and how long it takes to reindex the system.

Note

Use this recipe in your test environment. Do not use this in production.

Getting ready

For this recipe, we need to use the JIRA Data Generator add-on from Atlassian Labs. You can download this add-on at the following link:

https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-data-generator

How to do it…

Once the add-on is installed in JIRA, perform the following steps to generate test data:

Log in to JIRA as a JIRA administrator.
Navigate to Administration | System | Generate Metadata:
Set the number of projects and other metadata to generate.
Click on Generate and wait for the process to complete.
Select Generate Data.
Set the number of issues, comments, and other data that is to be generated.
Click on Generate and wait for the process to complete, as shown in the following screenshot:

How it works…

Generating test data in JIRA with the JIRA Data Generator add-on is a two-step process. We first need to create all the necessary configuration metadata such as custom fields and workflows and then create the issues.

Anonymizing JIRA exports

Sometimes, in order to troubleshoot your JIRA instance, you need to provide a data dump for Atlassian or another service vendor so that they can recreate your environment to reproduce the problem locally. If you have sensitive information in your JIRA, this can be troublesome. In this recipe, we will look at how we can anonymize our data in JIRA.

Getting ready

For this recipe, we need to use the JIRA Anonymizer utility. You can download it from the following link:

https://confluence.atlassian.com/download/attachments/139008/jira_anon.zip?version=1&modificationDate=1367988226752&api=v2

To run the Anonymizer utility, make sure that the following prerequisites are met on the machine you are running the utility from:

Make sure the JAVA_HOME environment variable is set properly
Running the java -version command will display the correct version of Java

How to do it…

Perform the following steps to anonymize your JIRA export:

Unzip the jira_anon.zip file to a temporary directory.
Copy your JIRA XML export (entities.xml) to the temporary directory.
Open up a command prompt and go to the temporary directory where the joost.jar file resides.
Run the anonymizer application with the java -Xmx512m -jar joost.jar entities.xml anon.stx > anon-entities.xml command, where entities.xml is the name of the original XML export and anon-entities.xml is the new anonymized XML file to be created.
Note
JIRA's XML backup utility produces a ZIP file that contains two XML files; do not anonymize activeobjects.xml.

How it works…

The JIRA Anonymizer protects sensitive information in your JIRA by going through your JIRA XML export and replacing values from many fields in JIRA with a string of the character x. The list of fields that are to be anonymized include the following:

Issue summary, environment, and description
Comments, work logs, and change logs
The project description
Configuration scheme description such as the notification and permission schemes
Attachment filenames
Text custom field types

Depending on the size of the export, the utility may require additional memory for processing. The -Xmx parameter indicates the amount of memory to allocate, so in the preceding steps, we allocated 512 MB of memory to run the utility.