Install JasperReports Server on RHEL, Rocky Linux, AlmaLinux and Fedora

JasperReports Server delivers web-based reporting, dashboards, and ad hoc analytics on top of a Java web application and a repository database. On RHEL, Rocky Linux, AlmaLinux, CentOS Stream, Oracle Linux, and Fedora you can deploy it with the self-contained Linux .run installer or with the standalone WAR distribution on Tomcat and PostgreSQL you manage yourself.

This guide maps both paths to RPM-family packaging: dnf, distribution Tomcat layout, firewalld, and SELinux. The RPM-family concepts are shared, but package availability, Tomcat versions, filesystem paths, and SELinux policy can differ by distribution and release. Deployment steps follow the JasperReports Server installation documentation for the release you download—they are not a substitute for the vendor platform-support matrix or your licensed build’s install guide.

Validated environment: Package availability, OpenJDK, Tomcat, firewalld, and SELinux commands were checked on Rocky Linux 10.2. JasperReports Server installation requires licensed or trial media. Commands in the deployment sections follow JasperReports Server 10.x documentation and must be adjusted to the exact supported-platform matrix for your licensed release.

JasperReports Server Installation Options

JasperReports Server needs three layers: a supported JDK, a servlet container (Tomcat on Linux), and a repository database (PostgreSQL is the usual choice). How you deliver those layers determines which install path fits.

Jaspersoft classifies the binary installer as evaluation-only. Use it for demonstrations, trials, and disposable labs. For production, use the standalone WAR distribution with supported application-server and database versions from your release matrix.

Check System Requirements and Supported Versions

Requirements change between JasperReports Server major and minor releases. Open the installation guide and platform-support document for the exact build you downloaded before you size the host or install packages.

The table below reflects JasperReports Server 10.0 guidance as published in the vendor installation documentation. Confirm the values for your patch level—do not treat this table as universal across older or future releases.

Plan hostname resolution and outbound access if the server must reach LDAP, email, or external data sources. Chrome or Chromium is optional during install but required for graphical report and dashboard export to PDF and related formats.

Prepare RHEL, Rocky Linux, AlmaLinux or Fedora

Refresh repository metadata and install the utilities you need for download, extraction, and service management. Steps below use sudo with dnf:

sudo dnf makecache
sudo dnf install -y java-21-openjdk-headless wget tar gzip unzip which

Apply pending system updates according to your organization’s patching policy before production deployment. For lab preparation you can run sudo dnf update -y first, but a full upgrade can introduce unrelated package changes or a reboot requirement.

Match the JDK package to your JasperReports Server release notes—the example below uses Java 21 on Rocky Linux 10 only as a host-prep illustration. Confirm that JDK major version in the platform-support guide for your edition before you install WAR or binary media.

Confirm Java is on the path:

java -version

Sample output:

openjdk version "21.0.11" 2026-04-21 LTS
OpenJDK Runtime Environment (Red_Hat-21.0.11.0.10-1) (build 21.0.11+10-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-21.0.11.0.10-1) (build 21.0.11+10-LTS, mixed mode, sharing)

Set JAVA_HOME in the service environment or shell profile when Buildomatic or Tomcat expects it. Discover the path from the java binary you installed—directory names can include architecture or build suffixes:

readlink -f "$(command -v java)"

Sample output:

/usr/lib/jvm/java-21-openjdk/bin/java

Derive JAVA_HOME from that path:

export JAVA_HOME="$(dirname "$(dirname "$(readlink -f "$(command -v java)")")")"

On Rocky Linux 10.2 the result is /usr/lib/jvm/java-21-openjdk. Confirm the fixed path exists before you hard-code it in a service unit:

ls -ld /usr/lib/jvm/java-21-openjdk*

Check hostname resolution with hostnamectl or hostname—JasperReports Server and JDBC URLs are easier to debug when forward and reverse DNS are consistent:

hostname -f
getent hosts "$(hostname -f)"

Review SELinux mode before you troubleshoot “permission denied” errors later. Production hosts should stay in enforcing mode—understand how SELinux modes differ before you change policy, but do not disable SELinux as a shortcut here:

getenforce

Sample output:

Enforcing

Keep SELinux enforcing and fix contexts or booleans rather than disabling it permanently.

