Previously, this option was supposed to be a file of the form
`CLOUDFLARE_API_TOKEN=...`, which has a few problems:
- That's not an api token. It's an env file fit for passing to systemd's
`EnvironmentFile` option. The user could typo the variable name, or
intentionally/unintentionally include unrelated environment variables.
- It's not how secret files usually work in NixOS. Secret files are
usually just the secret, and don't leak details about how the secret
is passed to the service.
- This increases friction for people switching between cloudflare dyndns
services, such as `services.cloudflare-dyndns` and
`services.cfdyndns`, which both have a `apiToken` option, but (before
this change) with different semantics.
Previously, all generations for the primary system profile
read their data from the currently active one rather than
their own path, and specialisations in general all used
their parent bootspec rather than their own. This fixes both issues.
This commit still uses the parent path's build date for
specialisations, but this is more minor issue and the times
shouldn't be meaningfully different in most cases anyways.
Mar 19 21:35:05 mobilizon mobilizon[1324]: 21:35:05.504 [info] {"args":{},"attempt":19,"duration":130905,"error":"** (File.Error) could not write to file \"/var/lib/mobilizon/sitemap/sitemap-00001.xml\": no such file or directory","event":"job:exception","id":178203,"max_attempts":20,"meta":{},"queue":"background","queue_time":510620016,"source":"oban","state":"failure","tags":[],"worker":"Mobilizon.Service.Workers.BuildSiteMap"}
Some upstream systemd units are conditionally installed into the systemd
output, so we must make sure the feature that enables their installation
is enabled on our side prior to trying to use them.
Like for matrix-whatsapp use a static user so that the registration file can be automatically shared with synapse.
This also includes the registerToSynapse config option.
The option has been added in 50029ed89c
but never had any effect. As far as I could tell, it was only added for
backward compatibility. I think it's safe to remove this after 3+ years.
I opted for removal instead of implementing it since the module will
just do nothing if no site is configure, thus no enable / disable switch
is needed. Especially on a per-site level.
The seekable format splits compressed data into a series of independent
frames, each of which can be decompressed individually. This allows to
distribute images in smaller chunks and allows image downloads to be
paused and resumed later from the same point.
Seekable archives as a whole can be decompressed with any regular zstd
decompressor. However, partial decompression requires to know the
starting position of the desired frame, which can be extracted from a
skippable frame (aka seektable) that is appended to the compressed data.
prefect: add dburl to worker
prefect: use same state directory
prefect: fix worker environment
prefect: create user
prefect: use datadir for sqlite url
prefect: make datadir writable
prefect: don't protect home
prefect fix sqlite url
prefect: fix state directory
prefect: user should not be systemuser
prefect: set to normal user
add prefect to systempackages
try user with same name
prefect use prefect_home
do not set database url
revert to dynamic user
prefect: add tests
prefect: fix port to string
GNOME in particular just breaks if plymouth isn't disabled, because
GDM takes on the role of quitting plymouth in a GNOME
configuration. But if we're disabling the DM, we should disable
plymouth too anyway.
PR #322282 introduced a regression that causes the previous display of
the ssh host key fingerprints to get directed to the journal rather than
the console (as intended). Thus, the console only logs an empty set of
fingerprints:
-----BEGIN SSH HOST KEY FINGERPRINTS-----
-----END SSH HOST KEY FINGERPRINTS-----
The fix is to reorder the bash statement that invokes ssh-keygen so
that the ssh-keygen output is directed to /dev/console.
