-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Conversation
The problem with this script is that it is largely untested, entirely unmaintained, and running it is likely to make your synapse blow up in exciting ways. For example, it leaves a bunch of tables with dead values in it, like event_to_state_groups. Having it here sends a message that it is a supported part of synapse, which is absolutely not the case.
I probably would not have run this in the past, if I had known how unsupported it is. On the other hand, in the cases when I used it, it got my synapse back up and running after rooms got messed up somehow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes pls
Features -------- - Python 3.5 and 3.6 support is now in beta. ([\#3576](#3576)) - Implement `event_format` filter param in `/sync` ([\#3790](#3790)) - Add synapse_admin_mau:registered_reserved_users metric to expose number of real reaserved users ([\#3846](#3846)) Bugfixes -------- - Remove connection ID for replication prometheus metrics, as it creates a large number of new series. ([\#3788](#3788)) - guest users should not be part of mau total ([\#3800](#3800)) - Bump dependency on pyopenssl 16.x, to avoid incompatibility with recent Twisted. ([\#3804](#3804)) - Fix existing room tags not coming down sync when joining a room ([\#3810](#3810)) - Fix jwt import check ([\#3824](#3824)) - fix VOIP crashes under Python 3 (#3821) ([\#3835](#3835)) - Fix manhole so that it works with latest openssh clients ([\#3841](#3841)) - Fix outbound requests occasionally wedging, which can result in federation breaking between servers. ([\#3845](#3845)) - Show heroes if room name/canonical alias has been deleted ([\#3851](#3851)) - Fix handling of redacted events from federation ([\#3859](#3859)) - ([\#3874](#3874)) - Mitigate outbound federation randomly becoming wedged ([\#3875](#3875)) Internal Changes ---------------- - CircleCI tests now run on the potential merge of a PR. ([\#3704](#3704)) - http/ is now ported to Python 3. ([\#3771](#3771)) - Improve human readable error messages for threepid registration/account update ([\#3789](#3789)) - Make /sync slightly faster by avoiding needless copies ([\#3795](#3795)) - handlers/ is now ported to Python 3. ([\#3803](#3803)) - Limit the number of PDUs/EDUs per federation transaction ([\#3805](#3805)) - Only start postgres instance for postgres tests on Travis CI ([\#3806](#3806)) - tests/ is now ported to Python 3. ([\#3808](#3808)) - crypto/ is now ported to Python 3. ([\#3822](#3822)) - rest/ is now ported to Python 3. ([\#3823](#3823)) - add some logging for the keyring queue ([\#3826](#3826)) - speed up lazy loading by 2-3x ([\#3827](#3827)) - Improved Dockerfile to remove build requirements after building reducing the image size. ([\#3834](#3834)) - Disable lazy loading for incremental syncs for now ([\#3840](#3840)) - federation/ is now ported to Python 3. ([\#3847](#3847)) - Log when we retry outbound requests ([\#3853](#3853)) - Removed some excess logging messages. ([\#3855](#3855)) - Speed up purge history for rooms that have been previously purged ([\#3856](#3856)) - Refactor some HTTP timeout code. ([\#3857](#3857)) - Fix running merged builds on CircleCI ([\#3858](#3858)) - Fix typo in replication stream exception. ([\#3860](#3860)) - Add in flight real time metrics for Measure blocks ([\#3871](#3871)) - Disable buffering and automatic retrying in treq requests to prevent timeouts. ([\#3872](#3872)) - mention jemalloc in the README ([\#3877](#3877)) - Remove unmaintained "nuke-room-from-db.sh" script ([\#3888](#3888))
If i look at the database structure: #934 I think it is easy:
how do I delete only those entries now? |
none of that addresses the fact that we're not able to support and test it. I suggest you maintain your own sql script. |
I will :) Delete data concerning only the room would be
I think it is much easyer and also deletes orphaned entries like this:
am I right? @richvdh what other tables have orphaned entries after using the old nuke script? |
A more secure way to clear event_to_state_groups will be these commands:
(this can take some minutes if you have millions of events already) shut synapse down to delete the entries(not sure if shutdown is needed)
start it up again
Do I understand it right, that If so, then we would have to do the same deletion script with |
For everyone who search for a secure solution to delete a room (or something nearby), I create a php script as replacement for the php riot_delete_room.php https://matrix.org "MDA...kYK" "#alias:domain.de" The script only shows all members and the stop and ask if the members should kick. Then ask for a reason and a possible userId which should not kicked. |
The purge api seems to be only able to remove empty rooms. The old nuke script was meant to repair unaccessible rooms, or rooms that contain errors. would the php script be able to remove those rooms too? I would love to have a real new nuke-script (if the synapse api doesn't work any more for example to remove an old broken room with some foreign-key entries missing in my database that always sais, there is an unread message, but there isn't and where I cannot post or do anything inside any more) |
PHP script posted above won't delete private rooms if admin is not joined to them. What would be needed is an admin api that allows server admin to kick any user from any room regardless of membership. Then purge_room api could be used. |
/_synapse/admin/v1/purge_room can only purge rooms, that have no users in it, does this mean no users from your homeserver or no users at all? It would be helpful to add an option to purge it also, if there are still users in it that didn't log in for some years |
purge_room will delete data if no local user (any user having account on homeserver that you call purge_api on) is a member of a room being purged. It will delete data from your homeserver even if users of remote homeserver are still in this room. Data will obviously still persist on remote homeservers. |
So this will be a problem, if there is at least one user from your HS (that might not be active any more or even only logged in a few years ago and then forgot his password). |
The problem with this script is that it is largely untested, entirely
unmaintained, and running it is likely to make your synapse blow up in
exciting ways.
For example, it leaves a bunch of tables with dead values in it, like
event_to_state_groups.
Having it here sends a message that it is a supported part of
synapse, which is absolutely not the case.