https://discourse.gnome.org/t/split-and-rename-of-chrome-gnome-shell/11075815ec9e1af...v42.0
- Renamed and split into a separate repo from the extensions.
- CMake build replaced with Meson (jq also not needed)
- requests Python module not needed since updates are now solely handled by GNOME Shell itself
Also
- Corrected license
- Cleaned up the module
- Replaced PYTHONPATH in a wrapper by Python environment
Changelog-Reviewed-By: Jan Tojnar <jtojnar@gmail.com>
This option allows for the customization of the description of the
created gitolite user.
An example of this being useful is for the integration of gitolite with
cgit, which itself uses the gitolite user's description as the author of
the git repo displayed in its generated site.
The original implementation had a few issues:
* The secret was briefly leaked since it is part of the cmdline for
`sed(1)` and on Linux `cmdline` is world-readable.
* If the secret would contain either a `,` or a `"` it would mess with
the `sed(1)` expression itself unless you apply messy escape hacks.
To circumvent all of that, I decided to use `replace-secret` which
allows you to replace a string inside a file (in this case
`#static-auth-secret#`) with the contents of a file, i.e.
`cfg.static-auth-secret-file` without any of these issues.
This commit fixes two bugs:
1) When starting a github-runner for the very first time, the
unconfigure script did not copy the `tokenFile` to the state
directory. This case just was not handled so far. As a result, the
runner could not configure. The unit did, however, fail even before
as the state token file is configured as inaccessible for the service
through `InaccessiblePaths=`. As the given path did not exist in the
described case, setting up the unit's namespacing failed.
2) Similarly, the `tokenFile` is also marked as not accessible to the
service user. There are, however, cases where other namespacing
options make the files inaccessible even before `InaccessiblePaths=`
kicks in; thus, they appear as non existing and cause the namespacing
to fail yet again. Prefixing the entry with a `-` causes Systemd to
ignore the entry if it cannot find it. This is the behavior we want.
I also took fixing those bugs as a chance to refactor the unconfigure
script to make it easier to follow.
`privacyidea-token-janitor`[1] is a tool which helps to automate
maintenance of tokens. This is helpful to identify e.g. orphaned tokens,
i.e. tokens of users that were removed or tokens that were unused for a
longer period of time and apply actions to them (e.g. `disable` or
`delete`).
This patch adds two new things:
* A wrapper for `privacyidea-token-janitor` to make sure it's executable
from CLI. To achieve this, it does a `sudo(8)` into the
`privacyidea`-user and sets up the environment to make sure the
configuration file can be found. With that, administrators can
directly invoke it from the CLI without additional steps.
* An optional service is added which performs automatic cleanups of
orphaned and/or unassigned tokens. Yes, the tool can do way more
stuff, but I figured it's reasonable to have an automatic way to clean
up tokens of users who were removed from the PI instance. Additional
automation steps should probably be implemented in additional
services (and are perhaps too custom to add them to this module).
[1] https://privacyidea.readthedocs.io/en/v3.7/workflows_and_tools/tools/index.html
Some networks can only transfer packets with a lower than normal maximum
transfer unit size. In these cases, it is necessary to set a MTU that
works for the given upstream network.
Wireguard can tag its packets with a firewall mark. This can be used for
firewalls or policy routing. This is very useful in some setups where
all traffic should go through a wireguard interface. The wireguard
packets cannot go through the wireguard interface and must be routed
differently, which can be done via the Firewall Mark.
The nixos option `config.networking.wireguard.interface.<name>.fwMark`
is of type `types.str` and not `types.int` to allow for specifying the
mark as a hexadecimal value.
