On Thu, Oct 27, 2016 at 12:45 PM, Francisco Olarte
<folarte@peoplecall.com> wrote:
> Merlin:
>
> On Thu, Oct 27, 2016 at 7:29 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
>> On Thu, Oct 27, 2016 at 11:18 AM, Francisco Olarte
>> <folarte@peoplecall.com> wrote:
>>> It is, but handling them is not easy, and you have to deal with things
>>> like DoS which are not trivial on the server ( as it is a heavy
>>> service ). It can be done, and sometimes needs to be done, but is not
>>> a thing to take over lightly.
>>>> This could be over ssh tunnel for example.
>>> In which case it is NOT exposed to the internet. What are you trying to say?
>>
>> what? ssh can most certainly convey over the internet. I said ssh
>> *tunnel*; not ssh. With tunneling the ssh endpoint is the client
>> application. When I built a libpq based intenet facing application
>> we used a modified pgbouncer to whitelist the parameterized query
>> strings and to force the auth. We had zero issues.
>
> I'm not a native English speaker, so I have some problem understanding
> the finer details....
>
> I said libpq service/protocols are tricky to put on the internet.
>
> You replied, among other things, it could be over an ssh tunnel ( I
> use ssh tunnels continuously, to the point I routinely open/close them
> on live connections via escape, so I know they are ).
right -- we may be talking past each other. You originally said,
'across a firewall', not 'exposed to the internet'. I agree that you
should not expose a database directly to the internet without very
carefully considering the ramifications, but there are many scenarios
where you would cross a firewall where the suggestions advised here
(tcp keepalives) are useful and good to do.
In our corporate intranet here we have overzealous firewalls which
causes major problems with many applications stacks, particularly
java. Aggressive keepalives deals with such cases pretty well.
merlin