Compare commits
1 commit
Author | SHA1 | Date | |
---|---|---|---|
d9470ab980 |
13 changed files with 46 additions and 479 deletions
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
obj: meta/collection
|
||||
rev: 2025-01-09
|
||||
rev: 2024-12-10
|
||||
---
|
||||
|
||||
# Applications
|
||||
|
@ -119,6 +119,7 @@ rev: 2025-01-09
|
|||
- [Wildcard](utilities/Wildcard.md)
|
||||
- [Textpieces](utilities/Textpieces.md)
|
||||
- [ImHex](utilities/ImHex.md)
|
||||
- [VirtManager](utilities/virt-manager.md)
|
||||
|
||||
# Mobile
|
||||
- [Aegis](./utilities/Aegis.md)
|
||||
|
@ -233,7 +234,6 @@ rev: 2025-01-09
|
|||
- [yazi](./cli/yazi.md)
|
||||
- [GPG](../cryptography/GPG.md)
|
||||
- [OpenSSL](../cryptography/OpenSSL.md)
|
||||
- [age](../cryptography/age.md)
|
||||
- [tomb](./cli/tomb.md)
|
||||
- [dysk](./cli/dysk.md)
|
||||
- [pass](./cli/pass.md)
|
||||
|
@ -253,7 +253,6 @@ rev: 2025-01-09
|
|||
- [wine](../windows/Wine.md)
|
||||
- [sbctl](../linux/sbctl.md)
|
||||
- [systemd-cryptenroll](../linux/systemd/systemd-cryptenroll.md)
|
||||
- [bubblewrap](./utilities/bubblewrap.md)
|
||||
|
||||
## Development
|
||||
- [act](./development/act.md)
|
||||
|
|
|
@ -1,71 +1,38 @@
|
|||
---
|
||||
obj: application
|
||||
repo: https://github.com/casey/intermodal
|
||||
website: imdl.io
|
||||
rev: 2025-01-28
|
||||
---
|
||||
|
||||
# Intermodal
|
||||
[Repo](https://github.com/casey/intermodal)
|
||||
Intermodal is a user-friendly and featureful command-line [BitTorrent](../../internet/BitTorrent.md) metainfo utility. The binary is called `imdl` and runs on [Linux](../../linux/Linux.md), [Windows](../../windows/Windows.md), and [macOS](../../macos/macOS.md).
|
||||
|
||||
## Usage
|
||||
### Create torrent file:
|
||||
```shell
|
||||
imdl torrent create [OPTIONS] <FILES>
|
||||
imdl torrent create file
|
||||
```
|
||||
|
||||
| Option | Description |
|
||||
| -------------------------------- | ----------------------------------------------------------------------------------------------------------- |
|
||||
| `-F, --follow-symlinks` | Follow symlinks in torrent input (default: no) |
|
||||
| `-f, --force` | Overwrite destination `.torrent` file if it exists |
|
||||
| `--ignore` | Skip files listed in `.gitignore`, `.ignore`, `.git/info/exclude`, and `git config --get core.excludesFile` |
|
||||
| `-h, --include-hidden` | Include hidden files that would otherwise be skipped |
|
||||
| `-j, --include-junk` | Include junk files that would otherwise be skipped |
|
||||
| `-M, --md5` | Include MD5 checksum of each file in the torrent ( warning: MD5 is broken) |
|
||||
| `--no-created-by` | Do not populate `created by` key with imdl version information |
|
||||
| `--no-creation-date` | Do not populate `creation date` key with current time |
|
||||
| `-O, --open` | Open `.torrent` file after creation (uses platform-specific opener) |
|
||||
| `--link` | Print created torrent `magnet:` URL to standard output |
|
||||
| `-P, --private` | Set private flag, restricting peer discovery |
|
||||
| `-S, --show` | Display information about the created torrent file |
|
||||
| `-V, --version` | Print version number |
|
||||
| `-A, --allow <LINT>` | Allow specific lint (e.g., `small-piece-length`, `private-trackerless`) |
|
||||
| `-a, --announce <URL>` | Use primary tracker announce URL for the torrent |
|
||||
| `-t, --announce-tier <URL-LIST>` | Add tiered tracker announce URLs to the torrent metadata, separate their announce URLs with commas. |
|
||||
| `-c, --comment <TEXT>` | Set comment text in the generated `.torrent` file |
|
||||
| `--node <NODE>` | Add DHT bootstrap node to the torrent for peer discovery |
|
||||
| `-g, --glob <GLOB>` | Include or exclude files matching specific glob patterns |
|
||||
| `-i, --input <INPUT>` | Read contents from input source (file, dir, or standard input) |
|
||||
| `-N, --name <TEXT>` | Set name of the encoded magnet link to specific text |
|
||||
| `-o, --output <TARGET>` | Save `.torrent` file to specified target or print to output |
|
||||
| `--peer <PEER>` | Add peer specification to the generated magnet link |
|
||||
| `-p, --piece-length <BYTES>` | Set piece length for encoding torrent metadata |
|
||||
| `--sort-by <SPEC>` | Determine order of files within the encoded torrent (path, size, or both) |
|
||||
| `-s, --source <TEXT>` | Set source field in encoded torrent metadata to specific text |
|
||||
| `--update-url <URL>` | Set URL where revised version of metainfo can be downloaded |
|
||||
Flags:
|
||||
```shell
|
||||
-N, --name <TEXT> Set name of torrent
|
||||
-i, --input <INPUT> Torrent Files
|
||||
-c, --comment <TEXT> Torrent Comment
|
||||
-a, --announce <URL> Torrent Tracker
|
||||
```
|
||||
|
||||
### Show torrent information
|
||||
```shell
|
||||
imdl torrent show <torrent>
|
||||
```
|
||||
|
||||
You can output the information as JSON using `--json`.
|
||||
|
||||
### Verify torrent
|
||||
```shell
|
||||
imdl torrent verify <torrent>
|
||||
imdl torrent verify --input torr.torrent --content file
|
||||
```
|
||||
|
||||
### Magnet Links
|
||||
### Generate magnet link
|
||||
```shell
|
||||
# Get magnet link from torrent file
|
||||
imdl torrent link [-s, --select-only <INDICES>...] <torrent>
|
||||
# Select files to download. Values are indices into the `info.files` list, e.g. `--select-only 1,2,3`.
|
||||
|
||||
# Get torrent file from magnet link
|
||||
imdl torrent from-link [-o, --output <OUT>] <INPUT>
|
||||
|
||||
# Announce a torrent
|
||||
imdl torrent announce <INPUT>
|
||||
```
|
||||
imdl torrent link <torrent>
|
||||
```
|
|
@ -1,7 +1,5 @@
|
|||
---
|
||||
obj: application
|
||||
repo: https://git.launchpad.net/ufw/
|
||||
arch-wiki: https://wiki.archlinux.org/title/Uncomplicated_Firewall
|
||||
---
|
||||
|
||||
# ufw
|
||||
|
@ -19,134 +17,19 @@ The next line is only needed _once_ the first time you install the package:
|
|||
ufw enable
|
||||
```
|
||||
|
||||
**See status:**
|
||||
See status:
|
||||
```shell
|
||||
ufw status
|
||||
```
|
||||
|
||||
**Enable/Disable:**
|
||||
Enable/Disable
|
||||
```shell
|
||||
ufw enable
|
||||
ufw disable
|
||||
```
|
||||
|
||||
**Allow/Deny:**
|
||||
Allow/Deny ports
|
||||
```shell
|
||||
ufw allow <app|port>
|
||||
ufw deny <app|port>
|
||||
|
||||
ufw allow from <CIDR>
|
||||
ufw deny from <CIDR>
|
||||
```
|
||||
|
||||
## Forward policy
|
||||
Users needing to run a VPN such as OpenVPN or WireGuard can adjust the `DEFAULT_FORWARD_POLICY` variable in `/etc/default/ufw` from a value of `DROP` to `ACCEPT` to forward all packets regardless of the settings of the user interface. To forward for a specific interface like `wg0`, user can add the following line in the filter block
|
||||
|
||||
```sh
|
||||
# /etc/ufw/before.rules
|
||||
|
||||
-A ufw-before-forward -i wg0 -j ACCEPT
|
||||
-A ufw-before-forward -o wg0 -j ACCEPT
|
||||
```
|
||||
|
||||
You may also need to uncomment
|
||||
|
||||
```sh
|
||||
# /etc/ufw/sysctl.conf
|
||||
|
||||
net/ipv4/ip_forward=1
|
||||
net/ipv6/conf/default/forwarding=1
|
||||
net/ipv6/conf/all/forwarding=1
|
||||
```
|
||||
|
||||
## Adding other applications
|
||||
The PKG comes with some defaults based on the default ports of many common daemons and programs. Inspect the options by looking in the `/etc/ufw/applications.d` directory or by listing them in the program itself:
|
||||
|
||||
```sh
|
||||
ufw app list
|
||||
```
|
||||
|
||||
If users are running any of the applications on a non-standard port, it is recommended to simply make `/etc/ufw/applications.d/custom` containing the needed data using the defaults as a guide.
|
||||
|
||||
> **Warning**: If users modify any of the PKG provided rule sets, these will be overwritten the first time the ufw package is updated. This is why custom app definitions need to reside in a non-PKG file as recommended above!
|
||||
|
||||
Example, deluge with custom tcp ports that range from 20202-20205:
|
||||
|
||||
```ini
|
||||
[Deluge-my]
|
||||
title=Deluge
|
||||
description=Deluge BitTorrent client
|
||||
ports=20202:20205/tcp
|
||||
```
|
||||
|
||||
Should you require to define both tcp and udp ports for the same application, simply separate them with a pipe as shown: this app opens tcp ports 10000-10002 and udp port 10003:
|
||||
|
||||
```ini
|
||||
ports=10000:10002/tcp|10003/udp
|
||||
```
|
||||
|
||||
One can also use a comma to define ports if a range is not desired. This example opens tcp ports 10000-10002 (inclusive) and udp ports 10003 and 10009
|
||||
|
||||
```ini
|
||||
ports=10000:10002/tcp|10003,10009/udp
|
||||
```
|
||||
|
||||
## Deleting applications
|
||||
Drawing on the Deluge/Deluge-my example above, the following will remove the standard Deluge rules and replace them with the Deluge-my rules from the above example:
|
||||
|
||||
```sh
|
||||
ufw delete allow Deluge
|
||||
ufw allow Deluge-my
|
||||
```
|
||||
|
||||
## Black listing IP addresses
|
||||
It might be desirable to add ip addresses to a blacklist which is easily achieved simply by editing `/etc/ufw/before.rules` and inserting an `iptables DROP` line at the bottom of the file right above the "COMMIT" word.
|
||||
|
||||
```sh
|
||||
# /etc/ufw/before.rules
|
||||
|
||||
...
|
||||
## blacklist section
|
||||
# block just 199.115.117.99
|
||||
-A ufw-before-input -s 199.115.117.99 -j DROP
|
||||
# block 184.105.*.*
|
||||
-A ufw-before-input -s 184.105.0.0/16 -j DROP
|
||||
|
||||
# don't delete the 'COMMIT' line or these rules won't be processed
|
||||
COMMIT
|
||||
```
|
||||
|
||||
## Rate limiting with ufw
|
||||
ufw has the ability to deny connections from an IP address that has attempted to initiate 6 or more connections in the last 30 seconds. Users should consider using this option for services such as SSH.
|
||||
|
||||
Using the above basic configuration, to enable rate limiting we would simply replace the allow parameter with the limit parameter. The new rule will then replace the previous.
|
||||
|
||||
```sh
|
||||
ufw limit SSH
|
||||
```
|
||||
|
||||
## Disable remote ping
|
||||
Change `ACCEPT` to `DROP` in the following lines:
|
||||
|
||||
```sh
|
||||
/etc/ufw/before.rules
|
||||
|
||||
# ok icmp codes
|
||||
...
|
||||
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT
|
||||
```
|
||||
|
||||
If you use IPv6, related rules are in `/etc/ufw/before6.rules`.
|
||||
|
||||
## Disable UFW logging
|
||||
Disabling logging may be useful to stop UFW filling up the kernel (dmesg) and message logs:
|
||||
|
||||
```sh
|
||||
ufw logging off
|
||||
```
|
||||
|
||||
## UFW and Docker
|
||||
Docker in standard mode writes its own iptables rules and ignores ufw ones, which could lead to security issues. A solution can be found at https://github.com/chaifeng/ufw-docker.
|
||||
|
||||
## GUI frontends
|
||||
If you are using KDE Plasma, you can just go to `Wi-Fi & Networking > Firewall` to access and adjust firewall configurations given `plasma-firewall` is installed.
|
||||
```
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
obj: application
|
||||
arch-wiki: https://wiki.archlinux.org/title/Pacman
|
||||
rev: 2025-01-08
|
||||
rev: 2024-12-19
|
||||
---
|
||||
|
||||
# Pacman
|
||||
|
@ -48,11 +48,6 @@ List explicitly installed packages:
|
|||
pacman -Qe
|
||||
```
|
||||
|
||||
List of packages owning a file/dir:
|
||||
```shell
|
||||
pacman -Qo /path/to/file
|
||||
```
|
||||
|
||||
List orphan packages (installed as dependencies and not required anymore):
|
||||
```shell
|
||||
pacman -Qdt
|
||||
|
|
|
@ -1,103 +0,0 @@
|
|||
---
|
||||
obj: application
|
||||
repo: https://github.com/containers/bubblewrap
|
||||
arch-wiki: https://wiki.archlinux.org//title/Bubblewrap
|
||||
rev: 2025-01-09
|
||||
---
|
||||
|
||||
# Bubblewrap
|
||||
Bubblewrap is a lightweight sandbox application used by Flatpak and other container tools. It has a small installation footprint and minimal resource requirements. Notable features include support for cgroup/IPC/mount/network/PID/user/UTS namespaces and seccomp filtering. Note that bubblewrap drops all capabilities within a sandbox and that child tasks cannot gain greater privileges than its parent.
|
||||
|
||||
## Configuration
|
||||
Bubblewrap can be called directly from the command-line and/or within shell scripts as part of a complex wrapper.
|
||||
|
||||
A no-op bubblewrap invocation is as follows:
|
||||
|
||||
```sh
|
||||
bwrap --dev-bind / / bash
|
||||
```
|
||||
|
||||
This will spawn a Bash process which should behave exactly as outside a sandbox in most cases. If a sandboxed program misbehaves, you may want to start from the above no-op invocation, and work your way towards a more secure configuration step-by-step.
|
||||
|
||||
### Desktop entries
|
||||
Leverage Bubblewrap within desktop entries:
|
||||
- Bind as read-write the entire host `/` directory to `/` in the sandbox
|
||||
- Re-bind as read-only the `/var` and `/etc` directories in the sandbox
|
||||
- Mount a new devtmpfs filesystem to `/dev` in the sandbox
|
||||
- Create a tmpfs filesystem over the sandboxed `/run` directory
|
||||
- Disable network access by creating new network namespace
|
||||
|
||||
```ini
|
||||
[Desktop Entry]
|
||||
Name=nano Editor
|
||||
Exec=bwrap --bind / / --dev /dev --tmpfs /run --unshare-net st -e nano -o . %f
|
||||
Type=Application
|
||||
MimeType=text/plain;
|
||||
```
|
||||
|
||||
> **Note**: `--dev /dev` is required to write to `/dev/pty`
|
||||
|
||||
## Options
|
||||
Usage: `bwrap [optiosn] [command]`
|
||||
|
||||
| Option | Description |
|
||||
| ------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `--args FD` | Parse nul-separated arguments from the given file descriptor. This option can be used multiple times to parse options from multiple sources. |
|
||||
| `--argv0 VALUE` | Set `argv[0]` to the value VALUE before running the program |
|
||||
| `--unshare-user` | Create a new user namespace |
|
||||
| `--unshare-user-try` | Create a new user namespace if possible else skip it |
|
||||
| `--unshare-ipc` | Create a new ipc namespace |
|
||||
| `--unshare-pid` | Create a new pid namespace |
|
||||
| `--unshare-net` | Create a new network namespace |
|
||||
| `--unshare-uts` | Create a new uts namespace |
|
||||
| `--unshare-cgroup` | Create a new cgroup namespace |
|
||||
| `--unshare-cgroup-try` | Create a new cgroup namespace if possible else skip it |
|
||||
| `--unshare-all` | Unshare all possible namespaces. Currently equivalent with: `--unshare-user-try --unshare-ipc --unshare-pid --unshare-net --unshare-uts --unshare-cgroup-try` |
|
||||
| `--share-net` | Retain the network namespace, overriding an earlier `--unshare-all` or `--unshare-net` |
|
||||
| `--userns FD` | Use an existing user namespace instead of creating a new one. The namespace must fulfil the permission requirements for `setns()`, which generally means that it must be a descendant of the currently active user namespace, owned by the same user. |
|
||||
| `--disable-userns` | Prevent the process in the sandbox from creating further user namespaces, so that it cannot rearrange the filesystem namespace or do other more complex namespace modification. |
|
||||
| `--assert-userns-disabled` | Confirm that the process in the sandbox has been prevented from creating further user namespaces, but without taking any particular action to prevent that. For example, this can be combined with --userns to check that the given user namespace has already been set up to prevent the creation of further user namespaces. |
|
||||
| `--pidns FD` | Use an existing pid namespace instead of creating one. This is often used with `--userns`, because the pid namespace must be owned by the same user namespace that bwrap uses. |
|
||||
| `--uid UID` | Use a custom user id in the sandbox (requires `--unshare-user`) |
|
||||
| `--gid GID` | Use a custom group id in the sandbox (requires `--unshare-user`) |
|
||||
| `--hostname HOSTNAME` | Use a custom hostname in the sandbox (requires `--unshare-uts`) |
|
||||
| `--chdir DIR` | Change directory to DIR |
|
||||
| `--setenv VAR VALUE` | Set an environment variable |
|
||||
| `--unsetenv VAR` | Unset an environment variable |
|
||||
| `--clearenv` | Unset all environment variables, except for PWD and any that are subsequently set by `--setenv` |
|
||||
| `--lock-file DEST` | Take a lock on DEST while the sandbox is running. This option can be used multiple times to take locks on multiple files. |
|
||||
| `--sync-fd FD` | Keep this file descriptor open while the sandbox is running |
|
||||
| `--perms OCTAL` | This option does nothing on its own, and must be followed by one of the options that it affects. It sets the permissions for the next operation to OCTAL. Subsequent operations are not affected: for example, `--perms 0700 --tmpfs /a --tmpfs /b` will mount `/a` with permissions `0700`, then return to the default permissions for `/b`. Note that `--perms` and `--size` can be combined: `--perms 0700 --size 10485760 --tmpfs /s` will apply permissions as well as a maximum size to the created tmpfs. |
|
||||
| `--size BYTES` | This option does nothing on its own, and must be followed by `--tmpfs`. It sets the size in bytes for the next tmpfs. For example, `--size 10485760 --tmpfs /tmp` will create a tmpfs at `/tmp` of size 10MiB. Subsequent operations are not affected. |
|
||||
| `--bind SRC DEST` | Bind mount the host path SRC on DEST |
|
||||
| `--bind-try SRC DEST` | Equal to `--bind` but ignores non-existent SRC |
|
||||
| `--dev-bind SRC DEST` | Bind mount the host path SRC on DEST, allowing device access |
|
||||
| `--dev-bind-try SRC DEST` | Equal to `--dev-bind` but ignores non-existent SRC |
|
||||
| `--ro-bind SRC DEST` | Bind mount the host path SRC readonly on DEST |
|
||||
| `--ro-bind-try SRC DEST` | Equal to `--ro-bind` but ignores non-existent SRC |
|
||||
| `--remount-ro DEST` | Remount the path DEST as readonly. It works only on the specified mount point, without changing any other mount point under the specified path |
|
||||
| `--overlay-src SRC` | This option does nothing on its own, and must be followed by one of the other overlay options. It specifies a host path from which files should be read if they aren't present in a higher layer. |
|
||||
| `--overlay RWSRC WORKDIR DEST`, `--tmp-overlay DEST`, `--ro-overlay DEST` | Use overlayfs to mount the host paths specified by `RWSRC` and all immediately preceding `--overlay-src` on `DEST`. `DEST` will contain the union of all the files in all the layers. With `--overlay` all writes will go to `RWSRC`. Reads will come preferentially from `RWSRC`, and then from any `--overlay-src` paths. `WORKDIR` must be an empty directory on the same filesystem as `RWSRC`, and is used internally by the kernel. With `--tmp-overlay` all writes will go to the tmpfs that hosts the sandbox root, in a location not accessible from either the host or the child process. Writes will therefore not be persisted across multiple runs. With `--ro-overlay` the filesystem will be mounted read-only. This option requires at least two `--overlay-src` to precede it. |
|
||||
| `--proc DEST` | Mount procfs on DEST |
|
||||
| `--dev DEST` | Mount new devtmpfs on DEST |
|
||||
| `--tmpfs DEST` | Mount new tmpfs on DEST. If the previous option was `--perms`, it sets the mode of the tmpfs. Otherwise, the tmpfs has mode `0755`. If the previous option was `--size`, it sets the size in bytes of the tmpfs. Otherwise, the tmpfs has the default size. |
|
||||
| `--mqueue DEST` | Mount new mqueue on DEST |
|
||||
| `--dir DEST` | Create a directory at DEST. If the directory already exists, its permissions are unmodified, ignoring `--perms` (use `--chmod` if the permissions of an existing directory need to be changed). If the directory is newly created and the previous option was `--perms`, it sets the mode of the directory. Otherwise, newly-created directories have mode `0755`. |
|
||||
| `--file FD DEST` | Copy from the file descriptor FD to DEST. If the previous option was `--perms`, it sets the mode of the new file. Otherwise, the file has mode `0666` (note that this is not the same as `--bind-data`). |
|
||||
| `--bind-data FD DEST` | Copy from the file descriptor FD to a file which is bind-mounted on DEST. If the previous option was `--perms`, it sets the mode of the new file. Otherwise, the file has mode `0600` (note that this is not the same as `--file`). |
|
||||
| `--ro-bind-data FD DEST` | Copy from the file descriptor FD to a file which is bind-mounted read-only on DEST. If the previous option was `--perms`, it sets the mode of the new file. Otherwise, the file has mode `0600` (note that this is not the same as `--file`). |
|
||||
| `--symlink SRC DEST` | Create a symlink at DEST with target SRC. |
|
||||
| `--chmod OCTAL PATH` | Set the permissions of PATH, which must already exist, to OCTAL. |
|
||||
| `--seccomp FD` | Load and use seccomp rules from FD. The rules need to be in the form of a compiled cBPF program, as generated by seccomp_export_bpf. If this option is given more than once, only the last one is used. Use `--add-seccomp-fd` if multiple seccomp programs are needed. |
|
||||
| `--add-seccomp-fd FD` | Load and use seccomp rules from FD. The rules need to be in the form of a compiled cBPF program, as generated by seccomp_export_bpf. This option can be repeated, in which case all the seccomp programs will be loaded in the order given (note that the kernel will evaluate them in reverse order, so the last program on the bwrap command-line is evaluated first). All of them, except possibly the last, must allow use of the PR_SET_SECCOMP prctl. This option cannot be combined with `--seccomp`. |
|
||||
| `--exec-label LABEL` | Exec Label from the sandbox. On an SELinux system you can specify the SELinux context for the sandbox process(s). |
|
||||
| `--file-label LABEL` | File label for temporary sandbox content. On an SELinux system you can specify the SELinux context for the sandbox content. |
|
||||
| `--block-fd FD` | Block the sandbox on reading from FD until some data is available. |
|
||||
| `--userns-block-fd FD` | Do not initialize the user namespace but wait on FD until it is ready. This allow external processes (like newuidmap/newgidmap) to setup the user namespace before it is used by the sandbox process. |
|
||||
| `--info-fd FD` | Write information in JSON format about the sandbox to FD. |
|
||||
| `--json-status-fd FD` | Multiple JSON documents are written to FD, one per line. |
|
||||
| `--new-session` | Create a new terminal session for the sandbox (calls `setsid()`). This disconnects the sandbox from the controlling terminal which means the sandbox can't for instance inject input into the terminal. Note: In a general sandbox, if you don't use `--new-session`, it is recommended to use seccomp to disallow the `TIOCSTI` ioctl, otherwise the application can feed keyboard input to the terminal which can e.g. lead to out-of-sandbox command execution. |
|
||||
| `--die-with-parent` | Ensures child process (COMMAND) dies when bwrap's parent dies. Kills (SIGKILL) all bwrap sandbox processes in sequence from parent to child including COMMAND process when bwrap or bwrap's parent dies. |
|
||||
| `--as-pid-1` | Do not create a process with PID=1 in the sandbox to reap child processes. |
|
||||
| `--cap-add CAP` | Add the specified capability CAP, e.g. `CAP_DAC_READ_SEARCH`, when running as privileged user. It accepts the special value `ALL` to add all the permitted caps. |
|
||||
| `--cap-drop CAP` | Drop the specified capability when running as privileged user. It accepts the special value `ALL` to drop all the caps. By default no caps are left in the sandboxed process. The `--cap-add` and `--cap-drop` options are processed in the order they are specified on the command line. Please be careful to the order they are specified. |
|
8
technology/applications/utilities/virt-manager.md
Normal file
8
technology/applications/utilities/virt-manager.md
Normal file
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
obj: application
|
||||
repo: https://github.com/virt-manager/virt-manager
|
||||
website: https://virt-manager.org
|
||||
---
|
||||
|
||||
# Virt Manager
|
||||
#wip
|
|
@ -1,123 +0,0 @@
|
|||
---
|
||||
obj: application
|
||||
repo: https://github.com/FiloSottile/age
|
||||
source: https://age-encryption.org/v1
|
||||
rev: 2025-01-09
|
||||
---
|
||||
|
||||
# age
|
||||
age is a simple, modern and secure file encryption tool, format, and Go library.
|
||||
|
||||
It features small explicit keys, no config options, and UNIX-style composability.
|
||||
|
||||
```sh
|
||||
$ age-keygen -o key.txt
|
||||
Public key: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p
|
||||
$ PUBLIC_KEY=$(age-keygen -y key.txt)
|
||||
$ tar cvz ~/data | age -r $PUBLIC_KEY > data.tar.gz.age
|
||||
$ age --decrypt -i key.txt data.tar.gz.age > data.tar.gz
|
||||
```
|
||||
|
||||
## Usage
|
||||
For the full documentation, read [the age(1) man page](https://filippo.io/age/age.1).
|
||||
|
||||
```
|
||||
Usage:
|
||||
age [--encrypt] (-r RECIPIENT | -R PATH)... [--armor] [-o OUTPUT] [INPUT]
|
||||
age [--encrypt] --passphrase [--armor] [-o OUTPUT] [INPUT]
|
||||
age --decrypt [-i PATH]... [-o OUTPUT] [INPUT]
|
||||
|
||||
Options:
|
||||
-e, --encrypt Encrypt the input to the output. Default if omitted.
|
||||
-d, --decrypt Decrypt the input to the output.
|
||||
-o, --output OUTPUT Write the result to the file at path OUTPUT.
|
||||
-a, --armor Encrypt to a PEM encoded format.
|
||||
-p, --passphrase Encrypt with a passphrase.
|
||||
-r, --recipient RECIPIENT Encrypt to the specified RECIPIENT. Can be repeated.
|
||||
-R, --recipients-file PATH Encrypt to recipients listed at PATH. Can be repeated.
|
||||
-i, --identity PATH Use the identity file at PATH. Can be repeated.
|
||||
|
||||
INPUT defaults to standard input, and OUTPUT defaults to standard output.
|
||||
If OUTPUT exists, it will be overwritten.
|
||||
|
||||
RECIPIENT can be an age public key generated by age-keygen ("age1...")
|
||||
or an SSH public key ("ssh-ed25519 AAAA...", "ssh-rsa AAAA...").
|
||||
|
||||
Recipient files contain one or more recipients, one per line. Empty lines
|
||||
and lines starting with "#" are ignored as comments. "-" may be used to
|
||||
read recipients from standard input.
|
||||
|
||||
Identity files contain one or more secret keys ("AGE-SECRET-KEY-1..."),
|
||||
one per line, or an SSH key. Empty lines and lines starting with "#" are
|
||||
ignored as comments. Passphrase encrypted age files can be used as
|
||||
identity files. Multiple key files can be provided, and any unused ones
|
||||
will be ignored. "-" may be used to read identities from standard input.
|
||||
|
||||
When --encrypt is specified explicitly, -i can also be used to encrypt to an
|
||||
identity file symmetrically, instead or in addition to normal recipients.
|
||||
```
|
||||
|
||||
### Multiple recipients
|
||||
Files can be encrypted to multiple recipients by repeating `-r/--recipient`. Every recipient will be able to decrypt the file.
|
||||
|
||||
```
|
||||
$ age -o example.jpg.age -r age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p \
|
||||
-r age1lggyhqrw2nlhcxprm67z43rta597azn8gknawjehu9d9dl0jq3yqqvfafg example.jpg
|
||||
```
|
||||
|
||||
#### Recipient files
|
||||
Multiple recipients can also be listed one per line in one or more files passed with the `-R/--recipients-file` flag.
|
||||
|
||||
```
|
||||
$ cat recipients.txt
|
||||
# Alice
|
||||
age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p
|
||||
# Bob
|
||||
age1lggyhqrw2nlhcxprm67z43rta597azn8gknawjehu9d9dl0jq3yqqvfafg
|
||||
$ age -R recipients.txt example.jpg > example.jpg.age
|
||||
```
|
||||
|
||||
If the argument to `-R` (or `-i`) is `-`, the file is read from standard input.
|
||||
|
||||
### Passphrases
|
||||
Files can be encrypted with a passphrase by using `-p/--passphrase`. By default age will automatically generate a secure passphrase. Passphrase protected files are automatically detected at decrypt time.
|
||||
|
||||
```
|
||||
$ age -p secrets.txt > secrets.txt.age
|
||||
Enter passphrase (leave empty to autogenerate a secure one):
|
||||
Using the autogenerated passphrase "release-response-step-brand-wrap-ankle-pair-unusual-sword-train".
|
||||
$ age -d secrets.txt.age > secrets.txt
|
||||
Enter passphrase:
|
||||
```
|
||||
|
||||
### Passphrase-protected key files
|
||||
If an identity file passed to `-i` is a passphrase encrypted age file, it will be automatically decrypted.
|
||||
|
||||
```
|
||||
$ age-keygen | age -p > key.age
|
||||
Public key: age1yhm4gctwfmrpz87tdslm550wrx6m79y9f2hdzt0lndjnehwj0ukqrjpyx5
|
||||
Enter passphrase (leave empty to autogenerate a secure one):
|
||||
Using the autogenerated passphrase "hip-roast-boring-snake-mention-east-wasp-honey-input-actress".
|
||||
$ age -r age1yhm4gctwfmrpz87tdslm550wrx6m79y9f2hdzt0lndjnehwj0ukqrjpyx5 secrets.txt > secrets.txt.age
|
||||
$ age -d -i key.age secrets.txt.age > secrets.txt
|
||||
Enter passphrase for identity file "key.age":
|
||||
```
|
||||
|
||||
Passphrase-protected identity files are not necessary for most use cases, where access to the encrypted identity file implies access to the whole system. However, they can be useful if the identity file is stored remotely.
|
||||
|
||||
### SSH keys
|
||||
As a convenience feature, age also supports encrypting to `ssh-rsa` and `ssh-ed25519` SSH public keys, and decrypting with the respective private key file. (`ssh-agent` is not supported.)
|
||||
|
||||
```
|
||||
$ age -R ~/.ssh/id_ed25519.pub example.jpg > example.jpg.age
|
||||
$ age -d -i ~/.ssh/id_ed25519 example.jpg.age > example.jpg
|
||||
```
|
||||
|
||||
Note that SSH key support employs more complex cryptography, and embeds a public key tag in the encrypted file, making it possible to track files that are encrypted to a specific public key.
|
||||
|
||||
#### Encrypting to a GitHub user
|
||||
Combining SSH key support and `-R`, you can easily encrypt a file to the SSH keys listed on a GitHub profile.
|
||||
|
||||
```
|
||||
$ curl https://github.com/benjojo.keys | age -R - example.jpg > example.jpg.age
|
||||
```
|
|
@ -401,11 +401,11 @@ You've seen most of the remaining operators in other examples:
|
|||
### Comments
|
||||
Dart supports single-line comments, multi-line comments, and documentation comments.
|
||||
|
||||
#### Single-line comments
|
||||
####Single-line comments
|
||||
A single-line comment begins with `//`. Everything between `//` and the end of line is ignored by the Dart compiler.
|
||||
```dart
|
||||
void main() {
|
||||
// refactor into an AbstractLlamaGreetingFactory?
|
||||
// TODO: refactor into an AbstractLlamaGreetingFactory?
|
||||
print('Welcome to my Llama farm!');
|
||||
}
|
||||
```
|
||||
|
|
11
technology/libvirt.md
Normal file
11
technology/libvirt.md
Normal file
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
obj: application
|
||||
repo: https://gitlab.com/libvirt
|
||||
website: https://libvirt.org
|
||||
arch-wiki: https://wiki.archlinux.org/title/Libvirt
|
||||
---
|
||||
|
||||
# libvirt
|
||||
#wip
|
||||
|
||||
libvirt has a GUI frontend with [virt-manager](./applications/utilities/virt-manager.md).
|
|
@ -17,4 +17,4 @@ Proxmox Virtual Environment (Proxmox VE) is an open-source virtualization platfo
|
|||
### 4. **Storage Options:**
|
||||
- Proxmox VE offers various storage options, including local storage, networked storage (Ceph, NFS, iSCSI), and [ZFS](filesystems/ZFS.md) (Zettabyte File System) support. This allows users to choose the storage solution that best fits their requirements.
|
||||
### 5. **Backup and Restore:**
|
||||
- The built-in backup and restore features simplify data protection in Proxmox VE. Users can create scheduled backups of VMs and containers, allowing for quick recovery in case of data loss or system failures.
|
||||
- The built-in backup and restore features simplify data protection in Proxmox VE. Users can create scheduled backups of VMs and containers, allowing for quick recovery in case of data loss or system failures.
|
||||
|
|
|
@ -1,74 +0,0 @@
|
|||
---
|
||||
obj: concept
|
||||
arch-wiki: https://wiki.archlinux.org/title/XDG_user_directories
|
||||
rev: 2025-01-08
|
||||
---
|
||||
|
||||
# XDG Directories
|
||||
The XDG User Directories are a standardized way to define and access common user directories in Unix-like operating systems, primarily defined by the XDG Base Directory Specification from the FreeDesktop.org project.
|
||||
|
||||
These directories provide users and applications with predefined paths for storing specific types of files, such as documents, downloads, music, and more. By using these directories, applications can integrate better with the operating system's file structure and provide a consistent experience for users.
|
||||
|
||||
## Creating default directories
|
||||
Creating a full suite of localized default user directories within the `$HOME` directory can be done automatically by running:
|
||||
|
||||
```sh
|
||||
xdg-user-dirs-update
|
||||
```
|
||||
|
||||
> **Tip**: To force the creation of English-named directories, `LC_ALL=C.UTF-8 xdg-user-dirs-update --force` can be used.
|
||||
|
||||
When executed, it will also automatically:
|
||||
- Create a local `~/.config/user-dirs.dirs` configuration file: used by applications to find and use home directories specific to an account.
|
||||
- Create a local `~/.config/user-dirs.locale` configuration file: used to set the language according to the locale in use.
|
||||
|
||||
The user service `xdg-user-dirs-update.service` will also be installed and enabled by default, in order to keep your directories up to date by running this command at the beginning of each login session.
|
||||
|
||||
## Creating custom directories
|
||||
Both the local `~/.config/user-dirs.dirs` and global `/etc/xdg/user-dirs.defaults` configuration files use the following environmental variable format to point to user directories: `XDG_DIRNAME_DIR="$HOME/directory_name"` An example configuration file may likely look like this (these are all the template directories):
|
||||
|
||||
```sh
|
||||
# ~/.config/user-dirs.dirs
|
||||
|
||||
XDG_DESKTOP_DIR="$HOME/Desktop"
|
||||
XDG_DOCUMENTS_DIR="$HOME/Documents"
|
||||
XDG_DOWNLOAD_DIR="$HOME/Downloads"
|
||||
XDG_MUSIC_DIR="$HOME/Music"
|
||||
XDG_PICTURES_DIR="$HOME/Pictures"
|
||||
XDG_PUBLICSHARE_DIR="$HOME/Public"
|
||||
XDG_TEMPLATES_DIR="$HOME/Templates"
|
||||
XDG_VIDEOS_DIR="$HOME/Videos"
|
||||
```
|
||||
|
||||
As xdg-user-dirs will source the local configuration file to point to the appropriate user directories, it is therefore possible to specify custom folders. For example, if a custom folder for the `XDG_DOWNLOAD_DIR` variable has named `$HOME/Internet` in `~/.config/user-dirs.dirs` any application that uses this variable will use this directory.
|
||||
|
||||
> **Note**: Like with many configuration files, local settings override global settings. It will also be necessary to create any new custom directories.
|
||||
|
||||
Alternatively, it is also possible to specify custom folders using the command line. For example, the following command will produce the same results as the above configuration file edit:
|
||||
|
||||
```sh
|
||||
xdg-user-dirs-update --set DOWNLOAD ~/Internet
|
||||
```
|
||||
|
||||
## Querying configured directories
|
||||
Once set, any user directory can be viewed with xdg-user-dirs. For example, the following command will show the location of the Templates directory, which of course corresponds to the `XDG_TEMPLATES_DIR` variable in the local configuration file:
|
||||
|
||||
```sh
|
||||
xdg-user-dir TEMPLATES
|
||||
```
|
||||
|
||||
## Specification
|
||||
Please read the full specification. This section will attempt to break down the essence of what it tries to achieve.
|
||||
|
||||
Only `XDG_RUNTIME_DIR` is set by default through `pam_systemd`. It is up to the user to explicitly define the other variables according to the specification.
|
||||
|
||||
### User directories
|
||||
- `XDG_CONFIG_HOME`: Where user-specific configurations should be written (analogous to `/etc`). Should default to `$HOME/.config`.
|
||||
- `XDG_CACHE_HOME`: Where user-specific non-essential (cached) data should be written (analogous to `/var/cache`). Should default to `$HOME/.cache`.
|
||||
- `XDG_DATA_HOME`: Where user-specific data files should be written (analogous to `/usr/share`). Should default to `$HOME/.local/share`.
|
||||
- `XDG_STATE_HOME`: Where user-specific state files should be written (analogous to `/var/lib`). Should default to `$HOME/.local/state`.
|
||||
- `XDG_RUNTIME_DIR`: Used for non-essential, user-specific data files such as sockets, named pipes, etc. Not required to have a default value; warnings should be issued if not set or equivalents provided. Must be owned by the user with an access mode of `0700`. Filesystem fully featured by standards of OS. Must be on the local filesystem. May be subject to periodic cleanup. Modified every 6 hours or set sticky bit if persistence is desired. Can only exist for the duration of the user's login. Should not store large files as it may be mounted as a tmpfs.`pam_systemd` sets this to `/run/user/$UID`.
|
||||
|
||||
### System directories
|
||||
- `XDG_DATA_DIRS`: List of directories separated by `:` (analogous to `PATH`). Should default to `/usr/local/share:/usr/share`.
|
||||
- `XDG_CONFIG_DIRS`: List of directories separated by `:` (analogous to `PATH`). Should default to `/etc/xdg`.
|
|
@ -5,6 +5,8 @@ repo: https://github.com/qemu/qemu
|
|||
rev: 2024-05-02
|
||||
---
|
||||
|
||||
#refactor -> https://wiki.archlinux.org/title/QEMU
|
||||
|
||||
# QEMU
|
||||
QEMU is an open-source emulator and virtualizer that enables running operating systems and various software applications on different hardware architectures. It supports [emulation](../emulation/Emulation.md) of various CPU architectures, including x86, ARM, PowerPC, and SPARC, among others. It allows running [virtual machines](../tools/Virtual%20Machine.md).
|
||||
|
||||
|
|
|
@ -3,6 +3,7 @@ aliases: ["VM"]
|
|||
obj: concept
|
||||
wiki: https://en.wikipedia.org/wiki/Virtual_machine
|
||||
---
|
||||
|
||||
# Virtual Machine
|
||||
In computing, a virtual machine (VM) is the virtualization or [emulation](../emulation/Emulation.md) of a computer system. Virtual machines are based on computer architectures and provide the functionality of a physical computer.
|
||||
|
||||
|
@ -10,4 +11,5 @@ Virtual Machine can be used to run operating systems in an isolated environment.
|
|||
|
||||
## Virtual Machine Software
|
||||
- [qemu](../linux/qemu.md)
|
||||
- [Proxmox](../linux/Proxmox.md)
|
||||
- [Proxmox](../linux/Proxmox.md)
|
||||
- [libvirt](../libvirt.md)
|
||||
|
|
Loading…
Add table
Reference in a new issue