Derek Coleman & Associates Inc logoDerek Coleman & Associates Inc

Home / Support / PostgreSQL on AlmaLinux 9

PostgreSQL on AlmaLinux 9 — Support & Quick Start

PostgreSQL on AlmaLinux 9 — PostgreSQL on AlmaLinux 9: the world's most advanced open-source database on an enterprise-grade RHEL-compatible base. Published by Derek Coleman & Associates Inc on the Azure Marketplace, deployed in your own Azure subscription.

Email support Product page Azure Marketplace listing

Fixed on image version 2026.916.1436 (published 2026-09-16)

The generated superuser password now authenticates over TCP: first boot rewrites the two distro pg_hba.conf lines that mapped 127.0.0.1/32 and ::1/128 to `ident` (which refused every password login) to `md5`, and then proves `psql -h 127.0.0.1 -U postgres` with the password before writing /var/lib/pgsql/.superuser-password. `sudo -u postgres psql` keeps working via peer authentication as before.

If you deployed this VM before 2026-09-16, it came from the older image and is not changed by the new publication — redeploy from the current Marketplace version, or apply the one-time repair below:

  1. On a VM from an earlier image `psql -h 127.0.0.1 -U postgres` answers `FATAL: Ident authentication failed`. `sudo -u postgres psql` works (peer authentication — it is how first boot set the password).
  2. To enable password logins in place, change the two `host all all 127.0.0.1/32 ident` and `::1/128 ident` lines in /var/lib/pgsql/data/pg_hba.conf to `md5` and reload — this is exactly what the fixed image does at first boot. (Not `scram-sha-256`: that image stores passwords as md5, which a `scram-sha-256` rule refuses — see First login for the md5 → SCRAM step.)
sudo -u postgres psql -c 'SELECT pg_reload_conf()'

Image change: see the pull request.

Source: the Marketplace live version set for this offer, read from Partner Center on 2026-09-16. New deployments take the newest version by default.

At a glance

Application ports5432 (PostgreSQL) — opened in firewalld at first boot; the server listens on localhost until you set listen_addresses. TLS is OFF (ssl = off)
Admin credential filesudo cat /var/lib/pgsql/.superuser-password
Sign in aspostgres
Service(s)postgresql
Configuration/var/lib/pgsql/data/postgresql.conf (listen_addresses, password_encryption, ssl = off); /var/lib/pgsql/data/pg_hba.conf
Logs/var/lib/pgsql/data/log/
VersionPostgreSQL (AlmaLinux 9 AppStream package)
PlatformAlmaLinux 9

Quick start

  1. Deploy from the Azure Marketplace (Get It Now → Create), choosing your SSH key at the Administration step.
  2. Allow inbound SSH (22) for yourself plus the application port(s): 5432 (PostgreSQL) — to your application subnets only — restrict to your own IP where possible. The in-image firewall already allows them; only the Network Security Group (NSG) keeps them closed.
  3. Connect locally with `sudo -u postgres psql`, or over TCP as postgres with the generated superuser password (see First login below).
  4. To accept network clients: set listen_addresses, add a `scram-sha-256` pg_hba.conf rule for your subnets (VMs from images before 2026.1004.2112 must re-store their passwords as SCRAM first — see First login), restart PostgreSQL, turn on TLS (it is off), then open 5432 in the NSG to your app tier only.

First login / credentials

This image generates its admin credential on the VM at first boot — nothing is pre-set. SSH into the VM with the username + key you chose at deploy, then print the generated credential:

ssh <your-username>@<VM-IP>
sudo cat /var/lib/pgsql/.superuser-password

Sign in as postgres.

  1. Connect as the superuser with `sudo -u postgres psql` (peer authentication — works on every version of this image).
  2. The generated password in /var/lib/pgsql/.superuser-password is set on the postgres role at first boot and authenticates over TCP too: `psql -h 127.0.0.1 -U postgres`. First boot proves that connection before it writes the file. (On VMs deployed before 2026-09-16 it answers `FATAL: Ident authentication failed` — see the note at the top of this page.)
  3. To accept network clients (images from 2026.1004.2112 print these steps in the login message): `sudo sed -i "s/^#\?listen_addresses = .*/listen_addresses = '*'/" /var/lib/pgsql/data/postgresql.conf`, then `echo "host all all 10.0.0.0/24 scram-sha-256" | sudo tee -a /var/lib/pgsql/data/pg_hba.conf` (use your client subnet), then `sudo systemctl restart postgresql`, and allow 5432 in the Azure NSG from that subnet only — never 0.0.0.0/0 (firewalld on the VM already allows the postgresql service).
  4. ⚠ That `scram-sha-256` rule only accepts passwords stored as SCRAM-SHA-256. Images from 2026.1004.2112 store every password that way. On a VM from an EARLIER image they are stored as md5 and the rule refuses them: first add `password_encryption = 'scram-sha-256'` to /var/lib/pgsql/data/postgresql.conf, `sudo systemctl reload postgresql`, then set each password again (`\password postgres` in `sudo -u postgres psql`, and the same for your application roles).
  5. TLS is OFF on this image (`ssl = off`): until you turn it on (`ssl = on` plus a certificate and key — postgresql.org/docs/13/ssl-tcp.html), queries and results cross the network unencrypted. Turn it on before real traffic. Then create your application role and database, change the postgres password (ALTER USER), and delete the file.

Sign in as postgres — either with `sudo -u postgres psql` (peer authentication) or with the generated password in /var/lib/pgsql/.superuser-password over TCP. Change the password and create a least-privilege application role before you open 5432 to anything. TLS is off on this image: turn it on before clients connect over the network.

Still stuck?

Email support@dcassociatesgroup.com (response within 1 business day) or send a message via the contact form. Include the offer name, VM size, region, and any log output — sudo journalctl -u <service> -n 100 usually tells the story.