mirror of
https://github.com/arcan1s/ahriman.git
synced 2025-06-28 14:51:43 +00:00
documentation update
This commit is contained in:
3261
docs/ahriman-architecture.svg
Normal file
3261
docs/ahriman-architecture.svg
Normal file
File diff suppressed because it is too large
Load Diff
After Width: | Height: | Size: 283 KiB |
157
docs/architecture.md
Normal file
157
docs/architecture.md
Normal file
@ -0,0 +1,157 @@
|
||||
# Package structure
|
||||
|
||||
Packages have strict rules of importing:
|
||||
|
||||
* `ahriman.application` package must not be used anywhere except for itself.
|
||||
* `ahriman.core` and `ahriman.models` packages don't have any import restriction. Actually we would like to totally restrict importing of `core` package from `models`, but it is impossible at the moment.
|
||||
* `ahriman.web` package is allowed to be imported from `ahriman.application` (web handler only, only `ahriman.web.web` methods). It also must not be imported globally, only local import is allowed.
|
||||
|
||||
Full dependency diagram:
|
||||
|
||||

|
||||
|
||||
## `ahriman.application` package
|
||||
|
||||
This package contains application (aka executable) related classes and everything for that. It also contains package called `ahriman.application.handlers` in which all available subcommands are described as separated classes derived from base `ahriman.application.handlers.handler.Handler` class. `ahriman.application.ahriman` contains only command line parses and executes specified `Handler` on success, `ahriman.application.application.Application` is a god class which provides interfaces for all repository related actions. `ahriman.application.lock.Lock` is additional class which provides file-based lock and also performs some common checks.
|
||||
|
||||
## `ahriman.core` package
|
||||
|
||||
This package contains everything which is required for any time of application run and separated to several packages:
|
||||
|
||||
* `ahriman.core.alpm` package controls pacman related functions. It provides wrappers for `pyalpm` library and safe calls for repository tools (`repo-add` and `repo-remove`).
|
||||
* `ahriman.core.auth` package provides classes for authorization methods used by web mostly. Base class is `ahriman.core.auth.auth.Auth` which must be called by `load` method.
|
||||
* `ahriman.core.build_tools` is a package which provides wrapper for `devtools` commands.
|
||||
* `ahriman.core.report` is a package with reporting classes. Usually it must be called by `ahriman.core.report.report.Report.load` method.
|
||||
* `ahriman.core.repository` contains several traits and base repository (`ahriman.core.repository.repository.Repository` class) implementation.
|
||||
* `ahriman.core.sign` package provides sign feature (only gpg calls are available).
|
||||
* `ahriman.core.status` contains helpers and watcher class which are required for web application. Reporter must be initialized by using `ahriman.core.status.client.Client.load` method.
|
||||
* `ahriman.core.upload` package provides sync feature, must be called by `ahriman.core.upload.upload.Upload.load` method.
|
||||
|
||||
This package also provides some generic functions and classes which may be used by other packages:
|
||||
|
||||
* `ahriman.core.configuration.Configuration` is an extension for standard `configparser` library.
|
||||
* `ahriman.core.exceptions` provides custom exceptions.
|
||||
* `ahriman.core.spawn.Spawn` is a tool which can spawn another `ahriman` process. This feature is used by web application.
|
||||
* `ahriman.core.tree` is a dependency tree implementation.
|
||||
|
||||
## `ahriman.models` package
|
||||
|
||||
It provides models for any other part of application. Unlike `ahriman.core` package classes from here provides only conversion methods (e.g. create class from another or convert to). Mostly case classes and enumerations.
|
||||
|
||||
## `ahriman.web` package
|
||||
|
||||
Web application. It is important that this package is isolated from any other to allow it to be optional feature (i.e. dependencies which are required by the package are optional).
|
||||
|
||||
* `ahriman.web.middlewares` provides middlewares for request handlers.
|
||||
* `ahriman.web.views` contains web views derived from aiohttp view class.
|
||||
* `ahriman.web.routes` creates routes for web application.
|
||||
* `ahriman.web.web` provides main web application functions (e.g. start, initialization).
|
||||
|
||||
# Application run
|
||||
|
||||
* Parse command line arguments, find command and related handler which is set by parser.
|
||||
* Call `Handler.execute` method.
|
||||
* Define list of architectures to run. In case if there is more than one architecture specified run several subprocesses or process in current process otherwise. Class attribute `ALLOW_MULTI_ARCHITECTURE_RUN` controls whether application can be run in multiple processes or not - this feature is required for some handlers (e.g. `Web`) which should be able to spawn child process in daemon mode (it is impossible to do for daemonic processes).
|
||||
* In each child process call lock functions.
|
||||
* After success checks pass control to `Handler.run` method defined by specific handler class.
|
||||
* Return result (success or failure) of each subprocess and exit from application.
|
||||
|
||||
In most cases handlers spawn god class `ahriman.application.application.Application` class and call required methods.
|
||||
|
||||
Application is designed to run from `systemd` services and provides parametrized by architecture timer and service file for that.
|
||||
|
||||
# Basic flows
|
||||
|
||||
## Add new packages or rebuild existing
|
||||
|
||||
Idea is to copy package to the directory from which it will be handled at the next update run. Different variants are supported:
|
||||
|
||||
* If supplied argument is file then application moves the file to the directory with built packages. Same rule applies for directory, but in this case it copies every package-like file from the specified directory.
|
||||
* If supplied argument iis not file then application tries to lookup for the specified name in AUR and clones it into the directory with manual updates. This scenario can also handle package dependencies which are missing in repositories.
|
||||
|
||||
## Rebuild packages
|
||||
|
||||
Same as add function for every package in repository. Optional filter by reverse dependency can be supplied.
|
||||
|
||||
## Remove packages
|
||||
|
||||
This flow removes package from filesystem, updates repository database and also runs synchronization and reporting methods.
|
||||
|
||||
## Update packages
|
||||
|
||||
This feature is divided into to stages: check AUR for updates and run rebuild for required packages. Whereas check does not do anything except for check itself, update flow is the following:
|
||||
|
||||
1. Process every built package first. Those packages are usually added manually.
|
||||
2. Run sync and report methods.
|
||||
3. Generate dependency tree for packages to be built.
|
||||
4. For each level of tree it does:
|
||||
1. Download package data from AUR.
|
||||
2. Build every package in clean chroot.
|
||||
3. Sign packages if required.
|
||||
4. Add packages to database and sign database if required.
|
||||
5. Process sync and report methods.
|
||||
|
||||
After any step any package data is being removed.
|
||||
|
||||
# Core functions reference
|
||||
|
||||
## Configuration
|
||||
|
||||
`ahriman.core.configuration.Configuration` class provides some additional methods (e.g. `getpath` and `getlist`) and also combines multiple files into single configuration dictionary using architecture overrides. It is recommended to read class related settings from the class, not outside.
|
||||
|
||||
## Utils
|
||||
|
||||
For every external command run (which is actually not recommended if possible) custom wrapper for `subprocess` is used. Additional functions `ahriman.core.auth.helpers` provide safe calls for `aiohttp_security` methods and are required to make this dependency optional.
|
||||
|
||||
## Submodules
|
||||
|
||||
Some packages provide different behaviour depending on configuration settings. In this cases inheritance is used and recommended way to deal with them is to call class method `load` from base classes.
|
||||
|
||||
## Additional features
|
||||
|
||||
Some features require optional dependencies to be installed:
|
||||
|
||||
* Version control executables (e.g. `git`, `svn`) for VCS packages.
|
||||
* `gnupg` application for package and repository sign feature.
|
||||
* `rsync` application for rsync based repository sync.
|
||||
* `boto3` python package for `S3` sync.
|
||||
* `Jinja2` python package for HTML report generation (it is also used by web application).
|
||||
|
||||
# Web application
|
||||
|
||||
Web application requires the following python packages to be installed:
|
||||
|
||||
* Core part requires `aiohttp` (application itself), `aiohttp_jinja2` and `Jinja2` (HTML generation from templates).
|
||||
* In addition authorization feature requires `aiohttp_security`, `aiohttp_session` and `cryptography`.
|
||||
|
||||
## Middlewares
|
||||
|
||||
Service provides some custom middlewares, e.g. logging every exception (except for user ones) and user authorization.
|
||||
|
||||
## Web views
|
||||
|
||||
All web views are defined in separated package and derived from `ahriman.web.views.base.Base` class which provides typed interfaces for web application.
|
||||
|
||||
REST API supports both form and JSON data, but the last one is recommended.
|
||||
|
||||
Different APIs are separated into different packages:
|
||||
|
||||
* `ahriman.web.views.service` provides views for application controls.
|
||||
* `ahriman.web.views.status` package provides REST API for application reporting.
|
||||
* `ahriman.web.views.user` package provides login and logout methods which can be called without authorization.
|
||||
|
||||
## Templating
|
||||
|
||||
Package provides base jinja templates which can be overridden by settings. Vanilla templates are actively using bootstrap library.
|
||||
|
||||
## Requests and scopes
|
||||
|
||||
Service provides optional authorization which can be turned on in settings. In order to control user access there are two levels of authorization - read-only (only GET-like requests) and write (anything).
|
||||
|
||||
If this feature is configured any request except for whitelisted will be prohibited without authentication. In addition, configuration flag `auth.allow_read_only` can be used in order to allow seeing main page without authorization (this page is in default white list).
|
||||
|
||||
For authorized users it uses encrypted session cookies to store tokens; encryption key is generated each time at the start of the application.
|
||||
|
||||
## External calls
|
||||
|
||||
Web application provides external calls to control main service. It spawns child process with specific arguments and waits for its termination. This feature must be used either with authorization or in safe (i.e. when status page is not available world-wide) environment.
|
128
docs/configuration.md
Normal file
128
docs/configuration.md
Normal file
@ -0,0 +1,128 @@
|
||||
# ahriman configuration
|
||||
|
||||
Some groups can be specified for each architecture separately. E.g. if there are `build` and `build:x86_64` groups it will use the option from `build:x86_64` for the `x86_64` architecture and `build` for any other (architecture specific group has higher priority). In case if both groups are presented, architecture specific options will be merged into global ones overriding them.
|
||||
|
||||
## `settings` group
|
||||
|
||||
Base configuration settings.
|
||||
|
||||
* `include` - path to directory with configuration files overrides, string, required.
|
||||
* `logging` - path to logging configuration, string, required. Check `logging.ini` for reference.
|
||||
|
||||
## `alpm` group
|
||||
|
||||
libalpm and AUR related configuration.
|
||||
|
||||
* `aur_url` - base url for AUR, string, required.
|
||||
* `database` - path to pacman local database cache, string, required.
|
||||
* `repositories` - list of pacman repositories, space separated list of strings, required.
|
||||
* `root` - root for alpm library, string, required.
|
||||
|
||||
## `auth` group
|
||||
|
||||
Base authorization settings.
|
||||
|
||||
* `target` - specifies authorization provider, string, optional, default `disabled`. Allowed values are `disabled`, `configuration`.
|
||||
* `allow_read_only` - allow requesting read only pages without authorization, boolean, required.
|
||||
* `allowed_paths` - URI paths (exact match) which can be accessed without authorization, space separated list of strings, optional.
|
||||
* `allowed_paths_groups` - URI paths prefixes which can be accessed without authorization, space separated list of strings, optional.
|
||||
* `salt` - password hash salt, string, required in case if authorization enabled (automatically generated by `create-user` subcommand).
|
||||
|
||||
## `auth:*` groups
|
||||
|
||||
Authorization mapping. Group name must refer to user access level, i.e. it should be one of `auth:status` (internal API usage only), `auth:read` (read hidden pages), `auth:write` (everything is allowed).
|
||||
|
||||
Key is always username (case-insensitive), option value depends on authorization provider:
|
||||
|
||||
* `MappingAuth` (default) - reads salted password hashes from values, uses SHA512 in order to hash passwords. Password can be set by using `create-user` subcommand.
|
||||
|
||||
## `build:*` groups
|
||||
|
||||
Build related configuration. Group name must refer to architecture, e.g. it should be `build:x86_64` for x86_64 architecture.
|
||||
|
||||
* `archbuild_flags` - additional flags passed to `archbuild` command, space separated list of strings, optional.
|
||||
* `build_command` - default build command, string, required.
|
||||
* `ignore_packages` - list packages to ignore during a regular update (manual update will still work), space separated list of strings, optional.
|
||||
* `makepkg_flags` - additional flags passed to `makepkg` command, space separated list of strings, optional.
|
||||
* `makechrootpkg_flags` - additional flags passed to `makechrootpkg` command, space separated list of strings, optional.
|
||||
|
||||
## `repository` group
|
||||
|
||||
Base repository settings.
|
||||
|
||||
* `name` - repository name, string, required.
|
||||
* `root` - root path for application, string, required.
|
||||
|
||||
## `sign:*` groups
|
||||
|
||||
Settings for signing packages or repository. Group name must refer to architecture, e.g. it should be `sign:x86_64` for x86_64 architecture.
|
||||
|
||||
* `target` - configuration flag to enable signing, space separated list of strings, required. Allowed values are `package` (sign each package separately), `repository` (sign repository database file).
|
||||
* `key` - default PGP key, string, required. This key will also be used for database signing if enabled.
|
||||
* `key_*` settings - PGP key which will be used for specific packages, string, optional. For example, if there is `key_yay` option the specified key will be used for yay package and default key for others.
|
||||
|
||||
## `report` group
|
||||
|
||||
Report generation settings.
|
||||
|
||||
* `target` - list of reports to be generated, space separated list of strings, optional. Allowed values are `html`, `email`.
|
||||
|
||||
### `email:*` groups
|
||||
|
||||
Group name must refer to architecture, e.g. it should be `email:x86_64` for x86_64 architecture.
|
||||
|
||||
* `full_template_path` - path to Jinja2 template for full package description index, string, optional.
|
||||
* `homepage` - link to homepage, string, optional.
|
||||
* `host` - SMTP host for sending emails, string, required.
|
||||
* `link_path` - prefix for HTML links, string, required.
|
||||
* `no_empty_report` - skip report generation for empty packages list, boolean, optional, default `yes`.
|
||||
* `password` - SMTP password to authenticate, string, optional.
|
||||
* `port` - SMTP port for sending emails, int, required.
|
||||
* `receivers` - SMTP receiver addresses, space separated list of strings, required.
|
||||
* `sender` - SMTP sender address, string, required.
|
||||
* `ssl` - SSL mode for SMTP connection, one of `ssl`, `starttls`, `disabled`, optional, default `disabled`.
|
||||
* `template_path` - path to Jinja2 template, string, required.
|
||||
* `user` - SMTP user to authenticate, string, optional.
|
||||
|
||||
### `html:*` groups
|
||||
|
||||
Group name must refer to architecture, e.g. it should be `html:x86_64` for x86_64 architecture.
|
||||
|
||||
* `path` - path to html report file, string, required.
|
||||
* `homepage` - link to homepage, string, optional.
|
||||
* `link_path` - prefix for HTML links, string, required.
|
||||
* `template_path` - path to Jinja2 template, string, required.
|
||||
|
||||
## `upload` group
|
||||
|
||||
Remote synchronization settings.
|
||||
|
||||
* `target` - list of synchronizations to be used, space separated list of strings, optional. Allowed values are `rsync`, `s3`.
|
||||
|
||||
### `rsync:*` groups
|
||||
|
||||
Group name must refer to architecture, e.g. it should be `rsync:x86_64` for x86_64 architecture. Requires `rsync` package to be installed. Do not forget to configure ssh for user `ahriman`.
|
||||
|
||||
* `command` - rsync command to run, space separated list of string, required.
|
||||
* `remote` - remote server to rsync (e.g. `1.2.3.4:5678:path/to/sync`), string, required.
|
||||
|
||||
### `s3:*` groups
|
||||
|
||||
Group name must refer to architecture, e.g. it should be `s3:x86_64` for x86_64 architecture.
|
||||
|
||||
* `access_key` - AWS access key ID, string, required.
|
||||
* `bucket` - bucket name (e.g. `bucket`), string, required.
|
||||
* `chunk_size` - chunk size for calculating entity tags, int, optional, default 8 * 1024 * 1024.
|
||||
* `region` - bucket region (e.g. `eu-central-1`), string, required.
|
||||
* `secret_key` - AWS secret access key, string, required.
|
||||
|
||||
## `web:*` groups
|
||||
|
||||
Web server settings. If any of `host`/`port` is not set, web integration will be disabled. Group name must refer to architecture, e.g. it should be `web:x86_64` for x86_64 architecture.
|
||||
|
||||
* `address` - optional address in form `proto://host:port` (`port` can be omitted in case of default `proto` ports), will be used instead of `http://{host}:{port}` in case if set, string, optional.
|
||||
* `host` - host to bind, string, optional.
|
||||
* `password` - password to authorize in web service in order to update service status, string, required in case if authorization enabled.
|
||||
* `port` - port to bind, int, optional.
|
||||
* `templates` - path to templates directory, string, required.
|
||||
* `username` - username to authorize in web service in order to update service status, string, required in case if authorization enabled.
|
60
docs/setup.md
Normal file
60
docs/setup.md
Normal file
@ -0,0 +1,60 @@
|
||||
# Setup instructions
|
||||
|
||||
1. Install package as usual.
|
||||
2. Change settings if required, see [configuration reference](configuration.md) for more details.
|
||||
3. Create `/var/lib/ahriman/.makepkg.conf` with `makepkg.conf` overrides if required (at least you might want to set `PACKAGER`):
|
||||
|
||||
```shell
|
||||
echo 'PACKAGER="John Doe <john@doe.com>"' | sudo -u ahriman tee -a /var/lib/ahriman/.makepkg.conf
|
||||
```
|
||||
|
||||
4. Configure build tools (it is required for correct dependency management system):
|
||||
|
||||
1. Create build command, e.g. `ln -s /usr/bin/archbuild /usr/local/bin/ahriman-x86_64-build` (you can choose any name for command, basically it should be `{name}-{arch}-build`).
|
||||
2. Create configuration file, e.g. `cp /usr/share/devtools/pacman-{extra,ahriman}.conf` (same as previous `pacman-{name}.conf`).
|
||||
3. Change configuration file, add your own repository, add multilib repository etc;
|
||||
4. Set `build_command` option to point to your command.
|
||||
5. Configure `/etc/sudoers.d/ahriman` to allow running command without a password.
|
||||
|
||||
```shell
|
||||
ln -s /usr/bin/archbuild /usr/local/bin/ahriman-x86_64-build
|
||||
cp /usr/share/devtools/pacman-{extra,ahriman}.conf
|
||||
|
||||
echo '[multilib]' | tee -a /usr/share/devtools/pacman-ahriman.conf
|
||||
echo 'Include = /etc/pacman.d/mirrorlist' | tee -a /usr/share/devtools/pacman-ahriman.conf
|
||||
|
||||
echo '[aur-clone]' | tee -a /usr/share/devtools/pacman-ahriman.conf
|
||||
echo 'SigLevel = Optional TrustAll' | tee -a /usr/share/devtools/pacman-ahriman.conf
|
||||
echo 'Server = file:///var/lib/ahriman/repository/$arch' | tee -a /usr/share/devtools/pacman-ahriman.conf
|
||||
|
||||
echo '[build]' | tee -a /etc/ahriman.ini.d/build.ini
|
||||
echo 'build_command = ahriman-x86_64-build' | tee -a /etc/ahriman.ini.d/build.ini
|
||||
|
||||
echo 'Cmnd_Alias CARCHBUILD_CMD = /usr/local/bin/ahriman-x86_64-build *' | tee -a /etc/sudoers.d/ahriman
|
||||
echo 'ahriman ALL=(ALL) NOPASSWD: CARCHBUILD_CMD' | tee -a /etc/sudoers.d/ahriman
|
||||
chmod 400 /etc/sudoers.d/ahriman
|
||||
```
|
||||
|
||||
5. Start and enable `ahriman@.timer` via `systemctl`:
|
||||
|
||||
```shell
|
||||
systemctl enable --now ahriman@x86_64.timer
|
||||
```
|
||||
|
||||
6. Start and enable status page:
|
||||
|
||||
```shell
|
||||
systemctl enable --now ahriman-web@x86_64
|
||||
```
|
||||
|
||||
7. Add packages by using `ahriman add {package}` command:
|
||||
|
||||
```shell
|
||||
sudo -u ahriman ahriman -a x86_64 add yay --now
|
||||
```
|
||||
|
||||
Note that initial service configuration can be done by running `ahriman setup` with specific arguments.
|
||||
|
||||
## User creation
|
||||
|
||||
`create-user` subcommand is recommended for new user creation.
|
Reference in New Issue
Block a user