Confirm firewalld is running if you use it:

sudo firewall-cmd --state

Sample output:

running

Check memory and root filesystem space with df and du against the JasperReports Server 10 requirements table before you download media:

free -h
df -h /

Sample output:

Mem:           3.8Gi       2.7Gi       239Mi       1.2Mi       1.2Gi       1.2Gi
/dev/mapper/rlm-root   14G   10G  3.1G  77% /

This lab host falls below the 8 GB RAM minimum for JasperReports Server 10—a production or evaluation install needs more memory than shown here.

Chrome or Chromium for export

JasperReports Server uses a configured Chrome or Chromium engine for graphical report and dashboard rendering and export. Installation can continue without a browser, but those export capabilities stay unavailable until you configure one.

Availability varies by distribution and enabled repositories—not every Enterprise Linux release ships chromium from the same source, and Fedora may differ from RHEL-family builds. Check before you install:

dnf info chromium

On Rocky Linux 10.2 with EPEL enabled, chromium is available from the epel repository. Install only when dnf info shows a package for your host:

sudo dnf install -y chromium

If no supported package exists, follow the vendor-supported Chrome or Chromium installation option for your release and point the installer or server configuration at that binary. On Enterprise Linux hosts that rely on EPEL, enable EPEL on your distribution first when the package is not in base repositories.

Method 1: Install with the Linux Binary Installer

The binary installer ships Tomcat, PostgreSQL, and the JasperReports Server application in one .run file. The steps below summarize the vendor wizard; exact prompts, paths, and archive layout depend on the build you download.

Download and verify the installer

Download the Linux x86_64 .run installer from your Jaspersoft account, trial page, or licensed software portal. Use wget when the portal provides a direct HTTPS URL. Legacy Community builds may appear on third-party mirrors—verify checksums and licensing before you use them.

Typical filename pattern:

TIB_js-jrs-<version>_linux_x86_64.run

Make the installer executable:

chmod +x TIB_js-jrs-*_linux_x86_64.run

The command exits silently on success. Compare SHA-256 checksums when the vendor publishes them.

Run the installer

Launch the installer from a shell with enough disk space and RAM for JasperReports Server 10:

./TIB_js-jrs-*_linux_x86_64.run

The wizard asks you to accept the license, choose Install All Components or Custom Install, set the installation directory, and optionally configure Chrome or Chromium for export. Standard install bundles PostgreSQL and Tomcat. Custom installation can expose additional component choices, such as using an existing supported PostgreSQL instance. Whether an external Tomcat can be selected depends on the installer build. For a separately managed Tomcat, prefer the standalone WAR distribution.

Meaningful choices during setup (wording varies by release):

• Install all components — fastest evaluation path; installs bundled PostgreSQL and Tomcat.
• Custom install — use when port 5432 is taken or you already run a supported PostgreSQL instance elsewhere.
• Chrome or Chromium path — set only after you install a supported browser; export features need this path.
• Keystore warning — back up .jrsks and .jrsksp before you overlay an older install.

Choose bundled or custom components

Start and stop JasperReports Server

After install, change to the installation directory named in the wizard and use the vendor control script—commonly ctlscript.sh at the install root:

cd /path/to/jasperreports-server-install/
./ctlscript.sh start

The vendor script starts bundled PostgreSQL and Tomcat in sequence. Review the transcript on your host for the exact service names and ports your build reports.

Stop all bundled components:

./ctlscript.sh stop

Check status:

./ctlscript.sh status

Paths and service names vary by install directory and version. Use the control script supplied by your binary installer—commonly ctlscript.sh—unless that release’s documentation specifies another service-management method.

Method 2: Install JasperReports Server WAR on Tomcat

The standalone WAR distribution is the enterprise production path Jaspersoft documents. You manage Tomcat and PostgreSQL, configure Buildomatic for your database and application server, then run the version-provided installation script. Archive layout, property file names, and whether the WAR is prebuilt or generated during install can vary by edition and package—inspect your downloaded media before you run commands.

Install Java and Tomcat

Install the JDK and Tomcat versions that appear in the platform-support guide for your JasperReports Server release. For OpenJDK installation, alternatives, and JAVA_HOME on RPM-family Linux, see install Java on RHEL, Rocky Linux, AlmaLinux and Fedora.

