From: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10 |
Date: | 2024-11-23 20:24:47 |
Message-ID: | CANzqJaCph4bT6MQEiDCVROiCQf+jqKKWJowEBqKme-qg83Jzfw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, Nov 23, 2024 at 1:10 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
[snip]
> I have to admit, for this question, we just point people to:
>
> https://www.postgresql.org/support/versioning/
>
> and say bounce the database server and install the binaries. What I
> have never considered before, and I should have, is the complexity of
> doing this for many remote servers. Can we improve our guidance for
> these cases?
>
What guidance is needed? Even for us, where firewalls block our servers
from https://download.postgresql.org, it's as simple as downloading the
relevant RPM files *once* (and that done with a PowerShell script), then
patching thusly:
WinScp PG16.4_RHEL8 dir to each server, and on each server
$ sudo -iu postgres pg_ctl stop -mfast -wt9999 -D /path/to/data
$ sudo yum install PG16.4_RHEL8/*rpm
$ sudo -iu postgres pg_ctl start -wt9999 -D /path/to/data
Those three sudo commands take, at most, three minutes.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2024-11-23 21:39:07 | Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10 |
Previous Message | Gianni Ceccarelli | 2024-11-23 19:50:50 | Version upgrades and replication |