Arch Linux User Repository

@mrpg I downgraded to nodejs-lts, that did the trick for me. Seems like its a issue in node or a new interaction with latest nodejs.

Has anyone gotten this to run recently? I was not able to access the website, so I dug a little deeper.

It seems to break right after starting the service, with journalctl saying something like /usr/bin/node[147752]: ../src/api/callback.cc:125:void node::InternalCallbackScope::Close(): Assertion(env_->execution_async_id()) == (0)' failed.. I can also bind to port 9001 usingnc -4 -l 9001` with no errors, so it truly doesn't seem to be running anymore.

Any insights?

Please not that 1.8.13 seems to be broken, so I will refrain from packaging it until upstream has addressed the issue: https://github.com/ether/etherpad-lite/issues/4975

Is there a manual procedure I could follow to install a plugin?

@mrvdb: Not that I'm aware of. However, if you're up for the pain, you can of course start packaging extensions for etherpad-lite.

Even if this means redoing it on upgrading the package it's worth it sometimes. Having the secure base install is nice, but without /any/ option to get a plugin to work, most people will need to choose another install method than this package.

And people are free to do so.

I saw someone mentioning manually putting a .ep_initialized file in the plugin folder, but that didn't seem to work for me. Also, given that the upstream issue has been open for more than 2 years now, a workaround would perhaps be fitting.

The problem is, that etherpad-lite doesn't really have a "plugin directory", but pollutes its base install directory when installing plugins.

That being said: You're free to modify this PKGBUILD for your own purposes of course. From a packaging standpoint it makes no sense though as it is unsafe to use and would basically require manual intervention all the time.

If you have some time to spend it is always a good idea to help upstream figure out how to solve the plugin directory issue and fix this problem at the root instead of making your system less secure.

Is there a manual procedure I could follow to install a plugin?

Even if this means redoing it on upgrading the package it's worth it sometimes. Having the secure base install is nice, but without /any/ option to get a plugin to work, most people will need to choose another install method than this package.

I saw someone mentioning manually putting a .ep_initialized file in the plugin folder, but that didn't seem to work for me. Also, given that the upstream issue has been open for more than 2 years now, a workaround would perhaps be fitting.

The problem appears to be caused by the fact that our Etherpad instance is served by Apache (proxy) under /pad. The fonts seem to be searched for using absolute paths, which probably was not the case before.

So this is not a packaging issue.

@respiranto: is your docroot at /usr/share/etherpad-lite/src/? The files are part of the package and are in /usr/share/etherpad-lite/src/static/font.

Note: Fixed typo in path

The problem appears with both skins.

Thanks for the quick reply!

I do indeed get several 404's for the following (font) requests:

GET /static/font/fontawesome-etherpad.woff?2 HTTP/1.1
GET /static/font/Roboto-Bold.ttf HTTP/1.1
GET /static/font/fontawesome-etherpad.ttf?2 HTTP/1.1
GET /static/font/Roboto-Regular.ttf HTTP/1.1

I adapted the configuration using a three-way diff between the old default, the new default and the custom version.

Probably unrelated, but for some reason, one of the preexisting notes, that I used to test the impact of configuration changes is now presented with the default text (and no history), even though it still exists in the database.

@respiranto: I can't reproduce this. Which skin are you using? The new "colibris" (that one works fine for me)? Did you use pacdiff (in pacman-contrib) to diff your configuration?

Do you see any error messages in the logs? Check your web server logs for 404s and potentially your etherpad-lite.service journal output.