Subject: [Tools-discuss] Etherpad no longer on standard port

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 Mar 2020 14:54:05 +0100

On 2020-03-04, at 05:07, Larry Masinter <[email-masked]> wrote:
> 
> https://etherpad.ietf.org:9009/p/ManyCouches

Uh oh, that thing redirects to port 9009 now.
That is not going to work with many firewalls.

(Also:
pichat             9009        tcp    Pichat Server                [Mark_Seuffert]                                       [Mark_Seuffert]                                           2004-11
pichat             9009        udp    Pichat Server                [Mark_Seuffert]                                       [Mark_Seuffert]                                           2004-11
https://de.wikipedia.org/wiki/Pichat will not be familiar to many firewall admins, nor considered desired traffic if it is.)fn

(Ceterum Censeo: I think hackmd/CodiMD is a more appropriate tool for the 2020s.)

Grüße, Carsten

---

From: Glen <[email-masked]>
Date: Wed, 4 Mar 2020 08:05:15 -0800

Hi Carsten -

On Wed, Mar 4, 2020 at 5:54 AM Carsten Bormann <[email-masked]> wrote:
> Uh oh,

I'm sorry you're unhappy.  I hope the following information is helpful.

> that thing redirects

"Redirects" is correct. The reason we are running on a specific port
is because that is how Etherpad is designed to operate, out of the
box.  In order to make Etherpad work through a web browser without a
specified port, it is necessary to proxy it through the central Apache
server.  ( https://github.com/ether/etherpad-lite/wiki/How-to-put-Etherpad-Lite-behind-a-reverse-Proxy
).  That kind of thing is not the norm for Etherpad.  And
understandably so:  Because of the bidirectional, continuous nature of
Etherpad connections, that meant that every person connected to
Etherpad in a proxied setup also needs an active Apache connection to
be opened and maintained.  And that brings with it problems, as I will
outline:

> to port 9009 now.

"Now" is not exactly correct.  This has been the setup for several
months.  At the last IETF meeting, we found that Etherpad's proxied
connections were being disrupted whenever a high-volume misbehaving
search engine would start to spider the site, or any other high amount
of traffic would hit Apache.  No matter how high I might tune Apache,
search engines and other agents would pre-empt or expire out the
users' proxied Etherpad connections, resulting in continuous
disconnections (and *many* complaints.)  So, at that time, after hours
of on-line debugging, and as what amounted to an emergency measure, I
moved Etherpad back to its default configuration of running on its own
port.  This was announced at the meeting.  (
https://mailarchive.ietf.org/arch/msg/106all/wpga4gEF9z9I2rxk-y7ZFoyawYg/
).   This was in my opinion immediately necessary to restore reliable
Etherpad service, and it *did* successfully restore that service.

> That is not going to work with many firewalls.

I don't know about "many".  Nobody at the meeting last time reported
any firewall issues (or any other issues) once I made this change.
And indeed, everyone using Etherpad seemed satisfied with that
solution (with one exception, which was that, at that time, my
solution did not include SSL.   I added that right after the meeting,
and put the redirect in place at that time as a convenience to
participants.)  I'm sure that there are some firewall operators out
there who block outbound connections on high ports by default or
design, but I am hopeful that, during the time this setup is in use,
any IETF participant using Etherpad behind a blocked firewall will be
able to find a way to either work with, or around (perhaps with a VPN)
any firewall issues they may encounter.  I hope "many" is "a few", and
so far I have had no reports of anyone tripping over this change.  So
far, it's working fine, and without any issues.

> > https://de.wikipedia.org/wiki/Pichat will not be familiar to many firewall admins, nor considered desired traffic if it is.)fn

Nor, I suspect, is the "ETL Service Manager" - (although Tor - which
also seems to run on Etherpad's default port of 9001 - certainly would
be)
etlservicemgr 9001 tcp ETL Service Manager [Stephen_McCrea]
[Stephen_McCrea] 2002-03 Known Unauthorized Use on port 9001
etlservicemgr 9001 udp ETL Service Manager [Stephen_McCrea]
[Stephen_McCrea] 2002-03 Known Unauthorized Use on port 9001

I selected a port other than Etherpad's default to try to diffuse
potential Etherpad port-scanner graffiti attacks, and redirected the
name in Apache to the direct port as a convenience to the
participants.   If you or others want a *different* port, that's any
easy change, although I'm sure it would also be a significant
participant debate topic.

Yes, I am aware that people have opinions about port numbers.  I've
gotten suggestions that we should (a) run Nginix as a proxy front end
instead or (b) give Etherpad its own IP address or (c) "do a better
job" of blocking large incoming floods of Apache connections (like
search engines?)  or (d) many other, less-helpful and less-friendly
suggestions.  We are already queued to look at the helpful
suggestions, and I have some ideas on working this forward, but we
have not yet reached that point.

