Suggestion: refactoring the software to facilitate "shared" Etherpad installation to serve differently configured Etherpads instances

[Wikinaut]

How can I setup several Etherpad installations which share the code, and perhaps also the database ?

I'd like to set up different Etherpad installations, accessible through Apache2

• sharing a single Etherpad software core installation (shared)
• for different user groups
• with different favicons
• with different default pad texts
• optionally using distinct databases, or a single database but with distinct database prefixes

The current core file is settings.json, but this does not allow to configure everything.
Missing is the possibilty to define different favicons or to use a single database but with database prefixes (like MediaWiki optionally allows).

This bug is filed for tracking. I commit myself to work on a solution.

[JohnMcLear]

You wouldn't want to use Apache for something like this because apache wouldn't perform as well as something like varnish.

However if Apache is essential, you would use mod_proxy and run each etherpad instance on a seperate TCP port and have a separate database for each instance.

You would replicate the core of etherpad lite to different folders and run each instance in a different screen or start them all using one holding script that executes the watcher script. Yoyur file system replication would have ignores set for favicons and configs unique to that instance.

We currently run beta.etherpad.org and beta.primarypad.com like this but with varnish in front of nodejs.

Imho most sysadmins will want to replace the favicon with their own so I don't really see this as a priority.

[Wikinaut]

You would replicate the core of etherpad lite to different folders.
I'd rather suggest to use Symbolic links to point to a single core installation, where the entries go through dedicated ports and settings.json. I am currently working on that scheme.

You can flag this with low priority, and as suggestion.

[Pita]

you could give the settings file as an parameter.... I will think about that

[Wikinaut]

Yes.
Make the path/filename of settings.json an optional parameter to bin/run.sh which is then passed to InstDeps.sh and to node/utils/Settings.js

as discussed with Pita in the chat, 05.12.2011.

It should allow to start different etherpad jobs with different settings:

su etherpad /srv/etherpad/bin/run.sh settings.etherpad-xyz.json
su etherpad /srv/etherpad/bin/run.sh settings.etherpad-abc.json

[Pita]

Wikinaut suggested to set the settings file as an parameter

[Pita]

Can someone implement this settings file as a parameter? Shouldn't be too difficult

[jhollinger]

@Wikinaut The only critical (in my mind) thing my pull request wouldn't necessarily solve is "a single database with distinct prefixes." However, if you don't mix Groups between instances, it would essentially be the same thing. Thoughts?

[jhollinger]

I would suggest that this is done. Anyone disagree?

[Wikinaut]

I think the following issue is still open:

• with different favicons

to allow to run different pads with different favicons ( It should be possible to set up the path to favicon.ico in settings.json ).

[JohnMcLear]

@Wikinaut Feel free to write that in. It's really quite low hanging and a very low priority..

[redhog]

You can install ep_etherpad-lite globally with npm install and the "install" it locally in each "copy" with npm link.

We should add the ability to set database prefix, not just for this, but to be able to easily run etherpad alongside other web software within the same database...

[Wikinaut]

I think, my bug/issue/enhancement can be closed since different settings.json can be used.