[RFC] etebase: add package

[peter-stadler]

Maintainer: me
Compile tested: x86_64, x86_64 qemu, master
Run tested: x86_64, x86_64 qemu, master, run it

Description: This is the new version of etesync-server.

Question: As it changed quite a bit needing a manual migration of the users and is also renamed to etebase, I would create a new package with the same name. Is this a good way, also in regard of deprecating the etesync-server package later on (is this possible)?

[neheb]

Please rebase to remove the red checkmarks.

[peter-stadler]

Rebased, thank you :-)

[neheb]

ping @jefferyto

[jefferyto]

Is it necessary to have both etesync-server and etebase available to be able to migrate users? How hard would it be to clear all etesync-server data and recreate it for etebase (by the user manually)? (Apologies if these are silly questions, I'm not familiar with this software.)

Since etesync-server isn't available on any release branch, my preference would be to have a clean break and rename etesync-server to etebase directly. Otherwise we have no clear criteria for how long to keep etesync-server around.

Also, I would prefer this renaming/duplicating the package to be done in a few commits rather than one; the diff is hard to read when it combines renames and other functional changes. I suggest one commit where etesync-server is changed to etebase (or, if we need to keep both packages, one commit where etesync-server is duplicated to etebase where the only changes are renames), then another commit to apply other functional changes.

[peter-stadler]

Thank you, this are very good hints :-) To answer your questions, I would distinguish:

• hoster that is the user of the servers on OpenWrt (etesync or etebase) and has only access to encrypted data
• end user that has an app on another device, connects to the server on Openwrt and can decrypt the data.

Is it necessary to have both etesync-server and etebase available to be able to migrate users?

The official guide wants it so: The hoster needs to create new accounts for each end user (here the etesync database can be used as source for user names). Then the end users can migrate their data on their own. I tested both migration tools:

• The web migration tool wants both: the etesync-server and etebase
• The android client can migrate its stage of the data to etebase even if the etesync-server is not available anymore (but the data that is changed and not synced to the android client would be lost).

I suppose for the typical use case on OpenWrt it would work to migrate without etesync-server.

How hard would it be to clear all etesync-server data and recreate it for etebase (by the user manually)?

The hoster can delete one database for clearing the data, but there is no way for recreating the data (as it is encrypted and there changed too much). The end users can use one of the copies in their clients (I suppose this is what the migration tool does internally).

---

So, I made two commits renaming the package etesync-server to etebase first, then upgrading it. Should I squash them before the merge or split it into two PRs?
Edit: The hoster has to remove the etesync-server manually (it is not uninstalled and even by uninstalling the database would not be deleted).

[neheb]

I take it this is ready?

[jefferyto]

@peter-stadler thanks for the updates 😄

Should I squash them before the merge or split it into two PRs?

I don't think either is strictly necessary; it's fine to have more than one commit in one PR.

The hoster has to remove the etesync-server manually (it is not uninstalled and even by uninstalling the database would not be deleted).

This is a nice (if perhaps unintentional) side effect to allow both etesync-server and etebase to be installed at the same time. I take it though that the web migration tool needs both running at the same time but this would not be possible with the current (default) config?

I don't think this is a great loss (if someone is using master they should expect to deal with things breaking). If running both is necessary for the migration and there are simple steps they can take to make this happen, it would be nice to document it either in a readme or just here in the PR.

[peter-stadler]

Thank you. So I think it is ready :-)

Actually the default configs are ready to run etesync-server and etebase at the same time (they are available at https://192.168.1.1/etesync and https://192.168.1.1/etebase) and the web migration tool works (I used it to migrate one account). But the device needs enough RAM to run both servers simultaneously (each of them needs about 35 MB).

The web migration tool first pulls all the data from etesync (not needing etebase running) and then pushes it to etebase (not needing etesync-server running anymore). So as a workaround with less than 70 MB free RAM you could:

• as hoster stop etesync-server between the two steps by service etesync-server stop
• as end user wait 10 minutes: If there is no request to etesync-server, it will be terminated (by the uwsgi emperor after the configured idle time)

Then there should be only one of the two servers running at a time.