First check which Tomcat version your enabled repositories provide:

dnf info tomcat tomcat9

Sample output on Rocky Linux 10.2:

Installed Packages
Name         : tomcat
Version      : 10.1.49
...
Available Packages
Name         : tomcat9
Version      : 9.0.117

Do not install the distribution package until its major and minor versions match the JasperReports Server platform-support matrix. JasperReports Server 10 supports Tomcat 10.1.24 or later within the Tomcat versions listed in its platform-support matrix. Do not assume that every newer Tomcat major release is automatically supported. Some Enterprise Linux releases also ship tomcat9 based on Tomcat 9, which does not satisfy JasperReports Server 10’s Jakarta requirement—Red Hat documents tomcat9 as the initially supplied Tomcat package on RHEL 10, so a RHEL user must not blindly copy Rocky Linux’s tomcat package command and assume it provides Tomcat 10.1.

The example below was validated on Rocky Linux 10.2, where the enabled repositories provided Tomcat 10.1. Other RHEL-family distributions or releases may provide Tomcat 9, a differently named package, or no compatible package. In those cases, use a vendor-supported Tomcat distribution rather than forcing an incompatible RPM.

Install the JDK and Tomcat on Rocky Linux 10.2 after you confirm both versions in the matrix:

sudo dnf install -y java-21-openjdk-devel tomcat

Production WAR installs often need the full JDK (-devel) for Buildomatic even when runtime Tomcat only requires a JRE. Do not install tomcat-admin-webapps unless you deliberately deploy and secure the Tomcat Manager application—it is not required for JasperReports Server.

Enable and start Tomcat through systemctl:

sudo systemctl enable --now tomcat

Sample output:

Created symlink '/etc/systemd/system/multi-user.target.wants/tomcat.service' → '/usr/lib/systemd/system/tomcat.service'.

On the tested Rocky Linux 10.2 host, configuration lives under /etc/tomcat/ and web applications deploy to /var/lib/tomcat/webapps/. The packaged service ran as the tomcat user in the tomcat_t SELinux domain. Verify the service account and process domain with ps on your system:

systemctl show tomcat -p User
ps -eZ | grep -E 'tomcat|java'

Sample output:

User=tomcat
system_u:system_r:tomcat_t:s0    172139 ?        00:00:01 java

Package users and SELinux policy details can differ across Fedora, RHEL, Oracle Linux, and repository sources.

Create the JasperReports service user

For Buildomatic installs under /opt, create a dedicated account with useradd that owns the extracted distribution and configuration. Adjust the account name and home directory to match your security policy:

sudo useradd -r -m -d /opt/jasperserver -s /sbin/nologin jasper
sudo mkdir -p /opt/jasperserver
sudo chown jasper:jasper /opt/jasperserver

Set directory ownership with chown when the Buildomatic tree must not remain root-owned. Distribution Tomcat can keep using the tomcat user while Buildomatic files live under /opt/jasperserver—separate ownership reduces permission conflicts during deploy.

Download and extract the WAR distribution

Download the standalone WAR file distribution (commonly a js-jrs_*_bin.zip archive) from Jaspersoft and extract it to a working directory owned by the install user:

sudo -u jasper unzip -d /opt/jasperserver /path/to/js-jrs_*_bin.zip

List the top-level contents on your host before you continue—do not assume a fixed file list across editions:

sudo -u jasper ls /opt/jasperserver

Your archive should include a buildomatic/ directory and the version-provided install scripts. The WAR may be present in the archive or produced during the Buildomatic deploy step depending on edition and package.

Configure Buildomatic

Work from the buildomatic/ directory inside your extracted distribution:

1. Enter buildomatic/.
2. Copy the sample master properties file that matches your database type and application server—for PostgreSQL and Tomcat, vendors typically ship a sample_conf/ template such as postgresql_master.properties (confirm the exact filename in your package).
3. Edit the active properties file (often default_master.properties after you copy the sample) for database host, port, database name, administrator credentials, application-server path, Java settings, and deployment directories.
4. Separate database administrator credentials used during install from application runtime credentials when your DBA policy requires it—Buildomatic may create databases, roles, and schemas depending on how you configure administrator access.

Only publish exact property keys and paths after you inspect your downloaded release and its install guide.

