Supported platforms: Ubuntu, Debian, RHEL, Oracle Linux, Amazon Linux.

Before You Start

Pyramid’s bundled PostgreSQL always runs on port 12130.

Two values are specific to your install — you get both in Step 5:

See what’s on your box:

systemctl list-units --type=service --all | grep -i pyramid

Paths by Platform

By default Pyramid installs to /opt/Pyramid with config.ini inside it.

Prerequisites

• sudo access
• 2x the current database size free on the backup filesystem
• Pyramid offline during the migration

Step 1: Install PostgreSQL 18

Ubuntu / Debian

sudo apt install -y curl ca-certificates
sudo install -d /usr/share/postgresql-common/pgdg
sudo curl -o /usr/share/postgresql-common/pgdg/apt.postgresql.org.asc \
--fail https://www.postgresql.org/media/keys/ACCC4CF8.asc
. /etc/os-release
echo "deb [signed-by=/usr/share/postgresql-common/pgdg/apt.postgresql.org.asc] \
https://apt.postgresql.org/pub/repos/apt ${VERSION_CODENAME}-pgdg main" \
| sudo tee /etc/apt/sources.list.d/pgdg.list
sudo apt update
sudo apt install -y postgresql-18 postgresql-client-18

Initialises and starts automatically — no initdb.

RHEL / Oracle Linux

sudo dnf install -y \
https://download.postgresql.org/pub/repos/yum/reporpms/EL-$(rpm -E %{rhel})-x86_64/pgdg-redhat-repo-latest.noarch.rpm
sudo dnf -qy module disable postgresql
sudo dnf install -y postgresql18-server postgresql18-contrib
sudo /usr/pgsql-18/bin/postgresql-18-setup initdb
sudo systemctl enable --now postgresql-18

If Oracle’s own PostgreSQL packages conflict:

sudo dnf install -y postgresql18-server --disablerepo=ol\* --enablerepo=pgdg18

Amazon Linux 2023

rpm -E %{rhel} doesn’t resolve here, so pin EL9:

sudo dnf install -y \
https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm
sudo dnf -qy module disable postgresql 2>/dev/null || true
sudo dnf install -y postgresql18-server postgresql18-contrib
sudo /usr/pgsql-18/bin/postgresql-18-setup initdb
sudo systemctl enable --now postgresql-18

GPG key complaints:

sudo rpm --import https://download.postgresql.org/pub/repos/yum/keys/PGDG-RPM-GPG-KEY-RHEL

Verify

sudo -u postgres psql -c "SELECT version();"

Do Step 2 before anything else.

Step 2: Configure PostgreSQL 18

2a. postgresql.conf

Ubuntu / Debian:

sudo nano /etc/postgresql/18/main/postgresql.conf

RHEL / Oracle / Amazon:

sudo nano /var/lib/pgsql/18/data/postgresql.conf

In the CONNECTIONS AND AUTHENTICATION section:

listen_addresses ships commented out, which means it defaults to localhost and refuses remote connections. Remove the # and set:

listen_addresses = '*'

Single-server installs can leave this at the default. Multi-server must change it.

port should already read:

port = 5432

max_connections — 100 is too low for Pyramid’s service pools:

max_connections = 1000

2b. pg_hba.conf

Ubuntu / Debian:

sudo nano /etc/postgresql/18/main/pg_hba.conf

RHEL / Oracle / Amazon:

sudo nano /var/lib/pgsql/18/data/pg_hba.conf

Pick one based on your security requirements.

Allow all (simplest, least secure):

# TYPE  DATABASE  USER  ADDRESS         METHOD
local   all       all                   peer
host    all       all   127.0.0.1/32    scram-sha-256
host    all       all   0.0.0.0/0       scram-sha-256
host    all       all   ::1/0           scram-sha-256
host    all       all   ::/0            scram-sha-256

Allow a subnet — replace with your own (v4 and v6):

# TYPE  DATABASE  USER  ADDRESS            METHOD
local   all       all                      peer
host    all       all   127.0.0.1/32       scram-sha-256
host    all       all   192.168.1.0/24     scram-sha-256
host    all       all   ::1/128            scram-sha-256

Keep the local ... peer line — later steps need it.

2c. Restart and verify

Ubuntu / Debian:

sudo systemctl restart postgresql@18-main

RHEL / Oracle / Amazon:

sudo systemctl restart postgresql-18

Then:

sudo -u postgres psql -c "SHOW listen_addresses;"
sudo -u postgres psql -c "SHOW max_connections;"
sudo ss -lntp | grep 5432

2d. Firewall

Ubuntu / Debian — replace with your subnet:

sudo ufw allow from 192.168.1.0/24 to any port 5432 proto tcp

RHEL / Oracle Linux:

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

Amazon Linux / EC2 has no local firewall by default — add an inbound TCP 5432 rule to the instance’s Security Group.

RHEL / Oracle with SELinux issues:

sudo ausearch -m avc -ts recent
sudo setsebool -P httpd_can_network_connect_db on

Step 3: Create the Backup Directory

Own it yourself, or later steps hit permission errors:

sudo mkdir -p /var/backups/pyramid
sudo chown -R $(whoami):$(whoami) /var/backups/pyramid
chmod 700 /var/backups/pyramid
ls -ld /var/backups/pyramid

The output should show your username, not root. If you created it root-owned earlier, the chown -R above fixes it.

Step 4: Confirm the Pyramid Path

ls -l /opt/Pyramid/config.ini

If it’s elsewhere:

sudo find / -name config.ini -path '*yramid*' 2>/dev/null

Step 5: Get Your Database Name and Password

sudo sed -n '/\[data\]/,/^\[/p' /opt/Pyramid/config.ini

Output looks like:

[data]
password=encG_0_KsIojX/E13v+ylAocWuRpaTALBicK864V7YWlmGCU/UuCPGd5n/ZpTMI/y4=
type=postgres
port=12130
username=pyramid
database=pyramidb3e0d8e8
dbhost=localhost

The username is always pyramid, the port always 12130. You need the database= value.

Derive the password. The config.ini value is encrypted, but the real password is built from the database name — you are not decrypting anything. The rule is pyramid! plus everything after pyramid in the database name:

database name:   pyramidb3e0d8e8
password:        pyramid!b3e0d8e8

Print your actual values:

DB=$(sudo sed -n '/\[data\]/,/^\[/p' /opt/Pyramid/config.ini | grep '^database=' | cut -d= -f2)
if [[ "$DB" == pyramid* ]]; then
echo "Database name: $DB"
echo "Password:      pyramid!${DB#pyramid}"
else
echo "Database '$DB' does not start with 'pyramid' - the rule does not apply."
echo "Get the password from whoever built this environment."
fi

Verify them:

PGPASSWORD='<YOUR_PASSWORD>' psql -h 127.0.0.1 -p 12130 -U pyramid \
-d <YOUR_DATABASE> -c "\dt" | head

