Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10
| От | Ron Johnson |
|---|---|
| Тема | Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10 |
| Дата | |
| Msg-id | CANzqJaCph4bT6MQEiDCVROiCQf+jqKKWJowEBqKme-qg83Jzfw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10 (Bruce Momjian <bruce@momjian.us>) |
| Ответы |
Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10
|
| Список | pgsql-general |
On Sat, Nov 23, 2024 at 1:10 PM Bruce Momjian <bruce@momjian.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!
В списке pgsql-general по дате отправления: