Обсуждение: Statistics collector port / unix dom. socket?
Hello, it seems Postgres tries to send a UDP packet to a random high port to communicate with the statistics collector daemon. We have rather strict packet filter rules in place, and I'd like to make the system use a fixed port for this, or even better a Unix domain socket. Is this possible (setting a compile time or run time parameter)? Thanks, peter.
Peter Sabaini <peter.sabaini@ait.ac.at> writes:
> it seems Postgres tries to send a UDP packet to a random high port to
> communicate with the statistics collector daemon. We have rather strict
> packet filter rules in place, and I'd like to make the system use a
> fixed port for this, or even better a Unix domain socket. Is this
> possible (setting a compile time or run time parameter)?
No, the stats collector just uses whatever port bind() chooses for it.
I'd suggest backing off your ideas about how much filtering is
appropriate for local connections.
regards, tom lane
On Tue, 2010-05-04 at 11:39 -0400, Tom Lane wrote: > Peter Sabaini <peter.sabaini@ait.ac.at> writes: > > it seems Postgres tries to send a UDP packet to a random high port to > > communicate with the statistics collector daemon. We have rather strict > > packet filter rules in place, and I'd like to make the system use a > > fixed port for this, or even better a Unix domain socket. Is this > > possible (setting a compile time or run time parameter)? > > No, the stats collector just uses whatever port bind() chooses for it. A pity. > I'd suggest backing off your ideas about how much filtering is > appropriate for local connections. Since we're running multiple database instances with different projects on one machine I'd like to isolate them as best I can. Thanks anyway... peter. > > regards, tom lane
On Tue, May 4, 2010 at 1:41 PM, Peter Sabaini <peter.sabaini@ait.ac.at> wrote: > On Tue, 2010-05-04 at 11:39 -0400, Tom Lane wrote: >> Peter Sabaini <peter.sabaini@ait.ac.at> writes: >> > it seems Postgres tries to send a UDP packet to a random high port to >> > communicate with the statistics collector daemon. We have rather strict >> > packet filter rules in place, and I'd like to make the system use a >> > fixed port for this, or even better a Unix domain socket. Is this >> > possible (setting a compile time or run time parameter)? >> >> No, the stats collector just uses whatever port bind() chooses for it. > > A pity. > >> I'd suggest backing off your ideas about how much filtering is >> appropriate for local connections. > > Since we're running multiple database instances with different projects > on one machine I'd like to isolate them as best I can. Maybe running them in individual VMs would do that.
Peter Sabaini <peter.sabaini@ait.ac.at> writes:
> On Tue, 2010-05-04 at 11:39 -0400, Tom Lane wrote:
>> I'd suggest backing off your ideas about how much filtering is
>> appropriate for local connections.
> Since we're running multiple database instances with different projects
> on one machine I'd like to isolate them as best I can.
Since the stats collector uses pre-bound UDP sockets, it should not be
possible for any interference to occur. If anything other than other
processes in the same PG herd is able to send a message on that socket,
it would be a kernel bug.
regards, tom lane
On Tue, 2010-05-04 at 14:04 -0600, Scott Marlowe wrote: > On Tue, May 4, 2010 at 1:41 PM, Peter Sabaini <peter.sabaini@ait.ac.at> wrote: > > On Tue, 2010-05-04 at 11:39 -0400, Tom Lane wrote: > >> Peter Sabaini <peter.sabaini@ait.ac.at> writes: > >> > it seems Postgres tries to send a UDP packet to a random high port to > >> > communicate with the statistics collector daemon. We have rather strict > >> > packet filter rules in place, and I'd like to make the system use a > >> > fixed port for this, or even better a Unix domain socket. Is this > >> > possible (setting a compile time or run time parameter)? > >> > >> No, the stats collector just uses whatever port bind() chooses for it. > > > > A pity. > > > >> I'd suggest backing off your ideas about how much filtering is > >> appropriate for local connections. > > > > Since we're running multiple database instances with different projects > > on one machine I'd like to isolate them as best I can. > > Maybe running them in individual VMs would do that. We run them in containers (kind of like a chroot++). Since we're running a lot of small projects on that machine, full virtualization (VMware, Xen etc) would be unfeasible. -- PETER SABAINI Safety & Security Department Information Management & eHealth AIT Austrian Institute of Technology GmbH Reininghausstraße 13/1 | 8020 Graz | Austria T +43(0) 316 586570-55 | M +43(0) 664 8251123 | F +43(0) 316 586570-12 peter.sabaini@ait.ac.at | http://www.ait.ac.at | http://www.ait.ac.at/eHealth FN: 115980 i HG Wien | UID: ATU14703506 Kennen Sie die www.eHealth2010.at ? This email and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient, please notify the sender by return e-mail or by telephone and delete this message from your system and any printout thereof. Any unauthorized use, reproduction, or dissemination of this message is strictly prohibited. Please note that e-mails are susceptible to change. AIT Austrian Institute of Technology GmbH shall not be liable for the improper or incomplete transmission of the information contained in this communication, nor shall it be liable for any delay in its receipt.