refactor
This commit is contained in:
parent
d34c642377
commit
e851e2de48
GPG key ID:
901B2ADDF27C2263
5 changed files with 145 additions and 5 deletions
|
|
@ -79,6 +79,24 @@ proxy_service:
|
|||
--token=/path/to/token.file \
|
||||
--proxy=tele.example.com:443
|
||||
```
|
||||
4. Enable Teleport Service
|
||||
```shell
|
||||
[Unit]
|
||||
Description=Teleport Service
|
||||
After=network.target
|
||||
|
||||
[Service]
|
||||
Type=simple
|
||||
Restart=on-failure
|
||||
EnvironmentFile=-/etc/default/teleport
|
||||
ExecStart=/usr/local/bin/teleport start --config /etc/teleport.yaml --pid-file=/run/teleport.pid
|
||||
ExecReload=/bin/kill -HUP $MAINPID
|
||||
PIDFile=/run/teleport.pid
|
||||
LimitNOFILE=524288
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
|
||||
## `tctl`
|
||||
|
|
|
|||
114
technology/applications/package managers/APKBUILD.md
Normal file
114
technology/applications/package managers/APKBUILD.md
Normal file
|
|
@ -0,0 +1,114 @@
|
|||
---
|
||||
obj: concept
|
||||
source: https://wiki.alpinelinux.org/wiki/APKBUILD_Reference
|
||||
---
|
||||
|
||||
# APKBUILD
|
||||
APKBUILDs are the scripts that are created in order to build [Alpine Packages](Alpine%20Package.md) using the abuild tool on [Alpine Linux](../../linux/Alpine%20Linux.md).
|
||||
|
||||
## abuild-defined variables
|
||||
The following variables are defined by abuild:
|
||||
- `startdir` : The directory where the APKBUILD script is.
|
||||
- `srcdir` : The directory where sources, from the source variable, are downloaded to and unpacked to.
|
||||
- `pkgdir` : This directory should receive the files for the main package. For example, a normal autotools package would have make DESTDIR="$pkgdir" install in the `package()` function.
|
||||
- `subpkgdir` : This directory should receive the files for a subpackage. This variable should only be used from subpackage functions.
|
||||
- `builddir` : This variable should point to the directory inside the `srcdir` where the main package source is unpacked. This is typically `$srcdir/$pkgname-$pkgver`. It’s used by the default `prepare()` function as a working directory when applying patches.
|
||||
|
||||
## User-defined variables
|
||||
|
||||
The following variables should be defined by the user:
|
||||
- `Maintainer` : Name and email address of the maintainer of the project (not your package). A well-formatted example is `# Maintainer: John Snow <john_snow@thewall.net>`
|
||||
- `arch` : Package architecture(s) to build for. Can be one or several seperated by whitespace of: x86, x86_64, armv7, armhf, aarch64, ppc64le, s390x, riscv64, all, or noarch, where all means all architectures, and noarch means it's architecture-independent (e.g., a pure-python package). Architectures can be negated using the ! character to exclude them from the list of supported architectures. E.g. arch="all !ppc64le" means that the package is allowed to be built on all architectures but the ppc64le architecture.
|
||||
- `depends` : Run-time dependency package(s) that are not shared-object dependencies. Shared objects dependencies are auto-detected and should not be specified here. To specify a conflicting package, add the package name prefixed with a '!'.
|
||||
- `depends_dev` : Run-time dependency package(s) for the `$pkgname-dev` subpackage.
|
||||
- `depends_doc` : Run-time dependency package(s) for the `$pkgname-doc` subpackage.
|
||||
- `depends_openrc` : Run-time dependency package(s) for the `$pkgname-openrc` subpackage.
|
||||
- `depends_libs` : Run-time dependency package(s) for the `$pkgname-libs` subpackage.
|
||||
- `depends_static` : Run-time dependency package(s) for the `$pkgname-static` subpackage.
|
||||
- `checkdepends` : Dependencies that are only required during the check phase, they are only installed if the check option is enabled
|
||||
- `giturl` : [Git](../../dev/Git.md) repository from which abuild checkout checks out. You can checkout a specific branch in [git](../../dev/Git.md) by adding `-b $branch`.
|
||||
- `install` : There are 6 different types of install scripts. Install scripts are named `$pkgname.action`, where action can be: `pre-install`, `post-install`, `pre-upgrade`, `post-upgrade`, `pre-deinstall`, or `post-deinstall`. For example, if `pkgname` is set to mypackage and install is set to `$pkgname.post-install`, then a script named `mypackage.post-install` must exist along-side the APKBUILD.
|
||||
- `$pkgname.pre-install` : This script is executed before installing the package. Typical use is when the package needs a group and a user to be created.
|
||||
- `$pkgname.post-install` : This script is executed after installing the package.
|
||||
- `$pkgname.pre-upgrade` : This script is executed before upgrading/downgrading/reinstalling the package. Note that exiting with failure will not cause [apk](apk.md) to exit with failure, but will mark the package as broken.
|
||||
- `$pkgname.post-upgrade` : This script is executed after upgrading/downgrading/reinstalling the package.
|
||||
- `$pkgname.pre-deinstall` : This script is executed before uninstalling the package.
|
||||
- `$pkgname.post-deinstall` : This script is executed after uninstalling the package.
|
||||
- `install_if` : `install_if` can be used when a package needs to be installed when some packages are already installed or are in the dependency tree. It works in reverse to the recommends feature, that other package managers provide.
|
||||
- `license` : License(s) for the package, for example GPL-3.0-or-later, BSD-2-Clause or MIT (details).
|
||||
- `makedepends` : Build-time dependency package(s).
|
||||
- `md5sums/sha256sums/sha512sums` : Checksums for the files/URLs listed in source. The checksums are normally generated and updated by executing `abuild checksum` and should be the last item in the APKBUILD.
|
||||
- `options` : Build-time options for the package.
|
||||
|
||||
| Option | Description |
|
||||
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `!archcheck` | Do not try to verify that the architecture of the binary files is the same architecture as abuild should build for. One example where it makes sense to set this are packages with firmware files, that get executed on another CPU (such as WiFi firmware). |
|
||||
| `!check` | Do not try to run the `check()` function. Please always add a short comment after the `!check` about why it's disabled. Creating a very simple check function, that calls `program --version` is worse than disabling tests completely because it gives the false impression that the package is thoroughly tested with the testsuite from upstream. |
|
||||
| `checkroot` | Specifies that the package's test suite will be run in _fakeroot_. This is necessary for some test suites which fail when run as non-root. |
|
||||
| `net` | Allows network access when run in _rootbld_. |
|
||||
| `!strip` | Avoid stripping symbols from binaries. |
|
||||
| `suid` | Allow setuid binaries. |
|
||||
| `!tracedeps` | Do not automatically find dependencies (e.g. by using `ldd` to find dynamic libraries, which the resulting binary links against). |
|
||||
| `chmod-clean` | Make all files writable in the src/ directory. Useful for packages that make files read-only in the process of building packages (go modules). |
|
||||
| `toolchain` | Don't warn when g++ is in makedepends |
|
||||
| `!dbg` | Don't create debugging subpackage |
|
||||
| `ldpath-recursive` | Scan directories recursively when creating .so providers |
|
||||
| `!spdx` | Do not check if the license= field has a SPDX compliant license |
|
||||
| `textrels` | Don't error out when text relocations are found |
|
||||
| `charset.alias` | Don't error out if `/usr/lib/charset.alias` is found |
|
||||
| `libtool` | Don't delete libtool .la files |
|
||||
| `!fhs` | Don't enforce checks on path that follow the FHS |
|
||||
|
||||
- `pkgdesc` : A brief, one-line description of what the package does.
|
||||
- `pkggroups` : System group(s) to be created during build-time. System group(s) should also be created in the `$pkgname.pre-install` script, so that the system group(s) are also created prior to package installation for run-time use.
|
||||
- `pkgname` : The name of the package. All letters should be lowercase.
|
||||
- `pkgrel` : [Alpine package](Alpine%20Package.md) release number. Starts at 0 (zero). Always increment pkgrel when making updates to an aport; reset pkgrel to 0 (zero) when incrementing pkgver.
|
||||
- `pkgusers` : System user(s) to be created during build-time. System user(s) should also be created in the `$pkgname.pre-install` script, so that the system user(s) are also created prior to package installation for run-time use.
|
||||
- `pkgver` : The version of the software being packaged. Format for valid versions: `{digit}{.digit}...{letter}{_suf{#}}...{-r#}`. A Suffix suf in the above format can be one of the following to indicate that the release is less recent than the version without the suffix: `alpha`, `beta`, `pre`, `rc`. These are for indicating more recent releases: `cvs`, `svn`, `git`, `hg`, `p`. All other suffices are invalid. To package a specific [git](../../dev/Git.md) commit, the date of the commit gets appended to the latest release, e.g. `1.0.0_git20180204`.
|
||||
- `provides` : List of package names (and optionally version info) this package provides. If package with a version is provided (provides='foo=1.2') [apk](apk.md) will consider it as an alternate name and it will automatically consider the package for installation by the alternate name, and conflict with other packages having the same name, or provides. If version is not provided (provides='foo'), [apk](apk.md) will consider it as virtual package name. Several package with same non-versioned provides can be installed simultaneously. However, none of them will be installed by default when requested by the virtual name - instead, error message is given and user is asked to choose which package providing the virtual name should be installed.
|
||||
- `provider_priority` : A numeric value which is used by apk-tools to break ties when choosing a virtual package to satisfy a dependency. Higher values have higher priority. The primary use case is to specify the primary package that satisfies a virtual (provider).
|
||||
- `replaces` : Allow this package to be installed at the same time as the listed packages, even if they have conflicting files. The files from this package will override ("take over") the conflicting files. This can be used to override config files with "policy packages".Another use case is renaming packages (or moving files from one package to another): "replaces" will avoid the file conflict error that [apk](apk.md) reports if it happens to install the new package before uninstalling the old package. A common misconception is that "replaces" is used to replace packages (like in [PKGBUILD](PKGBUILD.md)). This is not the case, it is only for solving file conflicts. To let [apk](apk.md) consider installing one package instead of another one, refer to provides (with the version).
|
||||
- `replaces_priority` : The priority of the replaces. If multiple packages replace files of each other, then the package with the highest replaces_priority will win.
|
||||
- `source` : The source variable is not only used to list the remote source files to fetch, it is also used to list the local files that abuild will need in order to build the apk. Examples of such local files include: init.d files, conf.d files, install files (see install variable), patches, and all other necessary files.
|
||||
- `triggers` : Apk-tools can "monitor" directories and execute a trigger if any package installed/uninstalled any file in the monitored dir. The triggers are always executed after the [apk](apk.md) action (install, uninstall, upgrade). The triggers are specified in the format: `scriptname=pathlist` where scriptname is the (sub)package name + `.trigger` suffix and pathlist is `:` separated list of the dirs to monitor. The triggers variable must include the triggers for subpackages too if they have any. It is possible to use wildcards (`*`) in the dir list.
|
||||
- `url` : The homepage for the package. This is to help users find upstream documentation and other information regarding the package.
|
||||
|
||||
## Functions
|
||||
```
|
||||
sanitycheck() -> clean()-> fetch() -> verify() -> unpack() -> prepare() -> mkusers() -> build() -> check() -> package() -> subpackages() -> language packs -> apk -> cleanup()
|
||||
```
|
||||
|
||||
### User-defined functions
|
||||
The following functions should be defined by the user:
|
||||
|
||||
- `prepare()`
|
||||
Optional. Used for build preparation: patches, etc, should be applied here. When you don't specify a custom `prepare()`, the built-in `default_prepare()` from abuild will be used. It applies patches already (always prepare them in the -p1 format), so usually it makes sense to not create a custom `prepare()` function at all! If you do create one, call `default_prepare()` inside it:
|
||||
|
||||
```shell
|
||||
prepare() {
|
||||
default_prepare
|
||||
# your custom code here
|
||||
}
|
||||
```
|
||||
|
||||
- `build()`
|
||||
**Required**. This is the compilation stage. This function will be called as the current user (unless the `package()` function is missing - for compatibility reasons). If no compilation is needed, this function can contain a single line: `return 0`
|
||||
|
||||
To enable or disable CFLAGS, CXXFLAGS, CMake with option, or configure option per arch, use the CARCH variable:
|
||||
|
||||
```shell
|
||||
local cmakeoptions=
|
||||
case "$CARCH" in
|
||||
aarch64*|arm*|ppc64le|x86|s390x) cmakeoptions="$cmakeoptions -DWITH_OPENMP=OFF" ;;
|
||||
x86_64) cmakeoptions="$cmakeoptions -DWITH_OPENMP=ON" ;;
|
||||
*) msg "Unable to determine architecture from (CARCH=$CARCH)" ; return 1 ;;
|
||||
esac
|
||||
```
|
||||
|
||||
The block can be used in other parts of the APKBUILD even in global.
|
||||
|
||||
- `check()`
|
||||
Required if functionality exists. This function is called right after the build stage. It should check that the packaged thing is actually working, typically by running (integration) tests, if provided by upstream. If there’s no (easy) way how to test the package, you can declare that it does not want to use `check()` by adding `!check` into the options variable (`options="!check"`).
|
||||
|
||||
- `package()`
|
||||
**Required**. This is the packaging stage. Here, the built application and support files should be installed into `$pkgdir`. If this is a metapackage, this function can contain a single line: `mkdir -p "$pkgdir"`
|
||||
|
|
@ -3,11 +3,11 @@ arch-wiki: https://wiki.archlinux.org/title/PKGBUILD
|
|||
obj: concept
|
||||
---
|
||||
|
||||
A `PKGBUILD` is a shell script containing the build information required by Arch Linux packages. [Arch Wiki](https://wiki.archlinux.org/title/PKGBUILD)
|
||||
A `PKGBUILD` is a shell script containing the build information required by [Arch Linux](../../linux/Arch%20Linux.md) packages. [Arch Wiki](https://wiki.archlinux.org/title/PKGBUILD)
|
||||
|
||||
Packages in Arch Linux are built using the makepkg utility. When makepkg is run, it searches for a PKGBUILD file in the current directory and follows the instructions therein to either compile or otherwise acquire the files to build a package archive (pkgname.pkg.tar.zst). The resulting package contains binary files and installation instructions, readily installable with pacman.
|
||||
Packages in [Arch Linux](../../linux/Arch%20Linux.md) are built using the [makepkg](makepkg.md) utility. When [makepkg](makepkg.md) is run, it searches for a PKGBUILD file in the current directory and follows the instructions therein to either compile or otherwise acquire the files to build a package archive (pkgname.pkg.tar.zst). The resulting package contains binary files and installation instructions, readily installable with [pacman](Pacman.md).
|
||||
|
||||
Mandatory variables are `pkgname`, `pkgver`, `pkgrel`, and `arch`. `license` is not strictly necessary to build a package, but is recommended for any PKGBUILD shared with others, as makepkg will produce a warning if not present.
|
||||
Mandatory variables are `pkgname`, `pkgver`, `pkgrel`, and `arch`. `license` is not strictly necessary to build a package, but is recommended for any PKGBUILD shared with others, as [makepkg](makepkg.md) will produce a warning if not present.
|
||||
|
||||
# Example
|
||||
PKGBUILD:
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ obj: os
|
|||
# Alpine Linux
|
||||
Alpine Linux is a lightweight and secure [Linux](Linux.md) operating system designed for security, simplicity, and resource efficiency. It is particularly popular for use in containerized environments and embedded systems. Alpine does not use [Systemd](Systemd.md), instead it uses [openrc](openrc.md).
|
||||
|
||||
Here are some of the key features of Alpine Linux:
|
||||
Here are some of the features of Alpine Linux:
|
||||
- Lightweight: Alpine Linux is designed to be as small and simple as possible, with a small footprint and minimal dependencies. The base image is typically around 5 MB in size.
|
||||
- Security-focused: Alpine Linux uses the musl libc library and includes security features such as hardened kernel and stack protector. The default package manager, apk, is designed to prevent privilege escalation attacks and is based on signed packages.
|
||||
- Resource-efficient: Alpine Linux is optimized for resource efficiency and can run on low-power devices and in resource-constrained environments.
|
||||
|
|
@ -17,4 +17,10 @@ Here are some of the key features of Alpine Linux:
|
|||
Here are some of the common use cases for Alpine Linux:
|
||||
- Containerized environments: Alpine Linux is widely used as a base image for containerized applications due to its small size and focus on security.
|
||||
- Embedded systems: Alpine Linux is popular for use in embedded systems due to its small size and resource efficiency.
|
||||
- Servers and cloud computing: Alpine Linux is well-suited for use in servers and cloud computing environments due to its lightweight and secure design.
|
||||
- Servers and cloud computing: Alpine Linux is well-suited for use in servers and cloud computing environments due to its lightweight and secure design.
|
||||
|
||||
## libc
|
||||
Since alpine uses musl, applications using libc might not work anymore. Some of them might still run when using this compatibility package:
|
||||
```shell
|
||||
apk add gcompat
|
||||
```
|
||||
|
|
@ -9,6 +9,8 @@ source: https://wiki.alpinelinux.org/wiki/OpenRC
|
|||
# openRC
|
||||
OpenRC is a dependency-based init system that works with the system-provided init program
|
||||
|
||||
Init scripts are located at `/etc/init.d`.
|
||||
|
||||
The following commands are available to manage the init system:
|
||||
|
||||
- Basics:
|
||||
|
|
|
|||
Loading…
Reference in a new issue