Installation script (per your release)

From buildomatic/, the vendor documentation typically directs you to run an install script named in your distribution—commonly js-install.sh:

cd /opt/jasperserver/buildomatic
sudo -u jasper ./js-install.sh

Review the full Buildomatic transcript for JDBC errors, permission failures, and deploy warnings before you start or restart Tomcat. A generic one-line install command is not guaranteed to succeed without the correct sample configuration, credentials, and supported paths for your release.

Start Tomcat and review deployment logs

After Buildomatic completes on your host, restart Tomcat:

sudo systemctl restart tomcat

Check service state through journalctl—packaged Tomcat on Rocky Linux 10 logs to the journal and may also write dated files under /var/log/tomcat/:

sudo journalctl -u tomcat -n 100 --no-pager

Sample output (trimmed):

Jul 12 11:16:17 rocky1 server[172139]: main class used: org.apache.catalina.startup.Bootstrap
Jul 12 11:16:17 rocky1 server[172139]: options used: -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat ...

List log files present on your host—do not assume catalina.out exists:

sudo find /var/log/tomcat -maxdepth 1 -type f -ls

On Rocky Linux 10.2 with distribution Tomcat, logs appear as dated files such as catalina.2026-07-12.log under /var/log/tomcat/. After Buildomatic completes on your host, check whether the deployed WAR (or the context path your build uses) expanded under /var/lib/tomcat/webapps/.

Configure the Repository Database

Use bundled PostgreSQL

The binary installer creates a local PostgreSQL instance when you accept bundled database setup. Default listener port is 5432 unless the wizard prompts for an alternate.

Back up a bundled repository with pg_dump or the backup procedure documented for that PostgreSQL instance. Do not copy a live PostgreSQL data directory and treat it as a consistent backup unless the database is stopped and your procedure is designed for physical backup.

Use an external PostgreSQL server

Install PostgreSQL on a dedicated host or use an existing cluster. On Rocky Linux, see install PostgreSQL on Rocky Linux for repository setup before you create repository roles. The example below uses jasperdb as both the role and database name—match the role and database design expected by your version’s Buildomatic properties and organizational database policy:

CREATE ROLE jasperdb LOGIN PASSWORD 'strong-password';
CREATE DATABASE jasperdb OWNER jasperdb;

Buildomatic may create databases, roles, and schemas when you supply database administrator credentials during install. Jaspersoft’s WAR documentation recommends Tomcat with PostgreSQL but requires the actual database setup to follow the selected Buildomatic configuration. A production deployment may separate install-time administrator credentials from application runtime credentials and may use different database names than this example.

Test PostgreSQL network connectivity and authentication from the application host before configuring JDBC:

psql -h db.example.com -U jasperdb -d jasperdb -c 'SELECT 1'

A successful connection prints a single row with 1. Install the postgresql client package with dnf install postgresql if psql is not on the host yet. Buildomatic and Tomcat perform the actual JDBC test during deployment.

Use the same host, port, database name, and credentials in your Buildomatic properties file or the installer custom database panel.

Database permissions and connectivity checks

The credentials used by Buildomatic need sufficient privileges to create or update the required databases, schemas, roles, and objects. Runtime credentials need the permissions required by JasperReports Server after deployment. These may be separate accounts in a DBA-managed environment. Firewall rules must allow the application host to reach PostgreSQL on the configured port. For other supported databases (MySQL, Oracle, SQL Server), follow the vendor matrix for your release—do not assume PostgreSQL settings copy verbatim.

Configure Firewall and SELinux

Open the HTTP port clients use to reach Tomcat with firewalld permanent rules—8080 unless you changed the connector:

sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload

The reload command prints success when firewalld applies the permanent rule.

List open ports to confirm:

sudo firewall-cmd --list-ports

Sample output:

8080/tcp

If Tomcat listens on a custom port, open that port instead. Reverse proxies often expose 443 on the proxy while Tomcat stays on 8080 locally—open only what clients actually reach.

Do not enable SELinux booleans speculatively. Trigger the failed operation, inspect the AVC denial, and apply the smallest supported change that matches the actual process domain and resource.

After a failed start or JDBC connection, inspect recent denials:

sudo ausearch -m avc -ts recent

Identify the Tomcat or Java process domain before you change policy:

ps -eZ | grep -E 'tomcat|java'

Sample output on Rocky Linux 10 with distribution Tomcat:

system_u:system_r:tomcat_t:s0    172139 ?        00:00:01 java

Whether httpd_can_network_connect applies depends on that domain and packaging—it is not a universal Tomcat fix. Use sealert when available, verify file contexts with ls -Z, and adjust labels with semanage fcontext and restorecon when you place WAR files or logs on non-default paths. Create a narrowly scoped local policy only when no supported label or boolean covers the denial—do not run audit2allow blindly to silence AVCs. Do not set SELinux to permissive or disabled as a permanent workaround.

Service management

Binary installer

Use ctlscript.sh start, stop, and status from the install directory for evaluation installs. Wrapping the script in a systemd unit follows the same patterns as create a systemd service—validate on your host first: file ownership matches the service user, bundled PostgreSQL starts under that account, PID and forking behavior, stop timing, and reboot persistence. A single Type=forking unit that calls ctlscript.sh can report success while a child component fails—test systemctl start, stop, restart, enable, and reboot before you rely on it in production.

Externally managed Tomcat

When you deploy the WAR on distribution Tomcat, rely on the packaged unit:

sudo systemctl enable --now tomcat

Add a Restart=on-failure override only after Tomcat starts cleanly with the deployed WAR and you confirm log behavior through journalctl.

Access and Secure JasperReports Server

Open the login page in a browser:

http://SERVER-IP:8080/jasperserver

Replace SERVER-IP with your host name or load-balancer address. Use the initial administrator credentials documented for your edition and installation package. Some historical distributions used jasperadmin for both username and password—never assume those credentials apply to the current release, and change any default password immediately.

Hardening checklist:

• Change initial passwords and disable unused sample accounts.
• Restrict port 8080 with firewalld to management networks or place the app behind a reverse proxy.
• Terminate HTTPS at nginx or Apache HTTP Server and proxy to http://127.0.0.1:8080/jasperserver, or configure Tomcat-native TLS with Tomcat SSL and keytool.
• Protect PostgreSQL with host-based authentication and TLS where required.
• Restrict file permissions on keystores (.jrsks, .jrsksp) and Buildomatic properties files.

Export failures after login usually trace back to a missing or wrong Chrome or Chromium path—install a supported browser and point the server configuration at the binary documented for your release.

Upgrade, Backup and Uninstall

Before any upgrade:

• Dump the repository database with pg_dump (or your DBA’s standard logical backup for PostgreSQL).
• Export reports and repository content through JasperReports Server where your edition supports it.
• Back up the install directory, Buildomatic properties, and keystore files.

Binary installer upgrades often mean a new .run install into a fresh directory or following the vendor upgrade guide for your major version. WAR upgrades require a matching WAR build, Buildomatic migration steps, and a Tomcat maintenance window.

Uninstall:

• Binary install — run the vendor uninstaller if provided, or stop with ctlscript.sh stop, remove the install directory, and drop the bundled database only after a verified logical backup.
• WAR install — remove the deployed WAR and expanded context from /var/lib/tomcat/webapps/, undo Buildomatic datasource entries, and drop the repository database only after a verified backup.

Plan rollback before you upgrade production—restoring pg_dump and the previous WAR build is faster when you documented the prior version.

Common Problems and Fixes

When Tomcat fails to bind port 8080, confirm the listener with the ss command before you change connector settings.

Binary Installer vs WAR Deployment

Use the binary installer only for evaluation when you need a self-contained demo. Use WAR deployment when operations owns Tomcat, PostgreSQL, backups, and change windows.

Summary

Install JasperReports Server on RHEL-family Linux with the evaluation .run installer for trials and labs, or with the standalone WAR distribution on Tomcat and PostgreSQL for production. Prepare the host with a supported JDK, optional Chrome or Chromium for export, adequate RAM and disk per your release guide, and working firewalld and SELinux policies. Open port 8080 (or your chosen HTTP port), complete Buildomatic configuration for your licensed build, verify the web UI, change initial credentials, and back up the repository logically with pg_dump before you upgrade.

Official references: Jaspersoft getting started, system requirements and installation (Jaspersoft Community), and the installation guide PDF for your exact release from Jaspersoft documentation.