MantisBT 2.28.4

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick MantisBT 2.28.4 Bug Tracker on Ubuntu 24.04 as the software version and choose your Region. Then choose Launch through EC2.

Choose m5.large, your key pair, a security group as described in Prerequisites, and a subnet. The AMI has two volumes: the 8 GiB root volume and a 20 GiB data volume for the database. Increase the data volume at launch if you expect many attachments, because MantisBT stores attachments in the database.

To launch with the AWS CLI, replace the values in angle brackets:

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=mantisbt}]'

Connect over SSH. For MantisBT 2.28.4 Bug Tracker on Ubuntu 24.04, the SSH user is ubuntu.

ssh -i <your-key.pem> ubuntu@<public-ip>

First boot creates the database, the certificate and the secrets. Then PHP and nginx start. Check the units:

systemctl is-active mariadb php8.3-fpm nginx mantisbt-firstboot
sudo test -f /var/lib/sac/data/mantisbt-firstboot.done && echo FIRSTBOOT_DONE

All four units are active, and the first-boot marker is present:

active active active active FIRSTBOOT_DONE

Only SSH and nginx listen on the network. MariaDB has no TCP listener at all, and PHP-FPM uses a local socket:

sudo ss -lntp | awk 'NR>1 {print $4, $6}' | grep -v '127.0.0.5' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g' | sort

0.0.0.0:22 users:(("sshd"),("systemd")) 0.0.0.0:443 users:(("nginx"),("nginx"),("nginx")) 0.0.0.0:80 users:(("nginx"),("nginx"),("nginx")) [::]:22 users:(("sshd"),("systemd")) [::]:443 users:(("nginx"),("nginx"),("nginx")) [::]:80 users:(("nginx"),("nginx"),("nginx"))

Read the credentials file as root:

sudo cat /var/lib/sac/data/mantisbt-credentials.txt

Only root can read the file. It holds the URL, the administrator's user name and this instance's password:

# MantisBT 2.28.4 - generated on first boot by mantisbt-firstboot.service
# These credentials are unique to this instance; none was baked into the image. MantisBT stores only a hash of the
# password. Keep this file secret and change the password after your first sign-in (My Account). MANTISBT_URL=https://ec2-<public-ip-dashed>.<region>.compute.amazonaws.com/ MANTISBT_ADMIN_USER=administrator MANTISBT_ADMIN_PASSWORD=<MANTISBT_ADMIN_PASSWORD>
#
# Open MANTISBT_URL in a browser (self-signed certificate minted on this instance's first boot; port 80 redirects to # https) and sign in. Self-signup, anonymous access and e-mail are OFF; create users under Manage > Manage Users. # Database: MariaDB 'bugtracker' over the local socket only (no network listener, no database password). # Self-test:
sudo mantisbt-selftest Change the served name:
sudo mantisbt-set-hostname <your-dns-name>
# User guide: https://secureanycloud.com/stacks/mantisbt-2-28-4/

The URL uses the instance's public DNS name from EC2 instance metadata. The certificate also names the public and private IP addresses, so https://<public-ip>/ works too. MantisBT then redirects you to the configured name. To serve MantisBT under your own DNS name, see Step 10.

Open the MANTISBT_URL in your browser. The certificate is self-signed, so your browser asks you to confirm it the first time. Alternatively, install your own certificate (Step 10).

Enter administrator and choose Login. Enter the password from Step 4 and choose Login again:

Then change the password. Open the administrator menu at the top right and choose My Account. Enter the current password and a new one, and choose Update User.

The image includes a self-test. Through nginx, it signs the administrator in with MantisBT's real login form. It checks that the default password root and a blank password are refused, and it clears the failed attempts again so that the account is never locked. It also checks the security settings:

sudo mantisbt-selftest

SELFTEST-OK https 301 + health + administrator signed in via the login form + default 'root' and blank refused + installer/config/SOAP 404 + signup refused + 403 cross-origin POST + 403 cross-site logout (session kept) + 444 unknown host

MantisBT records every issue in a project. As the administrator, open Manage, then Projects, and choose Create New Project. Give the project a name (for example Web Shop) and choose Add Project.

Pick the project in the project menu at the top right, then choose Report Issue. Select a category, write a summary and a description, set the severity and choose Submit Issue.

My View collects the issues assigned to you, the unassigned ones, the ones you reported and recent changes, with a timeline of activity:

View Issues lists and filters every issue. Save a filter to reuse it:

Open an issue to see and change its status, assignee, severity, tags, relationships and notes:

Self-signup is off, so an administrator creates every account. Open Manage, Users, then Create New Account. Enter the user name, real name, email address and access level (viewer, reporter, updater, developer, manager or administrator).

Email is off until you configure it (Step 9), so MantisBT asks you for the new user's password on the same form. Give the password to the user and ask them to change it under My Account. Give each project its own users and access levels under Manage, Projects.

