| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
| |
There is no change log, as this is a security update.
|
|
|
|
| |
The `~@priviledged` needed to go, as `@chown` is part of this group.
|
|
|
|
| |
Image upload still fails, even with this test passing.
|
|
|
|
| |
This is, for some reason, needed for image uploads to sharkey.
|
|
|
|
| |
registered
|
|
|
|
|
|
| |
Note, that I have no way to test if this is actually going to work (no tests for matrix).
But, I assume that it is not going to pose problems, as we are not
migrating the db and these options won't remove state.
|
| |
|
| |
|
|
|
|
| |
We are not generating taskserver certificates anymore.
|
| |
|
| |
|
|
|
|
| |
This includes setting things, like setting the `X-Forwarded-For` header.
|
|
|
|
| |
are avoided
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Restarting might be useful, if stalwart is actually _running_ in prod,
but currently the constant restart makes it very difficult to
debug (or even stop) the service.
|
| |
|
|
|
|
|
| |
For some reason, this is not done already. Setting this prevents an
assertion being thrown, that the "acme" user does not have a group.
|
|
|
|
|
| |
This is needed for the http challenge (and for the potential to use
nginx as a proxy in the future.)
|
|
|
|
|
|
| |
If a password hash does not match stalwart's know ones, it will just
treat it as plaintext. This is obviously very bad, and should be
avoided.
|
|
|
|
| |
This makes it possible to use the internal storage
|
| |
|
|
|
|
| |
This has to do with the underlying stalwart-mail update.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Server2 is currently not so much under load, as such it seems better to
split the load.
# server2
## Virtual Hosts
etebase.vhack.eu: dav.vhack.eu
gallery.s-schoeffel.de
git.foss-syndicate.org
invidious-router.vhack.eu: video.fosswelt.org invidious-router.sils.li
issues.foss-syndicate.org
libreddit.vhack.eu
nextcloud.vhack.eu # <-- This
redlib.vhack.eu
sharkey.vhack.eu # <-- And this are the “only” really heavy services here.
source.foss-syndicate.org
source.vhack.eu
## Open ports
TCP 22: ssh
TCP 25: mail-smtp
TCP 53: dns
TCP 80: http
TCP 443: https
TCP 465: mail-smtp-tls
TCP 993: mail-imap-tls
TCP 995: mail-pop3-tls
TCP 10222: taskchampion-sync
UDP 53: dns
# server3
## Virtual Hosts
b-peetz.de
mail.vhack.eu
mastodon.vhack.eu
matrix.vhack.eu
miniflux.foss-syndicate.org: rss.foss-syndicate.org rss.vhack.eu miniflux.vhack.eu
openpgpkey.b-peetz.de
openpgpkey.s-schoeffel.de
openpgpkey.sils.li
openpgpkey.vhack.eu
peertube.vhack.eu
trinitrix.vhack.eu
vhack.eu
## Open ports
TCP 22: ssh
TCP 25: <port is 'mail-smtp' but service 'vhack.mail' is not enabled.>
TCP 53: dns
TCP 80: http
TCP 443: https
TCP 465: <port is 'mail-smtp-tls' but service 'vhack.mail' is not enabled.>
TCP 993: <port is 'mail-imap-tls' but service 'vhack.mail' is not enabled.>
TCP 4190: ???
TCP 64738: ???
UDP 53: dns
UDP 64738: ???
|
|
|
|
|
|
|
|
| |
We can't test that much, as user creation and general configuration seems to be
locked behind completing a point and click adventure, once Sharkey is actually
setup.
As such, we simply test, that Sharkey starts and provides its default
HTML.
|
| |
|
|
|
|
| |
This is largely based on: https://github.com/sodiboo/system/blob/b63c7b27f49043e8701b3ff5e1441cd27d5a2fff/sharkey/package.nix
|
|
|
|
| |
This makes re-using it even easier.
|
|
|
|
| |
This makes it easier to re-use this test data for various tests.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The comment alone would probably suffice, but having a convenient function
that makes it obvious *what* part of the serial number you are actually
supposed to change seems quite useful, when trying to reduce the
possibilities of forgetting it.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Running two mail-servers on one system is a total /mess/. Both try to
bind to the same ports, the old stack consists of **5** different
systemd services whilst stalwart-mail's systemd service simply refuses
to stop, etc.
I'm confident that it can work, but it would probably be best to deploy
the new mail-server on server3.
|