Arch Linux User Repository

I updated to 1.6.2.

Please note: From now on, etherpad-lite is relying on systemd-tmpfiles and systemd-sysusers and the setting of a dynamic StateDirectory according to its service file. The scripts delivered by upstream are no longer run.

These new features make the package more secure, but the new way of installing it also renders its content static (i.e. the installation of plugins is currently not possible, as the installation folder is now owned by root).

Before the included npm package had the possibility to install all over the install directory, leading to folders and files not taken care of or cleaned up by pacman.

Although the new state is somewhat unfortunate, I hope you can appreciate it nonetheless from a viewpoint of this now being a "clean(er) install".

I referred to upstream about the changes to maybe inspire a change in the way plugins should be installed to a dedicated (settable) directory.

The way etherpad-lite is installed now is still far from being perfect.

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.

All the icons (e.g., to create a list) do no longer show (instead I see those boxes containing 4 hex digits). I do not know whether this is due to removed files or an upstream change requiring something on the client (a font?) that I do not have.

I have started removing a lot of arbitrary files in package() to lower the amount of files in this package. If this causes any trouble due to missing files, please let me know!

Apart from that, I have added many additional hardening options to the service file. If any of those cause trouble, please let me know!

etherpad-lite now also supports using unix sockets. I didn't have the time to test this yet, but if you test it, please give feedback and leave suggestions for e.g. systemd sockets unit (if that's possible).

I thought this can be an application that you can run on your desktop and uses a public instance. But I see this is for you to create a public instance.