MantisBT locks an account after five failed sign-ins in a row. An administrator unlocks it under Manage, Users (the account's page, Reset Password or edit it). You can always unlock the administrator on the instance:

echo "UPDATE mantis_user_table SET failed_login_count=0 WHERE username='administrator';" | sudo mariadb bugtracker

MariaDB runs on the instance with its data on the data volume. It has no network listener (skip_networking), and every account signs in with operating system authentication, so there are no passwords anywhere. MantisBT's database user has privileges on its own database only:

sudo mariadb -N -e "SELECT @@version, @@datadir, @@skip_networking; SELECT CONCAT(User,'@',Host), IF(Priv LIKE '%unix_socket%','unix_socket','-'), IF(COALESCE(JSON_VALUE(Priv,'$.authentication_string'),'') IN ('','invalid'),'no password','PASSWORD') FROM mysql.global_priv ORDER BY 1; SHOW GRANTS FOR 'mantisbt'@'localhost';"

10.11.14-MariaDB-0ubuntu0.24.04.1 /var/lib/mysql/ 1 mantisbt@localhost unix_socket no password mariadb.sys@localhost - no password mysql@localhost unix_socket no password root@localhost unix_socket no password GRANT USAGE ON *.* TO `mantisbt`@`localhost` IDENTIFIED VIA unix_socket GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES ON `bugtracker`.* TO `mantisbt`@`localhost`

mariadb.sys is MariaDB's locked internal account and cannot sign in. root signs in only as the operating system root user, with sudo mariadb. The database directory is the data volume:

findmnt -no SOURCE,TARGET,FSTYPE /data
findmnt -no TARGET /var/lib/mysql df -h --output=size,target /data | tail -1

/dev/nvme1n1 /data ext4 /var/lib/mysql 20G /data

To grow the volume, enlarge the EBS volume in the EC2 console. Then run sudo resize2fs on the device that findmnt -no SOURCE /data shows. Attachments are stored in the database, so back it up as one unit. This command takes a consistent backup to a directory of your choice:

sudo mkdir -p <backup-dir> && sudo mariadb-dump --single-transaction --routines bugtracker | gzip | sudo tee <backup-dir>/bugtracker-$(date +%F).sql.gz >/dev/null

Also keep copies off the instance, for example in Amazon S3, or take EBS snapshots of the data volume.

Email is off, so MantisBT sends no notifications and the lost-password link is hidden. To use your own SMTP relay (for example Amazon SES), add these lines to the end of /etc/mantisbt/config_inc.php as root, with your relay's values:

sudo tee -a /etc/mantisbt/config_inc.php >/dev/null <<'EOF' $g_enable_email_notification = ON; $g_lost_password_feature = ON; $g_send_reset_password = ON; $g_phpMailer_method = PHPMAILER_METHOD_SMTP; $g_smtp_host = 'email-smtp.<region>.amazonaws.com'; $g_smtp_port = 587; $g_smtp_connection_mode = 'tls'; $g_smtp_username = '<smtp-user>'; $g_smtp_password = '<smtp-password>'; $g_from_email = 'mantisbt@<your-domain>'; $g_webmaster_email = 'admin@<your-domain>'; EOF

Configuration changes apply to the next page you open. Allow outbound TCP 587 from the instance to your relay. You can enable self-signup ($g_allow_signup = ON;) and anonymous access ($g_allow_anonymous_login = ON; with $g_anonymous_account) the same way. Leave them off for an internal tracker.

Point a DNS name at the instance's public IP address (or an Elastic IP), then tell MantisBT to use it. This command sets MantisBT's base URL, the names that nginx accepts and the guards. It also generates a new self-signed certificate for the name:

sudo mantisbt-set-hostname mantis.<your-domain>

To use a certificate from a public certificate authority, put the certificate chain in /etc/ssl/mantisbt/mantisbt.crt and its private key in /etc/ssl/mantisbt/mantisbt.key (root-only, mode 600). Then run sudo systemctl reload nginx. Alternatively, put MantisBT behind an Application Load Balancer with an AWS Certificate Manager certificate that forwards to port 443 on the instance.

The nginx, PHP and MariaDB services are blocked from the instance metadata service:

for u in nginx php8.3-fpm mariadb; do printf '%s ' "$u"; systemctl show -p IPAddressDeny --value "$u" | tr ' ' '\n' | sort | tr '\n' ' '; echo; done

nginx 168.63.129.16/32 169.254.169.254/32 fd00:ec2::254/128 php8.3-fpm 168.63.129.16/32 169.254.169.254/32 fd00:ec2::254/128 mariadb 168.63.129.16/32 169.254.169.254/32 fd00:ec2::254/128

nginx refuses a state-changing request that another website's page sends. It also refuses a link from another site to one of the pages that change state on a plain link:

curl -sk -o /dev/null -w '%{http_code}\n' -X POST -H 'Origin: https://evil.example' --data 'username=x' https://localhost/login.php
curl -sk -o /dev/null -w '%{http_code}\n' -H 'Sec-Fetch-Site: cross-site' https://localhost/logout_page.php
curl -sk -o /dev/null -w '%{http_code}\n' https://localhost/admin/install.php

403 403 404

Other notes:

• Passwords. MantisBT stores the MD5 hash of each password. This is its standard login method, and the alternatives in MantisBT 2.28 are LDAP or HTTP authentication. The administrator password that this image generates is a 24-character random string. Ask your users to choose long passwords, or connect MantisBT to your directory with LDAP ($g_login_method = LDAP; and the $g_ldap_* settings).
• REST API. Create a personal API token under My Account, API Tokens. Send it in the Authorization header to https://<your-host>/api/rest/. The SOAP API (deprecated by MantisBT) is not served on this image.
• Browser libraries. MantisBT 2.28.4 ships jQuery 2.2.4 and Bootstrap 3.4.1. Public advisories exist for both, with no fix in those major versions. MantisBT serves every page with a Content Security Policy that allows only its own scripts (no inline or third-party script). This blocks those script injection paths, and the image keeps that policy.
• Logs and sessions. PHP keeps login sessions in memory (/run/mantisbt-sessions), so a reboot signs everyone out. nginx logs are in /var/log/nginx.

Ubuntu security updates install automatically. To apply all updates now:

sudo apt-get update && sudo apt-get upgrade -y

You update MantisBT itself by replacing the release files. Download the new release from mantisbt.org and check its checksum. Copy it over /var/www/mantisbt, keeping /etc/mantisbt. Run MantisBT's database upgrade from the release's admin/ directory, then remove admin/ again. Back up the database first (Step 8), and read the MantisBT release notes before you upgrade.