The Etherpad Foundation
Replies: 1 comment 5 replies
-
|
Downgrade to 1.9.6 for the time being would be my advice. They are using a new plugin loading system as of v1.9.7, with a new location for the NPM packages. Whatever library they use to fetch the list of plugins from https://static.etherpad.org/plugins.json is also failing for me (behind a corporate HTTP proxy), so I had to install them manually, with something like docker exec -u root etherpad /bin/sh
npm install --no-save --legacy-peer-deps ep_mediawikirun inside the docker container. I'd file a bug report, but I have a workaround, and the details of all the trouble I had with v1.9.7 are a bit fuzzy at this point. All I know is a lot of the workarounds you see for plugins failing to install in the issue tracker won't work anymore, as of 1.9.7, since the plugins go in |
Beta Was this translation helpful? Give feedback.
-
|
We use axios to fetch the data from the plugins.json endpoint. That should not be a problem. Maybe something in your reverse proxy is blocking this request. We had one case where the corporate network blocked somehow static. etherpad.org |
Beta Was this translation helpful? Give feedback.
-
|
Hi @SamTV12345 -- out of curiosity, what was the resolution in the case where the corporate firewall was blocking static.etherpad.org? I run etherpad in our a docker swarm within our high-security environment. Since our team is all on our high-security VPN we chose to use etherpad running there for working meetings and agendas, which may contain sensitive info. Worked flawlessly for us for a year... When I deploy the service within a local (Vagrant) dev environment that's built to mimic our production swarm, things run smoothly and the update from 1.9.6 to 1.9.7 worked flawlessly. However, when I try deploying it to prod, it fails. In the logs I see: Then it sits there for a while (maybe a minute or so), and then simply dies: Which looks a LOT like a timeout... therefore I can only assume this is because of the call to https://static.etherpad.org/plugins.json and the fact that our firewall definitely won't allow that. I'm definitely not eager to ask our infosec team to allow it. Is there a setting to disable the new live plugin installer and/or this call? I curate our images manually so we really have no need to live install a plugin. Any insight you can provide would be helpful... as of now we're just sticking to 1.9.6. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Kellen, sorry to here that there is an issue with the live plugin manager. I just tested if I can run etherpad offline without internet connection. That did work. How can I recreate your setup locally? |
Beta Was this translation helpful? Give feedback.
-
That alone is super helpful to know. It has to be something else with the environment. I will do more testing, thank you! |
Beta Was this translation helpful? Give feedback.
-
|
No worries. Feel free to ask if there are things I can help you with :D |
Beta Was this translation helpful? Give feedback.
-
Hello,
I recently tried to upgrade my etherpad instance from 1.9.4 to 1.9.7, but some weird npm-related failure causes a crash loop.
For my current setup, I followed this guide and it worked perfectly until a few days ago... I didn't manage to find the root cause of this crash loop, but figured a workaround by serving it on another url (through a reverse proxy).
Anyway, I thought it would be appropriate to upgrade to 1.9.7 during this unforseen maintenance. I rebuilt an etherpad image with the following plugins :
No error message during buildtime, yet when I started the docker compose stack, it went into another crash loop in which etherpad tries to download ep_adminpads3 plugin (even though it was successfully installed during the build). Of course etherpad fails to do so because it's hosted in an offline environment.
Any help on this would be very much appreciated !
Here is the detailed stacktrace :
Beta Was this translation helpful? Give feedback.
All reactions