Meanwhile, the reality is that, while some people don't like
nonstandard ports, Etherpad is its own creature with its own unique
connection needs, and it does not, as we saw at IETF106, have the
ability to operate reliably under our current configuration, in
concert with everything else the IETF is running, especially at
meetings.  It is *designed* to run on its own exposed port.  It
appears to me that proxying things for Etherpad were documented as an
afterthought.  So I set up what I consider to be an acceptable
alternative (moving, for now, to the software's expected
configuration) to give participants the service they want, in the most
reliable way possible.

And to be clear:  This is not a "policy" decision.  I do not set
policy.  I'm the operator.  I fix problems.   So I am *not* trying to
imply here that "The IETF's policy is to run Etherpad on an exposed or
nonstandard port."  It is not.  Instead what I'm saying is, "It was
broken, badly, and I needed to fix it, on the fly, and I did so, and I
announced it, and I've queued this as something to discuss later on,
but for now it just needs to work, until something better can be
done."

And of course I want this to "be better", but I have not had the
opportunity to surface this issue to discuss it because we've all
being dealing with larger issues since the last meeting.  This *is* on
our collective radar to discuss but, because it does work now, and
because port numbers seem to be something at least recognized by the
IETF, this solution, while it may not be perfect on the "make everyone
happy" axis, does seem to be acceptable across the technical axis,
until we can engineer something better.

> (Ceterum Censeo: I think hackmd/CodiMD is a more appropriate tool for the 2020s.)

Now that *would* be a policy decision, and is outside my area.  I will
defer to others on that.

I hope this answers the questions implied, and, hopefully, reduces
your unhappiness.  I do want everyone to be happy... I also want
everything to work as reliably as possible.

Glen
--
Glen Barney
IT Director
AMS (IETF Secretariat)

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 Mar 2020 17:22:23 +0100

Hi Glen,

thank you for this detailed response!
I never figured what it was that you did to suddenly make IETF’s Etherpad much more reliable around IETF106, and now I understand.
I agree that, given the limitations of the software involved, that is the most sensible way to run the service.

My problems with getting people behind corporate firewalls to use Etherpad were real; I don’t remember which companies that were.  I mentioned the assignment of 9009 to point out that operators of firewalls who block 9009 do so justifiably.  Ultimately the question is whether people can use it or not, and firewall issues just combine with service reliability issues for the overall picture.  In other words, the separate port may indeed be a net win.

So my take is that there is additional incentive to look for what’s next after Etherpad, for functional as much as for those operational reasons.
I repeat my ceterum censeo that hackmd/CodiMD is a viable candidate, but that observation is not addressed at operational people at this point (although we’d have to figure out whether that can be run reliably — the sysadmins at my university tell me they can).

Grüße, Carsten

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 05 Mar 2020 17:25:33 +0200

One more data point: my own corporate firewall does block it: Connection Reset.

On 3/4/20, 18:22, "Tools-discuss on behalf of Carsten Bormann" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Glen,

    
    
    Grüße, Carsten
    
    ___________________________________________________________
    Tools-discuss mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/tools-discuss
    
    Please report datatracker.ietf.org and mailarchive.ietf.org
    bugs at http://tools.ietf.org/tools/ietfdb
    or send email to [email-masked]
    
    Please report tools.ietf.org bugs at
    http://tools.ietf.org/tools/issues
    or send email to [email-masked]