Re: postgresql 7.2b5 and vserver: statistics sockets
От | |
---|---|
Тема | Re: postgresql 7.2b5 and vserver: statistics sockets |
Дата | |
Msg-id | Pine.LNX.4.33.0201231810250.10226-100000@mail.conostix.com обсуждение исходный текст |
Ответ на | Re: postgresql 7.2b5 and vserver: statistics sockets (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: postgresql 7.2b5 and vserver: statistics sockets
|
Список | pgsql-general |
On Wed, 23 Jan 2002, Tom Lane wrote: > <postgresql@fruru.com> writes: > > If more people encounter the same problem (it's the way vserver works, > > there are some good arguments on why not to make 127.0.0.1 available) > > Uh ... what are they? We're willing to listen to reasonable arguments > why that needs to be configurable. All the vservers on a physical machine actually run on the same kernel and therefore share the same loopback interface. Every vserver has one IP address (alias) which it can use as its own. So using the alias we know in advance which vserver (if any) we send a packet to. Using 127.0.0.1 we don't, since if we don't limit the use of this address by the vservers, everyone (including people in a "hostile" vserver on the same physical machine) could bind to it and interfere with our vserver -> Not So Good(tm). Having multiple lo interfaces, one per vserver, on the same "real" kernel could be a solution were it not that this quickly becomes a mess (i see some routing issues) Of course, when binding the stats port to something else than 127.0.0.1 one needs to implement a minimum of firewalling if one doesn't trust the network (or the other vservers). But this isn't really new and I hope anyone in such a case already has their FW up and running. Hope this helps, Tycho Fruru
В списке pgsql-general по дате отправления: