The current command `create database gotosocial with locale C.UTF-8 template template0;` fails because the locale has to be quoted:
```
postgres=# create database gotosocial with locale C.UTF-8 template template0;
ERROR: syntax error at or near "."
LINE 1: create database gotosocial with locale C.UTF-8 template temp...
```
Tested manually that it works with the quotes and the official postgres examples also use quotes around the locales: https://www.postgresql.org/docs/current/sql-createdatabase.html
* update go-fed
* do the things
* remove unused columns from tags
* update to latest lingo from main
* further tag shenanigans
* serve stub page at tag endpoint
* we did it lads
* tests, oh tests, ohhh tests, oh tests (doo doo doo doo)
* swagger docs
* document hashtag usage + federation
* instanceGet
* don't bother parsing tag href
* rename whereStartsWith -> whereStartsLike
* remove GetOrCreateTag
* dont cache status tag timelineability
* Support setting private notes on accounts
* Reformat comment whitespace
* Add missing license headers
* Use apiutil.ParseID
* Rename Note model and cache to AccountNote
* Update golden cache config in test/envparsing.sh
* Rename gtsmodel/note.go to gtsmodel/accountnote.go
* Update AccountNote uniqueness constraint name
Now has same prefix as other indexes on this table.
---------
Co-authored-by: tobi <31960611+tsmethurst@users.noreply.github.com>
The old default of 30d can lead to a lot of media getting cached and
significant disk usage, even on small or single person instances. A lot
of deployments decrease this value, to 15 or even less. This is less of
an issue when using object storage, but for local storage which is the
more popular deployment option running out of disk space is unpleasant.
With GoToSocial's aim to fit in small places, this changes the default
to a much more conservative 7 days. In all likelihood people aren't
scrolling that far back in their timeline so this change shouldn't
result in any issue. Existing deployments will only be affected by
this change if the admin hasn't already configured this value, or didn't
bootstrap from the example configuration.
* Set default value of SMTPFrom to empty string
This parameter should contain proper e-mail address (to be provided by user during configuration).
* Update default values in example/config.yaml
Default values and related comments in example/config.yaml are aligned
with values defined in internal/config/defaults.go.
Small improvements to foramting of config.yaml file.
* Add default value for AdvancedThrottlingRetryAfter to internal/config/defaults.go
AdvancedThrottlingRetryAfter was introduced in 70739d3 (superseriousbusiness/gotosocial#1466).
* Update config.yaml snippets in documentation
* [docs] Rework backups a bit
This changes the existing backup documentation to:
* Push a bit harder on people to perform backups, it's not really just a
nice to have
* Removes the language about migrating to/from GoToSocial and a
different ActivityPub server since that's really not supported
* Adds a section about using backup software and provides an example on
how to do this using Borgmatic
* [docs] Remove too much info in db section
* [docs] Add docs on how to backup local media
This adds documentation pointing people at the media list-local command
in order to determine what media files they need to include as part of
their backups.
Provides a Python script that people can use to transform the media
listing from the CLI into Borg patterns. It also includes a Borgmatic
config.yaml in the repository so people can easily fetch it instead of
copy-pasting from the docs.
* [bugfix] Ensure we emit an absolute path prefix
It works either way, as a pattern like data/files/<ID> would match a
file on /data/files/<ID>. But it would potentially also match any path
that happens to include data/files/<ID> but not rooted at the
storage-local-base-path.
* [docs] Add more links to media list CLI reference
* [feature] Add media list command
This is an attempt to help alleviate #1776. Using admin media list
--local the full path to each local media file will be printed, with a
newline. The output of this should be feadable into backup tools in
order to allow to backup local media too. Together with the database
this should allow to fully recover from the loss of an instance.
The list command also gets a --remote flag for symmetry. In the case
of --remote we print the RemoteURL instead, the location the asset can
be retrieved from.
To get all media, you can run with --local and --remote.
* [bugfix] Fix the test failures
* [feature] Reimplement list media as top commands
This changes the implementation of admin media list --<variant> to two
separate top-level commands, list-local and list-remote.
The implementation now iterates over over the database in batches of 200
in order to avoid loading all media metadata into memory.
* [feature] Implement ListMedia with filter callback
This does away with the somewhat odd iterator-like structure we had
before and does away with most of the loop duplication in list-local and
list-remote. Instead they call GetAllMediaPaths with a filter func to
select the media they want. That's accumulated into a slice and
eventually returned.
* [bugfix] Simplify remote filter
Since we don't append the empty string anywhere, the remote filter can
be limited to returning RemoteURL, as that'll be an empty string for
local media.
* [docs] Add media list commands to CLI reference
---------
Co-authored-by: tobi <31960611+tsmethurst@users.noreply.github.com>
* [docs] Add a certificates guide in Advanced
This adds some documentation about the process of getting certificates
through ACME in general. It also provides a number of links to
alternative clients and certbot deployment guides that are up to date.
Slightly restructure the NGINX and Apache reverse proxy documentation
and insert mentions to the Provisioning TLS certificates advanced
documentation in them.
* [docs] Add firewall section in Advanced
* [docs] Add new guides to section indexes
* [docs] Fix spelling issue
* [docs] Fix a few typos
* [docs] Made Advanced its own section
This splits the Advanced page off from the Getting Started guide and
makes it its own thing. It now has some additional sub-sections for
bigger topics like caching and enhanced security. This also moves
tracing from Getting Started to Advanced as that feels like a more
appropriate location for it.
The enhanced security looks a little silly with a single section, but I
have guides pending for firewall configurations and I'd also like to
consolidate our how to provision TLS certificates in there as we repeat
this information multiple times.
* [docs] Fix all my spelling errors
* [docs] Inline the links in sandboxing
This tries to revamp/restructure the installation guide. It's renamed to
"Getting Started" as it now contains a few more things than just the
installation, especially the deployment considerations which we didn't
use to spell out as much ahead of time.
Installation is now a section with the guides on their own. I've removed
a bit of redundancy like the user creation. I also removed the rogue
reverse proxy section in the Docker guide and lifted that into the
reverse proxy section.
This adds an example on how to get Grafana Tempo up to receive spans as
well as Grafana itself to view them.
I've added this as a separate Tracing doc in the installation guide as
the Advanced one was starting to get rather full.
Fixes: #1791
Our default configuration places the SQLite DB in /gotosocial/, but the
AppArmor profile doesn't allow us to write there. Instead of making the
whole directory writable, add a writable area in /gotosocial/db/ instead
and advise in the docs to move the DB there.
Instead of a manually curated list of distribution packages, this adds
the Repology[1] widget instead.
This also separates out the distribution packages from the
self-hosting/deployment options into their own sections.
[1]: https://repology.org/project/gotosocial/versions
* start working on lists
* further list work
* test list db functions nicely
* more work on lists
* peepoopeepoo
* poke
* start list timeline func
* we're getting there lads
* couldn't be me working on stuff... could it?
* hook up handlers
* fiddling
* weeee
* woah
* screaming, pissing
* fix streaming being a whiny baby
* lint, small test fix, swagger
* tidying up, testing
* fucked! by the linter
* move timelines to state like a boss
* add timeline start to tests using state
* invalidate lists
This adds the preferences endpoint to our Mastodon Client API
implementation. It's a read-only endpoint that returns a number of
user preferences. Applications can query these settings when logging in
a user (for the first time) to configure themselves.
* Explain that markdown is enabled on the user settings page.
The current wording seems to imply that the input formatting can be
set on a per-post basis, which no client currently supports. It's not
clear that you have to go to the user settings page to change it.
* Update FAQ; some of the missing features are not missing any more!
* start working on notifs for new posts
* tidy up a bit
* update swagger
* carry over show reblogs + notify from follow req
* test notify on status post
* update column slice
* dedupe update logic + add tests
* fix own boosts not being timelined
* avoid type check, passing unnecessary accounts
* remove unnecessary 'inReplyToID' check
* add a couple todo's for future db functions
* start poking timelines
* OK yes we're refactoring, but it's nothing like the last time so don't worry
* more fiddling
* update tests, simplify Get
* thanks linter, you're the best, mwah mwah kisses
* do a bit more tidying up
* start buggering about with the prepare function
* fix little oopsie
* start merging lists into 1
* ik heb een heel zwaar leven
nee nee echt waar
* hey it works we did it reddit
* regenerate swagger docs
* tidy up a wee bit
* adjust paging
* fix little error, remove unused functions
* start fiddling about with email sending to allow multiple recipients
* do some fiddling
* notifs working
* notify on closed report
* finishing up
* envparsing
* use strings.ContainsAny
This adds a section to the docs instructing how to ensure apps will be
able to successfully login to an instance when host- and account-domain
differ.
Resolves#1609