You should see a table list. If not, stop and fix it — the backup will fail the same way.

Use 127.0.0.1, not localhost. On some hosts localhost resolves to IPv6 first and the bundled PostgreSQL isn’t bound to it.

Step 6: Check Disk Space

df -h /var/backups/pyramid
PGPASSWORD='<YOUR_PASSWORD>' psql -h 127.0.0.1 -p 12130 -U pyramid -d postgres \
-c "SELECT pg_size_pretty(pg_database_size('<YOUR_DATABASE>'));"

Step 7: Stop the Pyramid Services — Leave pyramidPG Running

This stops every Pyramid service except the database, and skips anything not installed on this server:

for u in $(systemctl list-unit-files --type=service --no-legend \
| awk '{print $1}' | grep -i pyramid | grep -vi pyramidPG); do
echo "Stopping $u"
sudo systemctl stop "$u"
done

Confirm the database is still up — this must print active:

systemctl is-active pyramidPG.service

If it prints inactive:

sudo systemctl start pyramidPG.service
sleep 5
systemctl is-active pyramidPG.service

Step 8: Back Up config.ini

cp -a /opt/Pyramid/config.ini \
/var/backups/pyramid/config.ini.backup_$(date +%Y%m%d_%H%M%S)

Step 9: Back Up the Database. -- replace 'your_password' and 'yourdatabase' with your details.

PostgreSQL 18’s pg_dump can dump from a 9.6 server, so no 9.6 binaries are needed.

Do not use sudo — it creates a root-owned file that breaks Step 12.

Ubuntu / Debian

BACKUP=/var/backups/pyramid/pyramid_backup_$(date +%Y%m%d_%H%M%S).backup
PGPASSWORD='<YOUR_PASSWORD>' /usr/lib/postgresql/18/bin/pg_dump \
-h 127.0.0.1 -p 12130 -U pyramid \
-Fc -b -v -f "$BACKUP" <YOUR_DATABASE>
ls -lh "$BACKUP"

RHEL / Oracle Linux / Amazon Linux

BACKUP=/var/backups/pyramid/pyramid_backup_$(date +%Y%m%d_%H%M%S).backup
PGPASSWORD='<YOUR_PASSWORD>' /usr/pgsql-18/bin/pg_dump \
-h 127.0.0.1 -p 12130 -U pyramid \
-Fc -b -v -f "$BACKUP" <YOUR_DATABASE>
ls -lh "$BACKUP"

-Fc custom format (required for pg_restore), -b include blobs, -v verbose, -f output file. The database name goes at the end with no flag — that’s normal for pg_dump.

Verify before continuing. ls -lh must show a real size owned by your user. If it’s 0 bytes or missing, the dump failed — do not go to Step 10.

In a new shell, recover the variable with:

BACKUP=$(ls -t /var/backups/pyramid/*.backup | head -1)

Step 10: Disable pyramidPG

sudo systemctl disable --now pyramidPG.service
systemctl is-enabled pyramidPG.service

Should print disabled.

Step 11: Create the pyramid Role in PostgreSQL 18

sudo -u postgres psql -c "CREATE USER pyramid WITH PASSWORD '<YOUR_PASSWORD>';"
sudo -u postgres psql -c "ALTER USER pyramid WITH SUPERUSER CREATEDB LOGIN;"

If the role already exists, use ALTER USER pyramid WITH PASSWORD '<YOUR_PASSWORD>'; instead of CREATE.

Step 12: Restore into PostgreSQL 18

Create the database — the name must match the original exactly:

sudo -u postgres psql -c 'CREATE DATABASE "<YOUR_DATABASE>" OWNER pyramid;'

Restore as pyramid over TCP, not as the postgres OS user. The postgres user can’t read into your 700 backup directory; connecting over TCP means the file is read with your permissions.

Ubuntu / Debian

PGPASSWORD='<YOUR_PASSWORD>' /usr/lib/postgresql/18/bin/pg_restore \
-h 127.0.0.1 -p 5432 -U pyramid \
-d <YOUR_DATABASE> --exit-on-error -v "$BACKUP"

RHEL / Oracle Linux / Amazon Linux

PGPASSWORD='<YOUR_PASSWORD>' /usr/pgsql-18/bin/pg_restore \
-h 127.0.0.1 -p 5432 -U pyramid \
-d <YOUR_DATABASE> --exit-on-error -v "$BACKUP"

--exit-on-error matters — without it pg_restore exits successfully even when every object failed.

To start over:

sudo -u postgres psql -c 'DROP DATABASE "<YOUR_DATABASE>";'
sudo -u postgres psql -c 'CREATE DATABASE "<YOUR_DATABASE>" OWNER pyramid;'

Step 13: Verify the Restore

Table count must be greater than zero:

sudo -u postgres psql -d <YOUR_DATABASE> -t -A \
-c "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='public';"

Size should be comparable to the original:

sudo -u postgres psql -t -A \
-c "SELECT pg_size_pretty(pg_database_size('<YOUR_DATABASE>'));"

This is how Pyramid itself will connect:

PGPASSWORD='<YOUR_PASSWORD>' psql -h 127.0.0.1 -p 5432 \
-U pyramid -d <YOUR_DATABASE> -c "\dt" | head

config.ini is still untouched at this point, so Pyramid can be brought back on the old database if anything’s wrong.

Step 14: Update config.ini

Change only the port:

sudo sed -i 's/^port=12130$/port=5432/' /opt/Pyramid/config.ini
sudo grep '^port=' /opt/Pyramid/config.ini

Leave everything else alone, including the encrypted password= field.

Step 15: Start the Pyramid Services

pyramidPG stays disabled.

for u in $(systemctl list-unit-files --type=service --no-legend \
| awk '{print $1}' | grep -i pyramid | grep -vi pyramidPG); do
echo "Starting $u"
sudo systemctl start "$u"
sleep 3
done
systemctl list-units --type=service --all | grep -i pyramid

Wait 60–90 seconds. Investigate anything that failed:

journalctl -u <unit-name> -n 50 --no-pager

Step 16: Update the Data Source in Admin Hub

1. Admin → Data → Data Source
2. Select Local PG
3. Change Port from 12130 to 5432
4. Test — wait for the green check
5. Apply

Step 17: Other Servers in the Cluster

On each remaining Pyramid server, stop the services, change the port, start them again:

for u in $(systemctl list-unit-files --type=service --no-legend \
| awk '{print $1}' | grep -i pyramid | grep -vi pyramidPG); do
sudo systemctl stop "$u"
done
sudo sed -i 's/^port=12130$/port=5432/' /opt/Pyramid/config.ini
sudo grep -E '^(port|dbhost)=' /opt/Pyramid/config.ini
for u in $(systemctl list-unit-files --type=service --no-legend \
| awk '{print $1}' | grep -i pyramid | grep -vi pyramidPG); do
sudo systemctl start "$u"
sleep 3
done

Check that dbhost= points at the server running PostgreSQL 18 — not localhost.

Step 18: Verify

Log into Pyramid and confirm that it is working as it should.

Step 19: Upgrade Pyramid

Checklist

• PostgreSQL 18 installed (RHEL / Oracle / Amazon: initdb run)
• listen_addresses uncommented and set (multi-server)
• max_connections = 300
• pg_hba.conf configured, local all all peer kept
• PG18 restarted, settings confirmed with SHOW
• Firewall / Security Group allows 5432
• Backup directory owned by your user, not root
• Database name and password verified against port 12130
• config.ini backed up
• All Pyramid services stopped except pyramidPG
• systemctl is-active pyramidPG.service printed active before the backup
• pg_dump run without sudo, file has a real size
• pyramidPG disabled after the backup
• Restore run over TCP with --exit-on-error
• Table count greater than zero
• pyramid connects over TCP on 5432
• config.ini port updated on every server
• Admin Hub → Local PG on 5432, Test passes
• 24 hours clean before upgrading Pyramid

Leave pyramidPG disabled — it costs nothing and keeps rollback available.

Required Timeline

1. Complete this migration. -- Taking the initial backup of the Pyramid repository database is critical. 
2. Verify everything is working properly. 
3. Proceed with the Pyramid 2025.11 or later upgrade.

Overview

This guide walks you through migrating your Pyramid Postgres server from PostgreSQL 9.6 to PostgreSQL 18. You can follow the manual process step-by-step or use the provided PowerShell script for automation(see the end of this article).

Prerequisites

• Administrative access to your Pyramid server(s).
• PostgreSQL 18 installer (download from postgresql.org).
• A database backup location with at least 2x the current database size in free disk space.
• All Pyramid services will be offline during this process.
• Note your Pyramid installation directory (default: C:\Program Files\Pyramid, but it may differ).
• PostgreSQL 18 must be installed before running this migration.

Manual Migration Process

Step 1: Install PostgreSQL 18

1. Download PostgreSQL 18 from postgresql.org.
2. Run the installer.
3. Accept the default settings:
   • Installation directory: C:\Program Files\PostgreSQL\18
   • Port: 5432
   • Username: postgres
   • Password: Set a secure password for the postgres superuser.
4. Skip Stack Builder at the end of the installation.
5. Complete the installation.

Step 2: Configure PostgreSQL 18 Host-Based Authentication

After installing PostgreSQL 18, you must configure which servers can connect to it. This is controlled by the pg_hba.conf file.

1. Open the following file with a text editor such as Notepad:
   C:\Program Files\PostgreSQL\18\data\pg_hba.conf
2. Find the sections labeled IPv4 local connections and IPv6 local connections.
3. Edit the below lines to allow your Pyramid servers to connect.

Below are two example configurations. Choose the configuration appropriate for your security requirements and work with your IT team to determine what is appropriate for your environment.

Example 1: Allow All Servers

Simplest configuration, but least secure:

# IPv4 local connections:
host    all    all    127.0.0.1/32    scram-sha-256
host    all    all    0.0.0.0/0       scram-sha-256

# IPv6 local connections:
host    all    all    ::1/0           scram-sha-256
host    all    all    ::/0            scram-sha-256

Example 2: Allow a Specific Subnet

More restrictive and secure:  --- change the ip's (ipv4 and v6) to your subnet ip's

# IPv4 local connections:
host    all    all    127.0.0.1/32      scram-sha-256
host    all    all    192.168.1.0/24    scram-sha-256

# IPv6 local connections:
host    all    all    ::1/0             scram-sha-256
host    all    all    fe80::/10         scram-sha-256

4. Save the file.

5. Increase max_connections. The default of 100 is too low for Pyramid's service pools. Open C:\Program Files\PostgreSQL\18\data\postgresql.conf in a text editor, find the CONNECTIONS AND AUTHENTICATION section, and set:

   max_connections = 1000

6. Restart the PostgreSQL 18 service:
   • Open services.msc.
   • Locate the PostgreSQL 18 service. The name may be PostgreSQL18, postgres-x64-18, or similar.
   • Right-click the service and select Restart.
   • Wait approximately 10–15 seconds for it to restart fully.

Verification

If you have secondary servers, test the connection from one of them:

psql -h [PostgreSQL18_IP] -U postgres -d postgres -p 5432

When prompted, enter the postgres superuser password. If the connection succeeds, authentication is configured correctly.

Step 3: Locate Your Pyramid Installation Directory

Your Pyramid installation may be in a non-default location. To locate it:

1. Open services.msc.
2. Right-click any Pyramid service and select Properties.
3. On the General tab, note the path shown for the service executable.

Common locations include:

• C:\Program Files\Pyramid
• C:\Pyramid
• D:\Applications\Pyramid

Remember this path—you will need it throughout this guide.

Step 4: Retrieve Database Credentials from config.ini

Extract your database connection details so that you can connect to the existing PostgreSQL 9.6 instance.

1. Navigate to your Pyramid installation directory.
2. Open config.ini with a text editor.
3. Find the [data] section.
4. Locate the relevant database values.

For example:

[data]
password=
type=postgres
port=12130
username=pyramid
database=pyramidb3e0d8e8
dbhost=EC2AMAZ-2TTQ7TS
dblocation=0
dbssl=0

Extract the following values:

• Username: pyramid
• Database Name: the value from database=
• Port: the value from port=
• Server/Host: the value from dbhost=

Construct the Password

The password stored in config.ini is encrypted, but the actual password Pyramid uses is constructed from the database name. 

• Take the database name and extract everything after the word pyramid.
• Password format: pyramid![everything_after_pyramid]

Example:

• Database name: pyramidb3e0d8e8
• Everything after pyramid: b3e0d8e8
• Password: pyramid!b3e0d8e8

Verify the PostgreSQL 9.6 Connection

1. Open pgAdmin 4.
2. Create a new server connection:
   • Right-click Servers → Create → Server.
   • Name: Pyramid_9.6_Backup
   • Open the Connection tab.
   • Host name/address: the value from dbhost=
   • Port: the value from port=
   • Username: pyramid
   • Password: the password constructed above.
   • Save password: Yes
3. Click Save.
4. Expand the connection and verify that you can see your databases.

This confirms that your credentials are correct before proceeding with the backup.

Step 5: Verify PostgreSQL 18 is Installed

1. Verify that C:\Program Files\PostgreSQL\18\bin exists.
2. Open services.msc.
3. Verify that the PostgreSQL 18 service exists.
4. Verify that you completed Step 2 and configured pg_hba.conf.

Step 6: Check Available Disk Space

1. Right-click the backup destination drive and select Properties.
2. Verify that free space is at least 2x the current database size.

To estimate the database size in pgAdmin 4:

• Right-click the Pyramid database.
• Select Properties → Statistics.
• Note the Size value.

Step 7: Stop Pyramid Services

1. Open services.msc.
2. Stop every service starting with Pyramid, except PyramidPostgreSQL.
3. Confirm that PyramidPostgreSQL is still Running.
4. Verify that all other Pyramid services are stopped before proceeding.

Step 8: Back Up config.ini

1. Navigate to your Pyramid installation directory.
2. Copy config.ini to a safe location.
3. Name the copy something such as config.ini.backup_[date].
4. Keep this file so that the original configuration can be restored if necessary.

Step 9: Create the Pyramid User in PostgreSQL 18

1. Open pgAdmin 4 installed with PostgreSQL 18.
2. Connect using the postgres superuser credentials.
3. Right-click Login/Group Roles → Create → Login/Group Role.
4. Configure the role:
   • Name: pyramid
   • Password: Use the password constructed in Step 4.
   • Under Definition, ensure Can login? is enabled.
   • Under Privileges, enable Can create databases? and Superuser?.
5. Save and close.

Step 10: Back Up the Current PostgreSQL 9.6 Database

1. Open pgAdmin 4 and connect to the existing PostgreSQL 9.6 instance.
2. Expand Databases and locate the Pyramid database identified in Step 4.
3. Right-click the database and select Backup.
4. Configure the backup:
   • Format: Custom or TAR
   • Filename: pyramid_backup_[date].backup
   • Compression: Medium
   • Path: A backup location with sufficient free space
5. Click Backup.
6. Wait for completion and monitor the Messages tab.

Verify the Backup

• Confirm that the .backup file was created.
• Confirm that its file size is reasonable compared with the source database size.

Step 11: Disable the Old PostgreSQL Service

1. Open services.msc.
2. Locate PyramidPostgreSQL. On some installations it may appear as PostgreSQL96 or postgresql-x64-9.6.
3. Right-click → Properties and set Startup type to Disabled.
4. Click Stop.
5. Confirm that the service is stopped and its startup type is Disabled.

Step 12: Restore the Database to PostgreSQL 18

1. Open pgAdmin 4 and connect to PostgreSQL 18.
2. Create a new database:
   • Right-click Databases → Create → Database.
   • Name: Use the exact database name identified in Step 4.
   • Owner: pyramid
   • Click Save.
3. Right-click the new database and select Restore.
4. Select the backup file created in Step 10.
5. Click Restore and monitor for errors.
6. Verify that the restore completes successfully.

Verify the Restore

• Right-click the restored database and select Properties → Statistics.
• Verify that its size is similar to the original database.
• Expand the database and verify that the expected tables exist.

Step 13: Update Pyramid Configuration on the Primary Server

1. Navigate to your Pyramid installation directory.
2. Open config.ini.
3. Locate the [data] section.
4. Change only the port:

   port=5432

5. Save the file.

Step 14: Update Additional Servers

If you have multiple Pyramid servers in your deployment:

1. On each additional Pyramid server:
   • Connect to the server.
   • Locate its Pyramid installation directory.
   • Back up config.ini.
   • Open config.ini.
   • Locate the [data] section.
   • Change only the port to 5432.
   • Do not change the username, password, database name, or dbhost.
   • Save the file.
2. Stop all Pyramid services on each secondary server, except PyramidPostgreSQL.
3. Restart the required Pyramid services on each secondary server.

Step 15: Restart Services on the Primary Server

1. Open services.msc.
2. Start all Pyramid services except PyramidPostgreSQL.
   • Right-click each service and select Start.
   • Wait approximately 3–5 seconds between each service start.
3. Wait approximately 60–90 seconds for all services to fully initialize.

Step 16: Update the Data Source Connection in Pyramid Admin Hub

1. Access Pyramid Admin Hub. Allow 1–2 minutes for services to fully start.
2. Navigate to Admin → Data → Data Source.
3. Locate and select Local PG.
4. In the Connection section, change the port from 12130 to 5432.
5. Click Test to verify connectivity.
6. If the test succeeds, click Apply.
7. Restart the remaining Pyramid services if prompted.

Step 18: Upgrade to Pyramid 2025.11 or Later

The PostgreSQL 9.6 to PostgreSQL 18 database migration is a prerequisite for upgrading to Pyramid 2025.11 or later.

Automate the process

Instead of doing all the above steps manually, you can use the attached Power shell script "Migrate-PyramidPostgres.ps1.zip" . To use the Power shell script attached to this article, first follow all steps 1-2.

Then download the attached Power shell script , unzip it and run as Administrator and it will do all the manually steps for you excluding steps 1-2.

For clusters with internet access, the RTE and TE deployments pull these Satellite images automatically without requiring any changes to your YAML files or Helm charts.

If your cluster's internet access is blocked, you must manually pull these images to your internal registry.
The images can be found in this registry:
https://hub.docker.com/r/pyramidanalytics/satellite/tags

To allow the pods to successfully pull the Satellite images from your internal registry, you will need to apply the following configuration steps based on your deployment method.

Option 1: Using YAML

In the runtime-service and task-service deployment files, locate the env block and append the PYRAMID_DOCKER_REGISTRY variable:

YAML

env:
  - name: PYRAMID_DOCKER_REGISTRY
    value: "<your.registry.address>"

(Note: Replace <your.registry.address> with the actual URL of your internal registry).

Option 2: Using Helm

If you are managing your deployments via Helm, ensure your registry is defined in your values.yaml file (e.g., as repo).

Then, update the rte_deployment and te_deployment templates by adding the following to the env block:

YAML

env:
  - name: PYRAMID_DOCKER_REGISTRY
    value: "{{ .Values.repo }}"

Follow the steps below to complete this task.

Please note that the steps are written to be used with Red Hat 9 and may differ for other Linux versions.

1. Run the following on a server that can connect to the internet:

   sudo subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms
   sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm -y

2. Download the rpm to print-packages folder

   sudo dnf install --downloadonly --downloaddir print-packages pango.x86_64 libXcomposite.x86_64 libXcursor.x86_64 libXdamage.x86_64 libXext.x86_64 libXi.x86_64 libXtst.x86_64 cups-libs.x86_64 libXScrnSaver.x86_64 libXrandr.x86_64 GConf2.x86_64 alsa-lib.x86_64 atk.x86_64 gtk3.x86_64 xorg-x11-fonts-100dpi xorg-x11-fonts-75dpi xorg-x11-utils xorg-x11-fonts-cyrillic xorg-x11-fonts-Type1 xorg-x11-fonts-misc libnss3.so libgbm libxshmfence google-noto-sans-cjk-ttc-fonts 

3. Copy all rpm from online machine to the offline
    

4. Install all the rpm's inside that folder

   sudo rpm -ivh print-packages/*.rpm

5. 5. Make printerpyramid and chrome executable in core file

   chmod +x /opt/Pyramid/core/prt/puppet/chromium/chrome
   chmod +x /opt/Pyramid/core/prt/puppet/pyramidPrinter

    

6. Check if the printer works

   /opt/Pyramid/core/prt/puppet/pyramidPrinter --port=10012 --proxy="{\"enableProxyServer\":false,\"useCredentials\":false,\"bypassProxyServerLocal\":false,\"proxyServer\":{\"address\":\"\",\"port\":0},\"loginUser\":{\"inheritanceType\":\"LoginUser\",\"name\":\"\",\"password\":\"\"}}" --localProxyPort=15000 --tabs=4 --uuid=aacb720a-7e4e-4989-bf76-6e81c2964a17

    

Running Pyramid from a path is sometimes required (e.g., https://mysite.com/pyramid) instead of the root (e.g. https://mysite.com). In embedding scenarios, this allows Pyramid to run under the same web domain instead of a subdomain - facilitating easier integrations and simplified authentication/security operations.

Prerequisites

• This applies only to Pyramid 2023.16.083 / 2024.01.013 and later.
• Earlier versions do not support this feature.

1. Configuring Pyramid to Use a Virtual Directory

1. Log in to Pyramid Admin.
2. Navigate to:
   Services → Web Services → Web Settings.
3. Enable "Deploy via Virtual Directory".
4. Set your desired virtual directory/path name, e.g., /pyramid.
5. Click Apply and restart all Pyramid web servers.

   

    Now, users can access Pyramid at:

http://localhost:8181/pyramid

Important Notes:

Pyramid may still be accessible at the root (/) by default. This is because Pyramid assumes that a load balancer or reverse proxy will manage access to /pyramid. If you only want users to access Pyramid at /pyramid, configure your load balancer accordingly and block access.

The next sections explain how to facilitate the virtual path for Pyramid using various load balancing / reverse proxy technologies.

2. Configuring AWS Load Balancer to Serve Pyramid Under /pyramid

(Assumes you already have an AWS Load Balancer set up. If not, see this guide for setup instructions.)

Steps:

1. Go to AWS Console → EC2 → Load Balancers.
2. Select the Load Balancer that will serve Pyramid.
3. Click "Add Rule".

Rule Configuration:

• Name: pyramid
• Condition Type: Path
• Path: /pyramid* ( use the path you setup for the virtual directory in the Pyramid admin)
• Action: Forward to target group
• Target Group: Choose the group that points to your Pyramid web servers (port 8181).

Setting Rule Priority

• The rule must have a lower number (higher priority) than any rule that routes traffic to /.
• Example: If there is a rule for / that sends traffic to another website, your /pyramid rule should have a lower number than that rule.
• This ensures /pyramid traffic is forwarded correctly and doesn't get overridden.

Example Rule Evaluation Order:

Now, users browsing to /pyramid will be forwarded to Pyramid before the root rule is applied.

3. Configuring IIS to Serve Pyramid Under to Serve Pyramid Under /pyramid

Step 1: Open IIS Manager

1. Open IIS Manager (inetmgr from the Run dialog).
2. In the Connections panel, click on your site (e.g., Default Web Site).

Step 2: Configure URL Rewrite Rules

1. Double-click "URL Rewrite" in the middle panel.
2. Click "Add Rules…" in the right panel.
3. Select "Blank Rule" under Inbound Rules and click OK.

Step 2.1: Create Rewrite Rule for /pyramid

1. Enter "Rewrite Pyramid Path" as the rule name.
2. Under Conditions, click "Match URL":
   • Set Requested URL to Matches the Pattern
   • Use the Regular Expressions option.
   • In the Pattern field, enter:

     ^pyramid(/.*)?$

3. Scroll to Action and set:
   • Action Type: Rewrite
   • Rewrite URL:

     http://localhost:8181/pyramid{R:1}

   • Append Query String: Yes
   • Stop Processing of Subsequent Rules: Yes
4. Click Apply in the right panel.

Step 3: Restart IIS and Test

1. Click Restart on the right panel under Manage Server.
2. Open a browser and visit:

   http://yourserver/pyramid

   It should correctly forward to http://localhost:8181/pyramid.
   
   Access the main site at:

   http://yourserver/

   Any request that is not for /pyramid will automatically be handled by the main site, so no additional rules are needed

Now, Pyramid should be accessible at /pyramid via IIS. 

When browsing to the main site i.e mysite.com you will get the site

3. Configuring Nginx to Serve Pyramid Under /pyramid

This process is identical to the one described here; however, in step 3, use the below configuration instead

server {
  listen 443 ssl;
    ssl_certificate /etc/nginx/certs/chain.pem;
    ssl_certificate_key /etc/nginx/certs/privkey.pem;
    server_name yourServername.mycompany.com;
    access_log /var/log/nginx/nginx.vhost.access.log;
    error_log /var/log/nginx/nginx.vhost.error.log;
    client_max_body_size 300M;
    location / {
proxy_pass http://localhost:8181/pyramid;
    }
location /events {
proxy_pass http://localhost:8181/pyramid/events;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }
}

AWS ALB (and possibly other load balancers/reverse proxies) terminate SSL at the load balancer level and communicate with backend servers (Pyramid) over HTTP. The "X-Forwarded-Proto" header ensures that Pyramid correctly identifies requests as HTTPS and responds accordingly. For most reverse proxies / load balancers this setting is NOT needed as they know how to handle the SSL termination correctly. 

Prerequisites

• This guide applies only to Pyramid 2023.16.083 / 2024.01.013 and later .
• Earlier versions do not support the "X-Forwarded-Proto" header.

1. Enabling "X-Forwarded-Proto" in Pyramid

Pyramid must be configured to recognize HTTPS requests forwarded by the AWS Application Load Balancer (ALB). This is done using the "X-Forwarded-Proto" header.

Steps:

1. Log in to Pyramid Admin.
2. Navigate to:
   Services → Web Services → Web Settings.
3. Check the box for "Proxy SSL Handling (X-Forwarded-Proto)".
4. Click Apply.
5. Restart all Pyramid web servers for the change to take effect.

   

2. Configuring an AWS Application Load Balancer (ALB)

Note: AWS configurations may change over time. Always refer to the latest AWS documentation for updates.

Step 1: Create an Application Load Balancer

1. Open the AWS Console.
2. Go to EC2 → Load Balancers.
3. Click "Create Load Balancer" and select Application Load Balancer.

Basic Configuration:

Network Mapping:

Security Groups:

• Select or create a security group that allows inbound HTTPS (443) traffic.

Step 2: Configure Listeners & Routing

Step 3: Create a Target Group

1. Click "Create Target Group".
2. Select "Instances" as the Target Type.
3. Configure the settings:

Health Check Configuration:

4. Click Next and register targets:
   • Select the EC2 instances running Pyramid.
   • Ensure the port is set to 8181.
   • Click "Include as pending below", then "Create Target Group".

Step 4: Assign the Target Group to the Load Balancer

1. Return to the "Listeners & Routing" section of the ALB setup.
2. Under Default Action, select "Forward to Target Group".
3. Choose the Pyramid target group created earlier.

Step 5: Configure SSL/TLS Certificate

1. Under Secure Listener Settings, select "Default SSL/TLS Certificate".
2. Upload or select an existing SSL certificate.
3. (Optional) Configure additional security settings based on your company's policies.

3. Final Configuration & Testing

Modify ALB Listener Rules (Optional)

If needed, edit the listener rules:

1. Go to EC2 → Load Balancers.
2. Select the ALB and navigate to Listeners → HTTPS:443 → Edit Default Rule.
3. Ensure the action is "Forward to Target Groups" and the correct Pyramid target group is selected.

1. Increase ALB Idle Timeout

Steps:

1. Go to EC2 Dashboard → Load Balancers.
2. Select your Application Load Balancer (ALB).
3. Go to the Attributes tab.
4. Click Edit.
5. Set Idle Timeout to 600 seconds.
6. Click Save.

2. Adjust Target Group Health Check Settings

Increase timeout & interval to prevent premature failures.

Steps:

1. Go to EC2 Dashboard → Target Groups.
2. Select your Target Group.
3. Go to the Health Checks tab → Click Edit.
4. Apply the recommended values above.
5. Click Save.

Update Security & DNS Settings

• Security Group: Ensure inbound port 443 is open to allow user connections.
• DNS Configuration: Update external DNS records to point to the ALB DNS name.

4. Summary

✅ Pyramid is now configured to recognize HTTPS requests using "X-Forwarded-Proto".

✅ The AWS Load Balancer terminates SSL and forwards requests to Pyramid over HTTP.

✅ Users can securely access Pyramid at https://your-domain.com via the ALB.

For further assistance, refer to the AWS Load Balancer Documentation or contact AWS Support.

 Various operating systems and technologies are out of support or nearing end of life (EOL). In tandem, Pyramid will start to drop official support for them.

Operating Systems 

• Windows 2012 reached end of life in October 10, 2023. Consequently, the final version of Pyramid that will support Windows 2012 will be Pyramid 2023.12 (not yet released). Customers should already be making plans to migrate off this Windows version. 
• Red Hat Enterprise Linux 7 and CentOS 7 are set to be out of support in June 2024. While we plan to support them beyond their EOL date, customers should start planning to migrate off them. 
• Ubuntu 16 and 18 are both out of standard support. While we plan to support them beyond their support dates until their official EOL dates, customers should start planning to migrate off them. 

We anticipate adding support for newer operating systems in the next few releases, this includes Red Hat Enterprise Linux 9, Oracle Linux 9, Ubuntu 24 and Amazon 2023.

Repository Databases

The discontinued support for these database engines relates to them as a repository, NOT as analytical data sources. 

MS SQL Server

• SQL 2012 reached end of life in Jul 12th 2022. Consequently, the final version of Pyramid that will support SQL 2012 will be Pyramid 2023.12 . Customers should already be making plans to migrate off this SQL version.
• SQL 2014 will reach end of life later this year. While we plan to support it beyond its EOL date, customers should start planning to migrate off it as well. 

PostgreSQL

• Postgres SQL 11 reached end of life in November 9th 2023. Consequently, the final version of Pyramid that will support Postgres SQL will be Pyramid 2023.12. Customers should already be making plans to migrate off this Postgres SQL version.
• Postgres SQL 12 will reach end of life later this year. While we plan to support it beyond its EOL date, customers should start planning to migrate off it as well. 

Oracle Database

• Oracle 10c reached end of life in June 30th 2021. Consequently, the final version of Pyramid that will support Oracle 10c database will be Pyramid 2023.12. Customers should already be making plans to migrate off this Oracle version.

Before upgrading the cluster, take a full backup of the Pyramid repository.

Please navigate on the customer's portal to the Pyramid Kubernetes Cluster configurator page.

Select a version and configure the number of pods for each Pyramid service.
Ensure that you maintain the previous Port and Persistent storage settings during the upgrade.

After proceeding to the next page, you can skip steps 1 and 2 as there is no need to repeat them. However, make sure to obtain the YAML file in step 3.

Before deploying the YAML, ensure the cluster hosts have enough resources (CPU and RAM).

To deploy the YAML file, just run the command below(step 4):

kubectl apply -f pyramid-analytics-config.yaml

Please note that the Kubernetes engine will initiate all the new pods before terminating the old ones.
This process may consume more resources until Kubernetes has terminated the old pods. However, it minimizes the amount of downtime taken during the upgrade process.

If you choose to use Helm instead of YAML, you can perform an upgrade by executing the following command.
However, Please make sure to update the version number to the latest or the one that you want to install. This version must be newer than the one currently installed. You can find the version number in the drop-down list on the Pyramid Kubernetes Cluster configurator page.

helm install pyramid pyramid/pyramidanalytics --version 2023.00.361

Following these recommendations can help prevent common installation issues and ensure that your environment meets the requirements of the Pyramid version being installed.

1. Check System Requirements

Before installing or upgrading Pyramid, confirm that the server meets the supported operating system, hardware, software, and database requirements.

Always refer to the latest Pyramid System Requirements before proceeding.

Important for Pyramid 2025.11 and later:

• Operating systems: Ubuntu 20, Debian 11, and Amazon Linux 2 are no longer supported.
• PostgreSQL: PostgreSQL 12 and earlier are no longer supported as Pyramid repository databases.
• Windows: Ensure that the required .NET Framework 4.7.2 and .NET 10 components are installed.
• Linux: Ensure that the operating system is fully updated and that the required software repositories and dependencies are accessible.

Note: Minimum hardware requirements vary depending on the deployment type, number of users, and expected workload. Kubernetes deployments have different requirements from native installations.

2. Check Antivirus and Endpoint Security

Antivirus and endpoint security software can sometimes interfere with the Pyramid installation process by blocking executables, extracting files, or preventing services from being created or started.

Before installing Pyramid, check whether your security software requires exclusions for:

• The Pyramid installer executable.
• The Pyramid installation directory.
• The Pyramid data and repository directories.
• Relevant Pyramid service processes.

If the installation fails and antivirus interference is suspected, review the antivirus logs and temporarily apply approved exclusions where necessary.

Important: Completely disabling antivirus protection is not normally recommended. Any temporary security changes should be approved by your IT or security team and reverted after troubleshooting.

3. Check Firewall and Network Ports

Pyramid uses multiple services that communicate with each other across the network.

If a firewall is enabled, ensure that the required ports are open between the relevant Pyramid servers and components.

This is particularly important for distributed and multi-server installations.

Check that:

• The required Pyramid service ports are available.
• Servers can communicate with each other.
• The Pyramid application can connect to its repository database.
• Users can access the required web application ports.
• Firewalls, security groups, and network access controls allow the required traffic.

For the required ports, refer to: Firewall Settings for Pyramid .

4. Check Repository Database Requirements

Pyramid requires a repository database to store application configuration, metadata, and other repository information.

Supported repository database technologies include:

• Microsoft SQL Server
• PostgreSQL
• Oracle Database

Before installing Pyramid, verify that the selected database version is supported and that the appropriate connection details and permissions are available.

When the installer is expected to create a database, the database account must have sufficient privileges to perform the required operations.

For existing databases or managed database services such as AWS RDS, the database may need to be created in advance by the database administrator.

In these cases, select the appropriate existing repository or managed database option in the installer.

Important PostgreSQL Changes in Pyramid 2025.11

Pyramid 2025.11 and later no longer support PostgreSQL 12 or earlier as repository databases.

Customers using an older PostgreSQL repository must migrate to a supported version before upgrading Pyramid.

This includes customers who originally installed Pyramid using the older bundled PostgreSQL 9.6 database.

For these installations, PostgreSQL must be migrated to a supported, separately managed PostgreSQL instance before upgrading Pyramid.

The migration guides below use PostgreSQL 18:

• Migrating PostgreSQL 9.6 to PostgreSQL 18 - Windows
• Migrating PostgreSQL 9.6 to PostgreSQL 18 - Linux

Important: Complete the PostgreSQL migration and verify that the existing Pyramid installation is working correctly before proceeding with the Pyramid 2025.11 or later upgrade.

If you are using an externally managed PostgreSQL server that already meets the supported requirements, the bundled PostgreSQL migration procedure does not apply.

5. Check Installation Permissions and Dependencies

Ensure that the account running the Pyramid installer has sufficient permissions to install the application, create directories, configure services, and perform the required system changes.

• Windows: Run the installer as Administrator.
• Linux: Run the installer with the appropriate administrative permissions, typically using sudo.

On Windows, install the required .NET components before starting the installation to help avoid unnecessary installation interruptions or reboots.

On Linux, ensure that the operating system is fully updated and that the required package repositories are accessible.

Linux installations may require internet access or access to properly configured offline repositories to install the necessary dependencies.

6. Backup Before Upgrading

If you are upgrading an existing Pyramid installation, always take a backup before starting the upgrade.

At a minimum, ensure that you have:

• A valid backup of the Pyramid repository database.
• Backups of relevant IMDB data files.
• Backups of uploaded files and generated content, where applicable.
• Copies of any important configuration files.

Where possible, verify that backups can be restored before proceeding with a production upgrade.

For repository backup instructions, see: How to Backup and Restore a PostgreSQL Database .

7. Troubleshooting Installation Failures

If the Pyramid installation fails, review the error message and installer logs before attempting to reinstall the software.

Common causes of installation failures include:

• Unsupported operating system or database versions.
• Missing software dependencies.
• Insufficient installation permissions.
• Antivirus or endpoint security interference.
• Blocked or unavailable network ports.
• Insufficient database permissions or incorrect connection settings.
• Configuration or service files remaining from an incomplete installation.

If the installation fails:

1. Review the error message displayed by the installer.
2. Check the installer logs for the underlying error.
3. Verify that the system requirements and prerequisites are met.
4. Correct any identified issues and retry the installation.
5. If a complete uninstall and reinstall is required, refer to How to Fully Uninstall Pyramid .

Important: Do not perform a complete uninstall or remove Pyramid repository data without first confirming that all required backups have been taken.

8. Collecting Installer Logs

If you are unable to resolve the installation issue, collect the installer logs before opening a support ticket.

On Windows, installer logs are generally written to the temporary directory of the account running the installation.

To access this directory, press Windows + R and enter:

%TEMP%

On Linux, installer logs may be located in:

/tmp

Depending on the Pyramid version and installer, look for log files with names such as:

• installerbuilder_install.log
• pyramidinstaller.log

File names may differ between installer versions. If multiple installation attempts have been made, sort the logs by modification time to identify the files associated with the relevant attempt.

9. Contacting Pyramid Support

If the issue persists, please open a Pyramid Support ticket .

Include the following information:

• The Pyramid version and build number being installed or upgraded.
• The operating system and version.
• The repository database type and version.
• The installation type (single-server, multi-server, or other).
• The installer logs from the failed installation.
• The exact error messages received.
• A description of the issue and when it occurred.
• Steps already taken to troubleshoot the issue.

Providing this information will help Pyramid Support investigate the issue more efficiently.

For further installation information, refer to the Pyramid Installation and System Requirements documentation .

One possible error is:

Error reading INI File /home/admin/Pyramid/config.ini

This can occur when configuration files or service registrations from a previous installation remain on the Linux server.

The installation path shown in the error message is an example. The actual path will depend on the directory used during installation.

Example of the installer error. The screenshot is illustrative; the displayed installer version is not a verified build number.

1. Check for Remaining Pyramid Configuration Files

If the installation failed and Pyramid has already been uninstalled, check whether the following configuration file remains:

/etc/pareg.ini

You can check whether the file exists by running:

sudo ls -l /etc/pareg.ini

This file may contain configuration information pointing to a previous Pyramid installation directory.

If it belongs to the failed installation and is no longer required, back it up before removing it.

sudo cp -p /etc/pareg.ini /etc/pareg.ini.bak

Then remove the obsolete file:

sudo rm /etc/pareg.ini

Important: Only remove this file after verifying that it belongs to the installation being cleaned up. Do not remove configuration files belonging to an active Pyramid deployment.

2. Check for Remaining Pyramid Services

Pyramid creates Linux services to manage its application components.

Older Pyramid installations used service scripts under /etc/init.d.

More recent Linux installations can use systemd to manage these services.

Before reinstalling Pyramid, check for obsolete service registrations left behind by the previous installation.

Current Pyramid Service Names

Depending on the Pyramid version, installed components, and deployment configuration, the following services may be present:

• pyramidAgent - Pyramid Agent
• pyramidFs - File System service
• pyramidRTE - Runtime Engine
• pyramidRTR - Router
• pyramidTE - Task Engine
• pyramidWeb - Web Server
• pyramidIMDB - In-Memory Database
• pyramidNLP - Natural Language Processing
• pyramidSOLVE - Solve Engine
• pyramidAI - AI service
• pyramidDNC - .NET Connector, where installed
• pyramidPG - Older bundled PostgreSQL service, where applicable

Note: Not every service will be installed in every environment.

The pyramidPG service is associated with installations using Pyramid's older bundled PostgreSQL repository. Environments using separately installed PostgreSQL will have their own PostgreSQL service, managed independently of Pyramid.

For more information, see: The Pyramid Services in Linux .

3. Check for Older Init.d Service Scripts

On installations using the older Linux service scripts, check the following directory:

/etc/init.d

To list any Pyramid-related service scripts, run:

ls -l /etc/init.d/pyramid*

You may find some of the service names listed above, depending on the version previously installed.

If Pyramid was completely uninstalled and these scripts are confirmed to be remnants of the failed installation, back them up before removing them.

For example, to back up an obsolete Task Engine service script:

sudo cp -p /etc/init.d/pyramidTE /etc/init.d/pyramidTE.bak

Once confirmed to be obsolete, the original script can be removed:

sudo rm /etc/init.d/pyramidTE

Repeat this procedure only for obsolete scripts associated with the failed installation.

Warning: Do not remove the entire /etc/init.d directory or automatically delete every Pyramid service script. Some scripts may still be required by an existing installation.

4. Check for Systemd Services

On Linux systems using systemd, Pyramid services may be registered as systemd units rather than traditional init.d scripts.

To list installed Pyramid service units, run:

systemctl list-unit-files 'pyramid*'

To list currently loaded Pyramid service units, including inactive services, run:

systemctl list-units --all 'pyramid*'

To inspect a particular service, for example the Task Engine, run:

sudo systemctl status pyramidTE

You can also inspect its unit definition:

systemctl cat pyramidTE

If service registrations remain from a failed installation, check whether they reference an installation directory that no longer exists.

Before removing any systemd unit, confirm its location, ownership, and whether it is still required.

If obsolete service registrations need to be removed, follow the appropriate systemd cleanup procedure for the Linux distribution.

After removing obsolete systemd unit files, reload the systemd manager configuration:

sudo systemctl daemon-reload

Important: Do not remove active Pyramid service units or disable services belonging to another working Pyramid installation.

5. Check the Previous Installation Directory

If the installer reports that it cannot read config.ini, verify the installation directory referenced by the error.

For example:

/home/admin/Pyramid/config.ini

Or, for an installation under the commonly used Linux installation directory:

/opt/pyramid/config.ini

Check whether the directory and configuration file exist and whether the installation account has the required permissions.

If the path points to an installation that has already been removed, the remaining registration or configuration may need to be cleaned up.

Warning: Do not delete the entire Pyramid installation or repository data directory without confirming that all required data, configuration, and database backups have been taken.

6. Run the Installation Again

After removing any confirmed obsolete configuration files and service registrations:

1. Verify that the previous Pyramid installation has been completely uninstalled.
2. Confirm that any required repository and data backups have been saved.
3. Ensure that obsolete service registrations no longer reference the previous installation.
4. Verify that the installation directories and permissions are correct.
5. Run the Pyramid installer again using the appropriate permissions.

If the installation fails again, collect the installer logs and review the reported error.

On Linux, installer logs may be located in the temporary directory:

/tmp

Include the installer logs and the exact error message when opening a ticket with Pyramid Support.

For additional installation troubleshooting recommendations, see: Pyramid Installation Tips .

Additional Notes

This article describes troubleshooting steps for installations that failed or were incompletely removed.

Service names and registration methods may differ depending on the Pyramid version, Linux distribution, and deployment configuration.

If the server is part of a distributed Pyramid deployment, verify the affected node and services before making any changes.

Pre-requisites:

• A backup of the Pyramid repository from the version you wish to revert back to.
• The installer of the version you need.

First Steps:

• If it wasn't already done, If you're using an IMDB (In-Memory DB), backup the 'imdata' folder to restore later.
  The default location is: "C:\Program Files\Pyramid\repository\imdata"
• If you're using publications, backup the below folder to have the ability to review and open published publications:
  "C:\Program Files\Pyramid\repository\general"
  This step should be done on each Pyramid server.
• Copy the machine key from config.ini 
  (C:\Program Files\Pyramid\config.ini).
  After the reinstallation copy the old machine key to the new config.ini
  look for:
  [machine]
  installType=1
  host=myPyramidserver.com
  machineKey=0e93adc283152805cceb676d9a38ec1e

Uninstall:

• Remove Pyramid completely from the server(s) through the control panel.
  For more details, please follow up on this article:
  'How to fully uninstall Pyramid'

Re-install:

• Restore the backup of the Pyramid repository.
• Install the previous version of Pyramid
  * Use the option of using an existing DB and point it to the restored DB.
• After the installation is complete, copy the old machine key into the new config.ini
• Remove all the new server entries in the table "server_instances" (In Pyramid repository) (check according to the date they were added)
• Restart Pyramid services and try to log in.
• Restore the contents of the IMDB and General folder to their relative locations.

After upgrading a Pyramid install that uses IIS, the site is no longer accessible, please check that the following is correct:

1)

Open IIS >Double click on the server name(1)>Double Click on "Application Request Routing Cache"(2)
  

Make sure that the box "Enable proxy" is ticked and if not tick it (3)>Click on Apply(4)

2)

Check that the Rewrite URL rule is correct on the Pyramid2018 website. Double click on the Pyramid2018 website >"URL Rewrite">"ReveseProxyInboundRule1"

The Rewrite URL should be "http://localhost:8181/{R:1}" as shown below, if it is not, please update it, click apply and do an IISRESET.

• When uninstalling the Alpha or Beta releases that are using the built-in repository, uninstalling will wipe out the database permanently.
  If you wish to keep the database, please back it up manually before the uninstall.
• During the uninstall of the RTM, you can back up the built-in repository during uninstall.
• Content that was created in the Alpha or Beta releases will not work in the RTM release.
• R is uninstalled on its own. Just confirm it was removed.
• The services and shares removed by the uninstaller as well. Just confirm they were removed.
• The IIS website is removed by the uninstaller. If it was not removed, it can be removed manually. You can manually uninstall IIS if you wish.

If your installer fails, or if you have uninstalled Pyramid but some components were not removed, do the following:

1. Uninstall the application properly from windows.
2. Check that the installation folder is completely removed.
   if not delete it completely.
3. Uninstall the R installation.
4. Optional: Download and run the attached* command script.
   This script will wipe out all services and folder shares and remove the registry entries.
   - Make sure NO "Pyramid ..." services exists.
   - Check that Registry entry was removed.
     If it wasn't, delete it manually. (See attached image)
5. In some cases, a reboot is required.

*Save the attached script to your computer (you will need to unzip the file). Then run it as an administrator. It will stop and delete services and removed folder shares.

Note.
The installer enables to install to IIS and to remote or local existing SQL/Postgres repository.
Currently, with the RTM version, you CANNOT install on top of an existing repository.

When the machine is clean, you can attempt to reinstall if needed.
 

If you require assistance, please open a support request by sending an email to Support@PyramidAnalytics.com