This commit makes the source and destination network distinction
explicit. This is necessary, as the source and destination network may
not have the same ID in the database, and thus associations will be broken
when migrated.
This commit takes insert query compilation and transaction creation out
of the critical loop for migrating message logs. I have tested with
the sqlite backend, and a speedup of approximately 40x has been achieved
for log migration.
The service file will run `/usr/bin/soju --config /etc/soju/config`.
By default it'll run as a dynamically created `soju` user and group (DynamicUser=yes),
and it will run in a constrained environment[1], only having write access to
/var/lib/soju and /run/soju
If the admin creates a static `soju` user and group, those static uid/gid will be used,
with the same service constraints. This can be useful to share the static `soju` group
with other services, so they can access the soju logs and database even
if the service is not running (or before it's running).
The procedure for the initial user and database scaffold still
works normally, when run as `root`:
```
mkdir /var/lib/soju/
sojudb -config /etc/soju/config create-user myname -admin
```
NOTE: systemd will automatically change the ownership of files in /var/lib/soju/ when the service
is started.
`sojuctl` will work for root, or with `sudo -u soju`, just normally.
References:
- [1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html#DynamicUser=
This adds a new config option, `logs db`, which enables storing chat
logs in the soju database.
Regular store options, CHATHISTORY options, and SEARCH operations are
supported, like the fs logs backend.
Messages are stored in a new table, Message. In order to track the list
of targets we have messages for in an optimized manner, another database
is used: MessageTarget.
All new requests are backend by indexes so should be fast even with
hundreds of thousands of messages.
A contrib script is provided for migrating existing logs fs chat logs to
the database. It can be run with eg:
go run ./contrib/migrate-logs/ logs/ sqlite3:soju.db
Co-authored-by: Simon Ser <contact@emersion.fr>
Add a new flag to disable users. This can be useful to temporarily
deactivate an account without erasing data.
The user goroutine is kept alive for simplicity's sake. Most of the
infrastructure assumes that each user always has a running goroutine.
A disabled user's goroutine is responsible for sending back an error
to downstream connections, and listening for potential events to
re-enable the account.
This is a mecanical change, which just lifts up the context.TODO()
calls from inside the DB implementations to the callers.
Future work involves properly wiring up the contexts when it makes
sense.
Previous soju versions were storing log without converting the channel
and nick names to their canonical lower-case representation. This could
result in two log directories for the same channel/nick.
This script fixes old log dirs.
