@xbrekz

Kaniko

2023-06-29T10:42:56.141Z

https://github.com/GoogleContainerTools/kaniko

https://www.youtube.com/watch?v=EgwVQN6GNJg

Kaniko

2023-06-29T09:43:17.091Z

https://github.com/GoogleContainerTools/kaniko

Шпаргалка по kubectl

2023-06-29T09:19:44.064Z

Контекст и конфигурация kubectl

kubectl config view # показать объединённые настройки kubeconfig

# использовать несколько файлов kubeconfig одновременно и посмотреть объединённую конфигурацию из этих файлов
KUBECONFIG=~/.kube/config:~/.kube/kubconfig2

kubectl config view

# получить пароль для пользователя e2e
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

kubectl config view -o jsonpath='{.users[].name}'    # показать первого пользователя
kubectl config view -o jsonpath='{.users[*].name}'   # получить список пользователей
kubectl config get-contexts                          # показать список контекстов
kubectl config current-context                       # показать текущий контекст (current-context)
kubectl config use-context my-cluster-name           # установить my-cluster-name как контекст по умолчанию

# добавить новую конфигурацию для кластера в kubeconf с базовой аутентификацией
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword

# сохранить пространство имен для всех последующих команд kubectl в этом контексте.
kubectl config set-context --current --namespace=ggckad-s2

# установить контекст, используя имя пользователя и пространство имен.
kubectl config set-context gce --user=cluster-admin --namespace=foo \
  && kubectl config use-context gce

kubectl config unset users.foo                       # удалить пользователя foo

Создание объектов

Манифесты Kubernetes могут быть определены в YAML или JSON. Можно использовать расширение файла .yaml, .yml и .json

kubectl apply -f ./my-manifest.yaml            # создать ресурсы
kubectl apply -f ./my1.yaml -f ./my2.yaml      # создать ресурсы из нескольких файлов
kubectl apply -f ./dir                         # создать ресурсы из всех файлов манифеста в директории
kubectl apply -f https://git.io/vPieo          # создать ресурсы из URL-адреса
kubectl create deployment nginx --image=nginx  # запустить один экземпляр nginx
kubectl explain pods                           # посмотреть документацию по манифестам подов

# Создать несколько YAML-объектов из stdin
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-sleep
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox-sleep-less
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000"
EOF

# Создать секрет с несколькими ключами
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: $(echo -n "s33msi4" | base64 -w0)
  username: $(echo -n "jane" | base64 -w0)
EOF

Просмотр и поиск ресурсов

# Get-команды с основном выводом
kubectl get services                          # Вывести все сервисы в пространстве имён
kubectl get pods --all-namespaces             # Вывести все поды во всех пространств имён
kubectl get pods -o wide                      # Вывести все поды в текущем пространстве имён с подробностями
kubectl get deployment my-dep                 # Вывести определённое развёртывание
kubectl get pods                              # Вывести все поды в пространстве имён
kubectl get pod my-pod -o yaml                # Получить информацию по поду в формате YAML

# Посмотреть дополнительные сведения команды с многословным выводом
kubectl describe nodes my-node
kubectl describe pods my-pod

# Вывести сервисы, отсортированные по имени
kubectl get services --sort-by=.metadata.name

# Вывести поды, отсортированные по количеству перезагрузок
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

# Вывести постоянные тома (PersistentVolumes), отсортированные по емкости
kubectl get pv --sort-by=.spec.capacity.storage

# Получить метку версии всех подов с меткой app=cassandra
kubectl get pods --selector=app=cassandra -o \
  jsonpath='{.items[*].metadata.labels.version}'

# Получить все рабочие узлы (с помощью селектора исключаем узлы с меткой 'node-role.kubernetes.io/master')
kubectl get node --selector='!node-role.kubernetes.io/master'

# Получить все запущенные поды в пространстве имён
kubectl get pods --field-selector=status.phase=Running

# Получить внешние IP-адреса (ExternalIP) всех узлов
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'

# Вывести имена подов, принадлежащие к определённому RC
# Использование команды "jq" помогает упросить поиск в jsonpath, подробнее смотрите на сайте https://stedolan.github.io/jq/
sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})

# Показать метки всех подов (или любого другого объекта Kubernetes, которым можно прикреплять метки)
kubectl get pods --show-labels

# Получить готовые узлы
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
 && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"

# Вывод декодированных секретов без внешних инструментов
kubectl get secret my-secret -o go-template='{{range $k,$v := .data}}{{"### "}}{{$k}}{{"\n"}}{{$v|base64decode}}{{"\n\n"}}{{end}}'

# Вывести все секреты, используемые сейчас в поде.
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq

# Вывести все идентификаторы (containerID) контейнеров инициализации (initContainers) во всех подах.
# Это полезно при очистке остановленных контейнеров, не удаляя при этом контейнеры инициализации.
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3

# Вывести события, отсортированные по временной метке
kubectl get events --sort-by=.metadata.creationTimestamp

# Сравнить текущее состояние кластера с состоянием, в котором находился бы кластер в случае применения манифеста.
kubectl diff -f ./my-manifest.yaml

Обновление ресурсов

kubectl set image deployment/frontend www=image:v2               # Плавающее обновление контейнеров "www" развёртывания "frontend", обновление образа
kubectl rollout history deployment/frontend                      # Проверить историю развёртывания, включая ревизии.
kubectl rollout undo deployment/frontend                         # Откатиться к предыдущему развёртыванию
kubectl rollout undo deployment/frontend --to-revision=2         # Откатиться к определённой ревизии
kubectl rollout status -w deployment/frontend                    # Отслеживать статус плавающего развёртывания "frontend" до его завершения
kubectl rollout restart deployment/frontend                      # Перезапуск плавающего развёртывания "frontend"


# Объявлено устаревшим, начиная с версии 1.11
kubectl rolling-update frontend-v1 -f frontend-v2.json           # (устарело) Плавающее обновление подов frontend-v1
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2  # (устарело) Изменить имя ресурса и обновить образ
kubectl rolling-update frontend --image=image:v2                 # (устарело) Обновить образ подов frontend
kubectl rolling-update frontend-v1 frontend-v2 --rollback        # (устарело) Отменить выполняющееся обновление

cat pod.json | kubectl replace -f -                              # Заменить под из определения в JSON-файле, переданного в поток stdin

# Принудительно заменить, удалить, а затем пересоздать ресурс. Это приведет к простою приложения
kubectl replace --force -f ./pod.json

# Создать сервис с реплицированным nginx на порту 80, который подключается к контейнерам на порту 8000.
kubectl expose rc nginx --port=80 --target-port=8000

# Обновить версию (метку) образа пода из одного контейнера single до v4
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -

kubectl label pods my-pod new-label=awesome                      # Добавить метку
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq       # Добавить аннотацию
kubectl autoscale deployment foo --min=2 --max=10                # Автоматически масштабировать развёртывание "foo" в диапазоне от 2 до 10 подов

Обновление ресурсов

# Обновить часть узла
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'

# Обновить образ контейнера; необходимо указать spec.containers[*].name, чтобы произвести слияние
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'

# Обновить образ контейнера через json-патч с позиционными массивами
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'

# Удалить развертывание livenessProbe через json-патч с позиционными массивами
kubectl patch deployment valid-deployment  --type json   -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'

# Добавить нового элемента в позиционный массив
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'

Редактирование ресурсов

Вы можете отредактировать API-ресурс в любом редакторе.

kubectl edit svc/docker-registry                      # Отредактировать сервис docker-registry
KUBE_EDITOR="nano" kubectl edit svc/docker-registry   # Использовать другой редактор

Масштабирование ресурсов

kubectl scale --replicas=3 rs/foo                                 # Масштабирование набора реплик (replicaset) 'foo' до 3
kubectl scale --replicas=3 -f foo.yaml                            # Масштабирование ресурса в "foo.yaml" до 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql  # Если количество реплик в развёртывании mysql равен 2, масштабировать его до 3
kubectl scale --replicas=5 rc/foo rc/bar rc/baz                   # Масштабирование нескольких контроллеров репликации до 5

Удаление ресурсов

kubectl delete -f ./pod.json                                              # Удалить под по типу и имени в pod.json
kubectl delete pod,service baz foo                                        # Удалить поды и сервисы с одноимёнными именам "baz" и "foo"
kubectl delete pods,services -l name=myLabel                              # Удалить поды и сервисы с именем метки myLabel
kubectl -n my-ns delete pod,svc --all                                     # Удалить все поды и сервисы в пространстве имен my-ns
# Удалить все поды, соответствующие pattern1 или pattern2 в awk
kubectl get pods  -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs  kubectl delete -n mynamespace pod

Работа с запущенными подами

kubectl logs my-pod                                 # вывести логи пода (в stdout)
kubectl logs -l name=myLabel                        # вывести логи пода с меткой myLabel (в stdout)
kubectl logs my-pod --previous                      # вывести логи пода (в stdout) по предыдущему экземпляру контейнера
kubectl logs my-pod -c my-container                 # вывести логи контейнера пода (в stdout, при работе с несколькими контейнерами)
kubectl logs -l name=myLabel -c my-container        # вывести логи пода с меткой myLabel (в stdout)
kubectl logs my-pod -c my-container --previous      # вывести логи контейнера пода (в stdout, при работе с несколькими контейнерами) по предыдущему экземпляру контейнера
kubectl logs -f my-pod                              # вывести логи пода в режиме реального времени (в stdout)
kubectl logs -f my-pod -c my-container              # вывести логи контейнера пода в режиме реального времени (в stdout, при работе с несколькими контейнерами)
kubectl logs -f -l name=myLabel --all-containers    # вывести логи всех подов с меткой myLabel (в stdout)
kubectl run -i --tty busybox --image=busybox -- sh  # запустить под как интерактивную оболочку
kubectl run nginx --image=nginx --restart=Never -n
mynamespace                                         # Запустить под nginx в заданном пространстве имён
kubectl run nginx --image=nginx --restart=Never     # Запустить под nginx и записать его спецификацию в файл pod.yaml
--dry-run -o yaml > pod.yaml

kubectl attach my-pod -i                            # Прикрепить к запущенному контейнеру
kubectl port-forward my-pod 5000:6000               # Переадресовать порт 5000 в локальной машине на порт 6000 в поде my-pod
kubectl exec my-pod -- ls /                         # Выполнить команду в существующем поде (в случае одного контейнера).
kubectl exec my-pod -c my-container -- ls /         # Выполнить команду в существующем поде (в случае нескольких контейнеров)
kubectl top pod POD_NAME --containers               # Показать метрики по заданному поду вместе с его контейнерами

Работа с узлами и кластером

kubectl cordon my-node                                                # Отметить узел my-node как неназначаемый
kubectl drain my-node                                                 # Вытеснить узел my-node, чтобы подготовиться к эксплуатации
kubectl uncordon my-node                                              # Отметить узел my-node как назначаемый
kubectl top node my-node                                              # Показать метрики по заданному узлу
kubectl cluster-info                                                  # Показать адреса главного узла и сервисов
kubectl cluster-info dump                                             # Вывести состояние текущего кластера в stdout
kubectl cluster-info dump --output-directory=/path/to/cluster-state   # Вывести состояние текущего кластера в /path/to/cluster-state

# Если ограничение с заданным ключом и проявлением уже существует, его значение будет заменено указанным
kubectl taint nodes foo dedicated=special-user:NoSchedule

Типы ресурсов

Вывести все поддерживаемые типы ресурсов, включая API-группу, флаг namespaced (организован ли ресурс в пространство имён или нет) и Kind:

kubectl api-resources

Другие варианты команды для анализа API-ресурсов:

kubectl api-resources --namespaced=true      # Все ресурсы с пространством имён
kubectl api-resources --namespaced=false     # Все ресурсы без пространства имён
kubectl api-resources -o name                # Все ресурсы с простым выводом  (только имя ресурса)
kubectl api-resources -o wide                # Все ресурсы с расширенным (с неограниченной длинной) выводом
kubectl api-resources --verbs=list,get       # Все ресурсы, которые поддерживают глаголы запроса "list" и "get"
kubectl api-resources --api-group=extensions # Все ресурсы в API-группе "extensions"

Форматирование вывода

Для вывода подробной информации в окно терминала в определенном формате, добавьте флаг -o (или --output) в команду kubectl, которая поддерживает форматирование.

Формат вывода

Описание

-o=custom-columns=<spec>

Вывод таблицы из списка пользовательских столбцов через запятую

-o=custom-columns-file=<filename>

Вывод таблицы из списка пользовательских столбцов, определённых в файле <filename>

-o=json

Вывод API-объекта в формате JSON

-o=jsonpath=<template>

Вывод полей, определённых в выражении jsonpath

-o=jsonpath-file=<filename>

Вывод полей, определённых в выражении jsonpath из файла <filename>

-o=name

Вывод только имена ресурсов

-o=wide

Вывод дополнительную информации в обычном текстовом формате, в случае подов отображается имя узла

-o=yaml

Вывод API-объекта в формате YAML

Уровни детальности вывода и отладки в Kubectl

Уровни детальности вывода Kubectl регулируются с помощью флагов -v или --v, за которыми следует целое число, представляющее уровни логирования. Общие соглашения по логированию Kubernetes и связанные с ними уровни описаны здесь.

Уровень детальности

Описание

--v=0

Как правило, используется чтобы всегда видеть, что происходит

--v=1

Достаточный уровень логирования по умолчанию, если вам не нужна большая детальность.

--v=2

Полезная информация про стабильное состояние сервиса и важные сообщения логов, которые могут связаны со значительными изменениями в системе. Это рекомендуемый уровень логирования по умолчанию для большинства систем.

--v=3

Расширенная информация об изменениях.

--v=4

Уровень детальности для отладки.

--v=6

Показать запрашиваемые ресурсы.

--v=7

Показать заголовки HTTP-запросов.

--v=8

Показать содержимое HTTP-запросов.

--v=9

Показать содержимого HTTP-запроса в полном виде.

Различия между Docker, containerd, CRI-O и runc

2023-06-25T15:01:49.458Z

Появление Docker привело к взрывному росту популярности контейнеров, но с тех пор появились и другие инструменты. К сожалению, разобраться в них может быть совсем непросто. Но мы попробуем! И если вы считаете себя единственным, кто всего этого пока не понимает, не волнуйтесь... Это не так!

Что такое Docker?

Существует разница между компанией Docker, контейнерами Docker, образами Docker и инструментами Docker, к которым мы все привыкли. Важно понимать, что Docker — лишь один из инструментов для работы с контейнерами; существуют и другие инструменты, причем некоторые из них поддерживает сама компания Docker.

Как видите, вы не единственный, кто сбит с толку. Давайте разберёмся, чем отличаются Docker, containerd и CRI-O. Это особенно важно, если вы работаете с Kubernetes.

Обзор экосистемы контейнеров

Экосистема контейнеров состоит из множества технологий, специальной терминологии и компаний, конкурирующих друг с другом. К счастью, компании иногда заключают хрупкое перемирие, чтобы согласовать некоторые стандарты. Эти стандарты помогают добиться совместимости между различными инструментами и избежать зависимости от одной компании или проекта. Основные стандарты, о которых необходимо знать:

Container Runtime Interface (CRI) определяет API между Kubernetes и Container Runtime (средой выполнения контейнеров).
Open Container Initiative (OCI) определяет стандарт образов и контейнеров.

На этой иллюстрации показано, как Docker, Kubernetes, OCI, CRI, containerd и runc вписываются в эту экосистему:

Docker

Мы начнем с Docker, потому что это самый популярный инструмент для работы с контейнерами в настоящий момент. Для многих само название "Docker" является синонимом слова «контейнер».

Компания Docker создала очень удобный инструмент для работы с контейнерами. Docker можно установить на ноутбук (Docker Desktop) или сервер (Docker Engine). Он содержит набор инструментов, упрощающих труд разработчиков и DevOps—инженеров. С помощью Docker CLI можно создавать образы контейнеров, работать с репозиториями, создавать, запускать и управлять контейнерами.

Docker состоит из трех проектов:

docker-cli: утилита командной строки, с которой вы взаимодействуете с помощью команды docker.
containerd: Linux Daemon, который управляет контейнерами и запускает их. Он загружает образы из репозитория, управляет хранилищем и сетью, а также контролирует работу контейнеров.
runc: низкоуровневая среда выполнения контейнеров, которая создает и запускает контейнеры.

На самом деле, когда вы запускаете контейнер с помощью docker, вы фактически запускаете его через Docker Daemon, containerd, а затем runc.

Dockershim: Docker в Kubernetes

Важно помнить, что Kubernetes поддерживает только Container Runtime, которые работают с Container Runtime Interface (CRI), но Docker не поддерживает этот стандарт напрямую, поэтому Kubernetes включает компонент под названием dockershim, который необходим для работы с Docker.

Что такое shim?

Компонент, который функционирует как мост между различными API, обеспечивая совместимость.

В дальнейшем Kubernetes откажется от поддержки dockershim и, соответственно, Docker и будет работать только с Container Runtime, поддерживающими Container Runtime Interface (CRI) — containerd или CRI-O.

Но это не означает, что Kubernetes не сможет запускать контейнеры из Docker—образов. И containerd, и CRI-O могут запускать образы в формате Docker (фактически в формате OCI), они просто делают это без использования команды docker и Docker Daemon.

Docker—образы

То, что многие люди называют Docker—образами, на самом деле является образами в формате Open Container Initiative (OCI). Поэтому, если вы загружаете образ из Docker Hub или другого репозитория, вы сможете использовать его с помощью команды docker, или в кластере Kubernetes, или с помощью утилиты podman, или любого другого инструмента, поддерживающего спецификацию формата образа OCI.

Container Runtime Interface (CRI)

CRI — это API, который Kubernetes использует для управления различными Container Runtime, создающими и управляющими контейнерами. CRI упрощает для Kubernetes использование различных Container Runtime. Вместо того, чтобы включать в Kubernetes поддержку каждой из них, используется стандарт CRI. При этом задача управления контейнерами полностью ложится на Container Runtime.

Поэтому, если вы можете использовать containerd для запуска контейнеров, вы также можете использовать CRI-O, потому что они поддерживают стандарт CRI. При этом, если вы конечный пользователь, то вам не важно, какая Container Runtime используется.

Помните, что Red Hat (проект OpenShift) использует CRI-O и отвечает за его поддержку (безопасность, исправления ошибок и т. д.). В то время как Docker поддерживает containerd.

Какая Container Runtime используется в Kubernetes

В архитектуре Kubernetes Kubelet (агент, работающий на каждом узле) отвечает за взаимодействие с Container Runtime. Вы можете проверить, какую Container Runtime вы используете, просмотрев параметры Kubelet на каждом узле. В манифесте есть опции --container-runtime и --container-runtime-endpoint, которые используются для настройки Container Runtime.

containerd

сontainerd — это Container Runtime, которая раньше была частью Docker. Реализует спецификацию CRI. Умеет скачивать образы из репозитория и управляет ими, а затем передает их Container Runtime нижнего уровня (о ней речь пойдет дальше), которая фактически создает и запускает процессы контейнера.

сontainerd был выделен из проекта Docker, чтобы сделать Docker модульным. Таким образом, Docker сам использует containerd. Когда вы устанавливаете Docker, он также устанавливает containerd. Кроме того, сontainerd использует собственный плагин для поддержки CRI в Kubernetes.

CRI-O

CRI-O — это еще одна Container Runtime, реализующая Container Runtime Interface (CRI). Она была специально создана с нуля при поддержке Red Hat, IBM, Intel и SUSE как Container Runtime для Kubernetes. Это альтернатива containerd, которая также позволяет загружать образы контейнеров из репозиториев, управлять ими и запускать Container Runtime нижнего уровня для запуска процессов контейнера.

Open Container Initiative (OCI)

OCI — это группа компаний, которые поддерживают спецификацию формата образа контейнера и метода запуска контейнеров. Идея OCI заключается в том, что вы можете выбирать между различными Container Runtime, которые соответствуют этой спецификации. При этом каждая из них может иметь разные реализации нижнего уровня. Например, у вас, может быть, одна OCI-совместимая Container Runtime для ваших хостов Linux и одна для ваших хостов Windows. В этом заключается преимущество стандартизации.

runc

runc — это еще одна среда выполнения контейнера, совместимая с OCI, которая запускает процессы контейнеров. runc называют эталонной реализацией OCI.

Что такое эталонная реализация?

Эталонная реализация — это программное обеспечение, в котором реализованы все требования спецификации или стандарта. В случае с OCI runc предоставляет все функции, ожидаемые от OCI-совместимой среды выполнения.

Вот несколько альтернатив runc:

crun: среда выполнения контейнеров, написанная на C (в отличие от runc, которая написана на Go).
kata-runtime: из проекта Katacontainers, который реализует спецификацию OCI как отдельные небольшие виртуальные машины (аппаратная виртуализация).
gVisor: разработана в Google, создает контейнеры с собственным ядром. Реализует OCI в своей среде выполнения, называемой runsc.

Подведем итоги

Docker — это лишь часть всей экосистемы контейнеров. Существуют открытые стандарты: CRI и OCI, и несколько Container Runtime с поддержкой CRI: containerd, runc, CRI-O и, конечно, сам Docker. Возможно, скоро мы увидим множество новых реализаций Container Runtime с поддержкой стандартов CRI и OCI.

Ansible VAULT

2023-06-22T14:33:59.127Z

Задачи автоматизации развертывания какого-либо ПО или изменения настроек системы практически всегда связаны с использованием учетных записей, обладающих необходимым набором прав для выполнения данных действий. И одна из самых важных проблем при использовании различных скриптов автоматизации состоит в том, что в этом сценарии приходится указывать учетные данные в открытом виде. Соответственно возникает проблема обеспечения безопасности этих данных, ведь к исходному коду скрипта может получить доступ любой пользователь, обладающий соответствующими правами. Кроме того, репозитории, в которых хранится исходный код сценариев тоже нуждаются в защите, так как здесь тоже любой имеющий доступ на чтение может узнать пароли. Конечно, можно попробовать хранить секретную информацию в отдельных файлах и считывать при выполнении сценария, но это не всегда возможно и часто требует дополнительного ручного труда, что несколько снижает преимущества автоматизации.

Склеп для секретов

И здесь на помощь нам приходит Ansible Vault – утилита для шифрования любых файлов в которых вы хотите хранить секретные переменные (пароли, ключи и т.д.). В качестве алгоритма шифрования Ansible Vault использует алгоритм симметричного шифрования AES256.

В этой статье мы рассмотрим использование Ansible Vault для работы с секретной информацией. Сразу замечу, что многие предпочитают использовать Hashicorp Vault для работы с Ansible, однако этого мощного средства в данной статье касаться не будем и поговорим только о встроенных в Ansible средствах.

Итак, основное предназначение Vault это хранение конфиденциальной информации, такой как учетные данные и секретные ключи. Как происходит обработки зашифрованных данных: в процессе выполнения плейбука данные автоматически расшифровываются и наша задача при выполнении плейбука правильно указать ключи, необходимые для расшифровки. Для шифрования используется парольная фраза и, соответственно, чем сложнее фраза, тем сложнее злоумышленнику расшифровать данные.

Важное уточнение. Ansible Vault защищает данные только когда они находятся в состоянии покоя, после того, как они расшифрованы Vault уже никаким образом не может их защитить и об их безопасности необходимо заботиться уж другими средствами.

Приступая к работе

Для работы с Vault нам прежде всего потребуется сам Ansible. В предыдущих статьях мы уже рассматривали его установку, поэтому будем считать, что все что нужно у вас уже есть.

Для работы с файлами мы можем вводить парольную фразу с клавиатуры при каждом обращении к Vault или же использовать файл, в котором хранится парольная фраза. В первом случае в строку вызова добавляется ключ —ask-vault-pass, во втором добавляется параметр —vault-password-file=<путь к файлу>.

Но прежде, чем начать работу с утилитой официальное руководство по Ansible предлагает нам определиться со стратегией управления паролями вашего хранилища. А именно, для начала нам нужно определиться с тем, будем ли мы шифровать весь контент одним паролем или же мы будем применять разные парольные фразы для разных случаев. Также, очень важный вопрос это где вы собираетесь хранить свои пароли.

В случае, если у вас небольшая команда или немного данных, вы можете использовать один пароль для всего, что вы шифруете с помощью Ansible Vault. Здесь важно помнить, что не стоит пытаться шифровать все данные, шифруйте только то, что является действительно секретной информацией, что критично для бизнеса и инфраструктуры.

Несколько паролей удобны если у вас большая команда или большой объем конфиденциальных данных. Например, вы можете использовать разные пароли для разных пользователей или для разграничения разных уровней доступа. В зависимости от решаемых задач вам может потребоваться другой пароль для каждого зашифрованного файла или каталога. Например, у вас может быть playbook, который включает в себя два файла vars, один для среды разработки и один для рабочей среды, зашифрованные двумя разными паролями. При запуске плейбука вам потребуется выбрать правильный пароль хранилища для среды, на которую вы ориентируетесь, используя идентификатор хранилища.

Начнем с простого примера. Создадим зашифрованный файл с консольным вводом пароля. Пока никакой автоматизации.

ansible-vault create --vault-id @prompt secret.yml

New vault password (default):

Confirm new vault password (default):

Содержимое файла плейбука может быть например следующим:

---

- name: This is a secret file

hosts: s1.otus.local

tasks:

- name: Execute command 'ls'

command: ls

После сохранения yml файла убедимся что он зашифрован.

Как видно, все кроме заголовка превратилось в бессмысленный набор цифр. Однако, зашифровать данные недостаточно, важно еще и расшифровать их и для этого мы воспользуемся следующей командой.

ansible-vault view --vault-id @prompt secret.yml

Как видно все достаточно просто. Если нам необходимо внести изменения в зашифрованный файл то можно воспользоваться следующей командой:

ansible-vault edit secret.yml

Но я думаю, что большинство системных администраторов согласится с тем, что это не самый лучший подход к автоматизации работы. Интерактивный ввод пароля требует участия человека который знает это пароль. То есть делегировать кому-либо запуск зашифрованного плейбука нам будет проблематично. Ну а с точки зрения безопасности хотелось бы напомнить, что существует такой класс вредоносов как кейлоггеры, то есть приложения, которые сохраняют все нажатые клавиши и интерактивный ввод парольной фразы позволит таким клавиатурным шпионам перехватить нажатые клавиши.

Поэтому в качестве альтернативы предлагается использовать файл с паролями. Здесь тоже надо помнить про безопасность и обеспечить ограничение доступа посторонних к каталогу, в котором хранятся такие файлы.

Для начала создадим файл с “очень сложным” паролем:

echo “P@ssw0rd” > password_file

И теперь применим этот файл для редактирования нашего yml файла. В случае, если для шифрования файла в предыдущем примере у вас использовался другой пароль, то для корректной расшифровки secret.yml необходимо указать его.

ansible-vault edit --vault-password-file password_file secret.yml

Если же у нас уже имеется готовый плейбук и мы хотим его зашифровать, то пригодится команда encrypt:

ansible-vault encrypt --vault-id @prompt secret_conditional.yml

Практическое применение

Приведенные выше примеры демонстрировали возможности ansible-vault как отдельного средства шифрования/дешифрования файлов. Однако, на практике шифрование используется в плейбуках и нам нужно иметь возможность сообщить плейбуку как получить доступ к любым зашифрованным данным, с которыми он может столкнуться. Здесь важно понимать что плейбук не знает, что по умолчанию он имеет дело с зашифрованными данными, поэтому при запуске команды ansible-playbook ему необходимо передать соответствующую информацию. Так, для запуска нашего зашифрованного плейбука с интерактивным запросом пароля нам необходимо выполнить следующую команду:

ansible-playbook --vault-id @prompt secret.yml

Ну а если мы хотим использовать файл с паролями, то команда будет иметь следующий вид:

ansible-playbook secret.yml --vault-password-file=password_file

Когда не нужно все

Далеко не всегда необходимо шифровать файл плейбука целиком. Иногда удобнее зашифровать значение только определенной переменной, например пароль, а все остальное оставить в открытом виде для того, чтобы другие специалисты также могли вносить свои правки при необходимости.

Для этого мы можем воспользоваться параметром encrypt_string. В примере ниже у нас имеется переменная my_secret значение которой неплохо бы скрыть от посторонних.

---

- name: inline secret variable demonstration

hosts: s1.otus.local

gather_facts: false

vars:

my_secret: my_very_long_password

tasks:

- name: print the secure variable

debug:

var: my_secret

Для этого используем следующую команду:

ansible-vault encrypt_string --vault-id @prompt my_very_long_password

Теперь мы можем заменить значение переменной на этот набор цифр и получить в итогк следующее:

Для запуска этого плейбука воспользуемся командой

ansible-playbook --vault-id @prompt secret1.yml

Управление паролями

В завершении статьи немного поговорим об управлении паролями, используемыми для шифрования. Общеизвестно, что пароли необходимо на регулярной основе менять, в противном случае со времени они перестанут быть секретом.

Для замены пароля необходимо указать старый пароль и затем два раза ввести новый:

ansible-vault rekey --ask-vault-pass secret.yml

Как видно все достаточно просто.

Заключение

Сегодня мы рассмотрели работу с шифрованием данных в Ansible с помощью Ansible Vault. Данная утилита предоставляет базовый функционал для шифрования, а для более решения более сложных задач управления шифрованием рекомендуется использовать Hashicorp Vault.

Также я хочу порекомендовать вам бесплатный урок от OTUS в рамках которого мы рассмотрим различные типы анализа исходного кода (SAST/SCA/DAST/IAST/RASP) и поговорим об инструментах, позволяющих внедрить их в ваш CI/CD пайплайн

Компоненты SystemD

2023-05-31T16:33:50.083Z

systemd

2023-05-22T18:07:14.983Z

systemd — набор базовых компонентов Linux-системы. Представляет собой менеджер системы и служб, который выполняется как процесс с PID 1 и запускает остальную часть системы. systemd обеспечивает возможности агрессивной параллелизации, сокетную и D-Bus активацию для запуска служб, запуск демонов по запросу, отслеживание процессов с помощью контрольных групп Linux, обслуживание точек (авто)монтирования, а также предлагает развитую транзакционную логику управления службами на основе зависимостей. systemd поддерживает сценарии инициализации SysV и LSB и работает как замена sysvinit. Среди прочих элементов и функций — демон журнала, утилиты управления базовой конфигурацией системы (имя хоста, дата, языковой стандарт), ведение списков вошедших в систему пользователей, запущенных контейнеров, виртуальных машин, системных учётных записей, каталогов и настроек времени выполнения, а также демоны для управления несложными сетевыми конфигурациями, синхронизации времени по сети, пересылки журналов и разрешения имён.

Основы использования systemctl

Главная команда для работы с systemd — systemctl. Она позволяет (среди прочего) отлеживать состояние системы и управлять системой и службами. Подробнее см. systemctl(1).

Совет:

Для управления systemd на удалённой машине команды необходимо выполнять с ключом -H пользователь@хост. Соединение с удалённым процессом systemd будет установлено через SSH.
В Plasma для systemctl разработан графический интерфейс systemd-kcmAUR. После установки соответствующий модуль появится в разделе System administration.

Использование юнитов

Юнитами могут быть, например, службы (.service), точки монтирования (.mount), устройства (.device) или сокеты (.socket).

При работе с systemctl обычно необходимо указывать полное имя юнита с суффиксом, например, sshd.socket. Существует несколько возможных сокращений:

Если суффикс не указан, systemctl предполагает, что это .service. Например, netctl равнозначно netctl.service.
Точки монтирования автоматически преобразуются в юнит .mount. Например, /home равнозначно home.mount.
Аналогично точкам монтрования, имена устройств автоматически преобразуются в юнит .device. Например, /dev/sda2 равнозначно dev-sda2.device.

Подробнее см. systemd.unit(5).

Примечание: Некоторые юниты содержат в названии символ @ (вида название@строка.service). Это т.н. экземпляры юнита-шаблона, настоящее имя которого не содержит части строка (т.е. имеет вид название@.service). строка называется идентификатором экземпляра и передаётся юниту-шаблону в качестве аргумента при вызове systemctl: в файле юнита идентификатор заменит спецификатор %i.

Если говорить точнее, systemd сначала попытается найти юнит, название которого полностью совпадёт с название@строка.суффикс, и лишь в случае неудачи создаст экземпляр шаблона название@.суффикс. Тем не менее, такие "конфликты" довольно редки, так как по соглашению символ @ должен использоваться только в названиях юнитов-шаблонов. Также помните, что вызвать юнит-шаблон без идентификатора экземпляра не получится, поскольку в этом случае нечего будет подставить вместо спецификатора %i.

Совет:

Большинство команд ниже также будут работать, если указать несколько юнитов; подробнее см. systemctl(1).
Опция --now в командах enable, disable и mask соответственно запускает, останавливает или маскировует указанный юнит сразу при выполнении команды, а не после перезагрузки.
Пакеты могут содержать собственные юниты для различных целей. Если вы только что установили пакет, выполните pacman -Qql название_пакета | grep -Fe .service -e .socket, чтобы их найти.

Действие

Команда

Примечание

Анализ состояния системы

Состояние системы

$ systemctl status

Список запущенных юнитов

$ systemctl или
$ systemctl list-units

Список юнитов, запустить которые не удалось

$ systemctl --failed

Список установленных файлов юнитов1

$ systemctl list-unit-files

Информация о процессе по его PID

$ systemctl status pid

cgroup slice, занимаемая память и родительский процесс

Состояние юнита

Страница руководства юнита

$ systemctl help юнит

если юнит её предоставляет

Состояние юнита

$ systemctl status юнит

в т. ч. работает ли он в данный момент

Проверить, добавлен ли юнит в автозапуск

$ systemctl is-enabled юнит

Запуск, перезапуск, перезагрузка юнита

Незамедлительно запустить юнит

# systemctl start юнит

Незамедлительно остановить юнит

# systemctl stop юнит

Перезапустить юнит

# systemctl restart юнит

Перезагрузить юнит с новыми настройками

# systemctl reload юнит

Перезагрузить настройки systemd2

# systemctl daemon-reload

сканировать систему на наличие новых или изменённых юнитов

Включение юнита (автозапуск)

Включить юнит, добавив его в автозапуск

# systemctl enable юнит

Включить юнит и сразу запустить

# systemctl enable --now юнит

Отключить запуск юнита при загрузке

# systemctl disable юнит

Включить юнит заново3

# systemctl reenable юнит

т.е. отключить и снова включить

Маскировка юнита

Замаскировать юнит, сделав невозможным его запуск4

# systemctl mask юнит

Снять маскировку юнита

# systemctl unmask юнит

В руководстве systemd.unit(5) § UNIT FILE LOAD PATH приведён перечень каталогов, в которых могут храниться файлы юнитов.
Перезагружаются только настройки systemd, но не юнитов. Для юнитов необходимо использовать команду reload.
Например, если раздел [Install] изменился с момента последнего включения.
Как вручную, так и по зависимости, что делает маскировку несколько опасной.

Управление питанием

Для управления питанием от имени непривилегированного пользователя необходим polkit. Если вы находитесь в локальном пользовательском сеансе systemd-logind и нет других активных сеансов, приведенные ниже команды сработают, даже если будут выполнены не от root. В противном случае (например, другой пользователь вошел в систему через tty) systemd автоматически запросит у вас пароль суперпользователя.

Действие

Команда

Завершить работу и перезагрузить систему

$ systemctl reboot

Завершить работу и выключить компьютер

$ systemctl poweroff

Перевести систему в ждущий режим

$ systemctl suspend

Перевести систему в спящий режим

$ systemctl hibernate

Перевести систему в режим гибридного сна (suspend-to-both)

$ systemctl hybrid-sleep

Написание файлов юнитов

Синтаксис файлов юнитов systemd (см. systemd.unit(5)) вдохновлён desktop-файлами XDG Desktop Entry Specification, а они, в свою очередь, основаны на синтаксисе файлов .ini Microsoft Windows. Файлы юнитов загружаются из целого ряда мест (команда systemctl show --property=UnitPath выведет полный список), ключевыми из которых являются следующие (в порядке увеличения приоритета):

/usr/lib/systemd/system/: юниты, добавленные пакетами при установке;
/etc/systemd/system/: юниты, созданные системным администратором.

Примечание:

При запуске systemd в пользовательском режиме пути загрузки будут отличаться.
Названия юнитов могут содержать только буквы и цифры ASCII-набора, подчёркивания и точки. Другие символы должны быть экранированы в C-стиле ("\x2d") или использоваться исключительно в рамках определённой семантики ('@', '-'). Подробнее см. systemd.unit(5) и systemd-escape(1).

При создании собственных юнитов за образец можно взять юниты установленных пакетов или примеры из systemd.service(5) § EXAMPLES.

Совет: Комментарии в файлах юнитов должны начинаться с символа # и размещаться на отдельной строке. Не используйте комментарии в конце строки, после параметров systemd, иначе юнит не будет работать.

Обработка зависимостей

В systemd зависимости определяются правильным построением файлов юнитов. Простой пример — юниту A требуется, чтобы юнит B был запущен перед запуском самого юнита A. Для этого добавьте строки Requires=B и After=B в раздел [Unit] юнит-файла A. Если зависимость является необязательной, укажите Wants=B и After=B соответственно. Обратите внимание, что Wants= и Requires= не подразумевают After=. Если After= не указать, то юниты будут запущены параллельно.

Зависимости обычно указываются для служб, но не для целей. Так, цель network.target будет "подтянута" ещё на этапе настройки сетевых интерфейсов одной из соответствующих служб, и можно спокойно указывать эту цель как зависимость в пользовательской службе, поскольку network.target будет запущена в любом случае.

Типы служб

Службы различаются по типу запуска, и это следует учитывать при написании юнитов. Тип определяется параметром Type= в разделе [Service]:

Type=simple (по умолчанию): systemd запустит эту службу незамедлительно. Процесс при этом не должен разветвляться (fork). Если после данной службы должны запускаться другие, то этот тип использовать не стоит (исключение — служба использует сокетную активацию).
Type=forking: systemd считает службу запущенной после того, как процесс разветвляется с завершением родительского процесса. Используется для запуска классических демонов за исключением тех случаев, когда в таком поведении процесса нет необходимости. Укажите параметр PIDFile=, чтобы systemd мог отслеживать основной процесс.
Type=oneshot: удобен для сценариев, которые выполняют одно задание и завершаются. Если задать параметр RemainAfterExit=yes, то systemd будет считать процесс активным даже после его завершения.
Type=notify: идентичен параметру Type=simple, но с уточнением, что демон пошлет systemd сигнал готовности. Реализация уведомления находится в библиотеке libsystemd-daemon.so.
Type=dbus: служба считается находящейся в состоянии готовности после появления указанного BusName в системной шине DBus.
Type=idle: systemd отложит выполнение двоичного файла службы до окончания запуска остальных ("более срочных") задач. В остальном поведение аналогично Type=simple.

Подробнее о параметре Type см. systemd.service(5) § OPTIONS.

Редактирование файлов юнитов

Не стоит редактировать юнит-файлы пакетов напрямую, так как это приведёт к конфликтам с pacman. Есть два безопасных способа редактирования: создать новый файл, который полностью заменит оригинальный, или создать drop-in файл, который будет применяться поверх оригинального юнита. В обоих случаях после редактирования необходимо перезагрузить юнит, чтобы изменения вступили в силу. Это выполняется либо путем редактирования блока с помощью команды systemctl edit, которая автоматически перезагружает юнит, либо перезагрузкой всех юнитов командой:

# systemctl daemon-reload

Совет:

С помощью systemd-delta можно узнать, какие файлы юнитов были переопределены и что конкретно было изменено.
Команда systemctl cat юнит позволит просмотреть содержимое файла юнита и связанных с ним drop-in сниппетов.

Замещение файла юнита

Чтобы полностью заместить файл юнита /usr/lib/systemd/system/юнит, создайте файл с таким же именем /etc/systemd/system/юнит и включите заново юнит для обновления символических ссылок.

Альтернативный способ:

# systemctl edit --full юнит

Эта команда откроет файл /etc/systemd/system/юнит в текстовом редакторе (если файл ещё не существует, будет скопирован оригинал) и автоматически перезагрузит юнит после завершения редактирования.

Примечание: Новые изменённые юниты продолжат работать даже после того, как pacman обновит оригинальные юниты в будущем. Это может усложнить обслуживание системы, поэтому предпочтительнее использовать подход, описанный в следующем разделе.

Drop-in файлы

Чтобы создать drop-in файл для /usr/lib/systemd/system/юнит, создайте каталог /etc/systemd/system/юнит.d/ и поместите в него файлы .conf с добавленными или изменёнными опциями. systemd будет анализировать эти файлы и применять их поверх оригинального юнита.

Самый простой способ — использовать команду:

# systemctl edit юнит

Команда откроет /etc/systemd/system/юнит.d/override.conf в текстовом редакторе (файл будет создан, если его ещё нет) и автоматически перезапустит юнит после завершения редактирования.

Примечание: Не все опции могут быть заменены в drop-in файле. Например, для изменения опции Conflicts= придётся создать полную замену файла юнита (см. предыдущий раздел).

Откат изменений

Отменить все изменения, сделанные с помощью systemctl edit, можно командой:

# systemctl revert юнит

Примеры

Например, если вы просто хотите добавить дополнительную зависимость к юниту, можно создать следующий файл:

/etc/systemd/system/юнит.d/customdependency.conf

[Unit]
Requires=новая зависимость
After=новая зависимость

Другой пример: для замены ExecStart в юните (кроме типа oneshot) создайте следующий файл:

/etc/systemd/system/юнит.d/customexec.conf

[Service]
ExecStart=
ExecStart=новая команда

Обратите внимание, что ExecStart необходимо очистить перед присвоением нового значения [1]. Это относится ко всем параметрам, которые позволяют прописать несколько значений, вроде OnCalendar в таймерах.

Пример настройки автоматического перезапуска службы:

/etc/systemd/system/юнит.d/restart.conf

[Service]
Restart=always
RestartSec=30

Цели

Systemd использует юнит типа цель (target) для группировки юнитов по зависимостям и в качестве стандартизированных точек синхронизации. Они выполняют ту же задачу, что и уровни запуска, но действуют немного по-другому. Каждая цель имеет имя, а не номер, и предназначена для конкретных задач; несколько целей могут быть активны одновременно. Некоторые цели реализованы путём наследования служб из других целей с добавлением собственных. В systemd также имеются цели, имитирующие общие уровни запуска SystemVinit, поэтому вы можете переключаться между целями, используя привычную команду telinit RUNLEVEL.

Получение информации о текущих целях

В systemd для этого предназначена следующая команда (заменяющая runlevel):

$ systemctl list-units --type=target

Создание пользовательской цели

Уровни запуска, имеющие определённое значение в sysvinit (0, 1, 3, 5 и 6), один в один соответствуют конкретным целям systemd. К сожалению, не существует хорошего способа сделать то же самое для пользовательских уровней 2 и 4. Их использование предполагает, что вы создаёте новый юнит-цель с названием /etc/systemd/system/цель, который берет за основу один из существующих уровней запуска (взгляните, например, на /usr/lib/systemd/system/graphical.target), создаёте каталог /etc/systemd/system/цель.wants, а после этого — символические ссылки на те службы из каталога /usr/lib/systemd/system/, которые вы хотите включить при загрузке.

Соответствие уровней SysV целям systemd

Уровнень запуска SysV

Цель systemd

Примечания

runlevel0.target, poweroff.target

Выключение системы

1, s, single

runlevel1.target, rescue.target

Однопользовательский уровень запуска

2, 4

runlevel2.target, runlevel4.target, multi-user.target

Уровни запуска, определенные пользователем/специфичные для узла. По умолчанию соответствует уровню запуска 3

runlevel3.target, multi-user.target

Многопользовательский режим без графики. Пользователи, как правило, входят в систему при помощи множества консолей или через сеть

runlevel5.target, graphical.target

Многопользовательский режим с графикой. Обычно эквивалентен запуску всех служб на уровне 3 и графического менеджера входа в систему

runlevel6.target, reboot.target

Перезагрузка

emergency

emergency.target

Аварийная оболочка

Изменение текущей цели

В systemd цели доступны посредством целевых юнитов. Вы можете переключать их такой командой:

# systemctl isolate graphical.target

Данная команда только изменит текущую цель и не повлияет на следующую загрузку системы. Она соответствует командам Sysvinit вида telinit 3 и telinit 5.

Изменение цели загрузки по умолчанию

Стандартная цель — default.target, которая по умолчанию ссылается на graphical.target (примерно соответствующего прежнему уровню запуска 5).

Узнать текущую цель можно так:

$ systemctl get-default

Для установки новой цели загрузки по умолчанию измените ссылку default.target. С помощью команды systemctl это делается так:

# systemctl set-default multi-user.target

Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target.

Альтернативный способ — добавить один из следующих параметров ядра в загрузчик:

systemd.unit=multi-user.target (что примерно соответствует прежнему уровню запуска 3).
systemd.unit=rescue.target (что примерно соответствует прежнему уровню запуска 1).

Порядок выбора цели по умолчанию

systemd выбирает default.target в следующем порядке :

Параметр ядра, описанный выше.
Символическая ссылка /etc/systemd/system/default.target.
Символическая ссылка /usr/lib/systemd/system/default.target.

Компоненты systemd

Некоторые (не все) составные части systemd:

systemd-boot — простой менеджер загрузки для UEFI;
systemd-firstboot — инициализация системных настроек при первой загрузке;
systemd-homed — переносимые аккаунты пользователей;
systemd-logind — управление сеансами;
systemd-networkd — управление сетевыми настройками;
systemd-nspawn — приложение для контейнеризации процессов;
systemd-resolved — разрешение сетевых имён;
systemd-sysusers(8) — создание системных пользователей/групп и добавление пользователей в группы при установке пакетов и загрузке системы;
systemd-timesyncd — синхронизация системных часов по сети;
systemd/Журнал — системные логи;
systemd/Таймеры — таймеры для управления событиями и службами, альтернатива cron.

systemd.mount — монтирование

systemd полностью отвечает за монтирование разделов и файловых систем, описанных в файле /etc/fstab. systemd-fstab-generator(8) преобразует записи из /etc/fstab в юниты systemd; это выполняется при каждой загрузке системы, а также при перезагрузке конфигурации системного менеджера.

systemd расширяет возможности fstab и предлагает дополнительные опции монтирования. Они могут влиять на зависимости юнита монтирования: например, могут гарантировать, что монтирование выполняется только после подключения к сети или после монтирования другого раздела. Полный список опций монтирования systemd (обычно они имеют префикс x-systemd) описан в systemd.mount(5) § FSTAB.

Примером этих опций может быть т.н. автомонтирование (здесь имеется в виду не автоматическое монтирование во время загрузки, а монтирование при появлении запроса от устройства). Подробнее смотрите fstab#Автоматическое монтирование с systemd.

Автомонтирование GPT-раздела

На UEFI-системах systemd-gpt-auto-generator(8) автоматически монтирует GPT-разделы в соответствии с Discoverable Partitions Specification, поэтому их можно не указывать в файле fstab.

Требования:

Загрузчик должен установить EFI-переменную LoaderDevicePartUUID, по которой можно будет определить системный раздел EFI. Эта возможность поддерживается в systemd-boot, а также в rEFInd (по умолчанию отключена). Это проверяется наличием строки Boot loader sets ESP partition information в выводе команды bootctl.
Корневой раздел должен быть на одном физическом диске с системным разделом EFI. Автомонтируемые разделы должны быть на одном физическом диске с корневым разделом. Очевидно, монтируемые разделы должны оказаться на одном диске и с ESP.

Совет: Автомонтирование разделов отключается изменением его GUID-типа или установкой атрибута раздела "do not mount" (бит 63), см. gdisk#Prevent GPT partition automounting.

/var

Для автомонтирования раздела /var его PARTUUID должен совпадать с хэш-суммой SHA256 HMAC, вычисленной на основании UUID типа раздела. В качестве ключа хэша используется machine ID. Необходимый PARTUUID можно получить командой:

$ systemd-id128 -u --app-specific=4d21b016-b534-45c2-a9fb-5c16e091fd2d machine-id

Примечание: Утилита systemd-id128(1) считывает machine ID из файла /etc/machine-id, поэтому вычислить PARTUUID до установки системы невозможно.

systemd-sysvcompat

Пакет systemd-sysvcompat (зависимость пакета base) содержит традиционный бинарный файл init. В системах под управлением systemd init — символическая ссылка на исполняемый файл systemd.

Кроме того, в этом пакете находятся 4 команды SysVinit — halt(8), poweroff(8), reboot(8) и shutdown(8). Это символические ссылки на systemctl, и их работа обусловлена логикой systemd. Подробнее см. #Управление питанием.

В systemd-системах отказаться от совместимости с System V можно либо задав параметр загрузки init= (см. BBS#233387), либо с помощью собственных аргументов команды systemctl.

systemd-tmpfiles — временные файлы

Утилита systemd-tmpfiles создает, удаляет и очищает непостоянные и временные файлы и каталоги. Она читает конфигурационные файлы из /etc/tmpfiles.d/ и /usr/lib/tmpfiles.d/, чтобы понять, что необходимо делать. Конфигурационные файлы в первом каталоге имеют приоритет над теми, что расположены во втором.

Конфигурационные файлы обычно предоставляются вместе с файлами служб и имеют названия вида /usr/lib/tmpfiles.d/программа.conf. Например, демон Samba предполагает, что существует каталог /run/samba с корректными правами доступа. Поэтому пакет samba поставляется в следующей конфигурации:

/usr/lib/tmpfiles.d/samba.conf

D /run/samba 0755 root root

Конфигурационные файлы также могут использоваться для записи значений при старте системы. Например, если вы используете /etc/rc.local для отключения пробуждения от устройств USB при помощи echo USBE > /proc/acpi/wakeup, вместо этого вы можете использовать следующий tmpfile:

/etc/tmpfiles.d/disable-usb-wake.conf

#    Path                  Mode UID  GID  Age Argument
w    /proc/acpi/wakeup     -    -    -    -   USBE

Подробнее смотрите systemd-tmpfiles(8) и tmpfiles.d(5).

Примечание: Этот способ может не сработать для установки опций в /sys, поскольку служба systemd-tmpfiles-setup может запуститься до того, как будут загружены соответствующие модули устройств. В этом случае при помощи команды modinfo модуль вы можете проверить, имеет ли модуль параметр для установки необходимой опции, и установить эту опцию в файле настроек в каталоге /etc/modprobe.d. В противном случае для установки верных атрибутов сразу при появлении устройства придется написать правило udev.

Советы и рекомендации

Программы настройки с графическим интерфейсом

systemadm — Графический поисковик юнитов systemd. Выводит список юнитов, возможна фильтрация по типу.

https://cgit.freedesktop.org/systemd/systemd-ui/ || systemd-ui

SystemdGenie — Утилита управления systemd на основе инструментов KDE.

https://invent.kde.org/system/systemdgenie || systemdgenie

Запуск сервисов после подключения к сети

Чтобы запустить сервис только после подключения к сети, добавьте такие зависимости в .service файле:

/etc/systemd/system/foo.service

[Unit]
...
Wants=network-online.target
After=network-online.target
...

Также должна быть включена служба ожидания сети того приложения, которое управляет сетью; только тогда network-online.target будет соответствовать состоянию сети.

В NetworkManager служба NetworkManager-wait-online.service включается вместе с NetworkManager.service. Проверить состояние службы можно командой systemctl is-enabled NetworkManager-wait-online.service. Если служба не включена, то включите заново NetworkManager.service ещё раз.
В случае netctl включите службу netctl-wait-online.service.
Для пользователей systemd-networkd юнит systemd-networkd-wait-online.service включается вместе со службой systemd-networkd.service; проверьте это командой systemctl is-enabled systemd-networkd-wait-online.service. Если нет, то включите заново systemd-networkd.service.

Подробнее можно почитать: Network configuration synchronization points.

Если служба отправляет DNS-запросы, она должна запускаться также после nss-lookup.target:

/etc/systemd/system/foo.service

[Unit]
...
Wants=network-online.target
After=network-online.target nss-lookup.target
...

Подробнее см. systemd.special(7).

Чтобы цель nss-lookup.target работала как положено, должна быть служба, которая запускает её параметром Wants=nss-lookup.target и размещает себя перед ней (Before=nss-lookup.target). Обычно это выполняет локальный DNS-распознаватель.

Чтобы узнать, какие службы зависят от nss-lookup.target, выполните:

$ systemctl list-dependencies --reverse nss-lookup.target

Включение установленных юнитов по умолчанию

This article or section needs expansion.

Reason: Как это работает для юнитов-экземпляров? (Discuss in Talk:Systemd (Русский))

Arch Linux поставляется с файлом /usr/lib/systemd/system-preset/99-default.preset, в котором указан параметр disable *. Это означает, что systemctl preset отключает по умолчанию юниты и пользователь должен сам их включать после установки пакетов.

Если такое поведение не устраивает, создайте символическую ссылку /etc/systemd/system-preset/99-default.preset на /dev/null для переопределения файла конфигурации. Это заставит systemctl preset включать юниты новых пакетов — вне зависимости от типа — кроме указанных в других файлах из каталога настроек systemctl preset. Пользовательских юнитов это не касается. Подробнее смотрите systemd.preset(5).

Примечание: Политика включения всех юнитов по умолчанию может привести к проблемам, если в установленном пакете находится несколько взаимоисключающих юнитов. В этом случае в файле preset-настроек придётся явно указать, какие юниты включаться не должны. Подробнее смотрите systemd.preset(5).

Песочница для приложений

Юнит может быть использован в качестве песочницы для изоляции приложений и их процессов в виртуальном окружении. Systemd использует механизм namespaces, белые и чёрные списки capabilities, а также control groups для контейнеризации процессов при помощи настраиваемых окружений — см. systemd.exec(5).

Добавление к существующему юниту systemd функциональности песочницы обычно происходит методом проб и ошибок вкупе с использованием различных инструментов логирования — strace, stderr и journalctl(1). В таких случаях имеет смысл предварительно поискать соответствующую документацию от разработчиков. В качестве отправной точки для поиска путей повышения безопасности изучите вывод команды:

$ systemd-analyze security юнит

Рекомендации по созданию песочницы с помощью systemd:

Параметр CapabilityBoundingSet определяет список разрешённых capabilities, но с его помощью можно также и запрещать некоторые capabilities для определённого юнита.

Например, можно задать capability CAP_SYS_ADM, необходимую для создания безопасной песочницы: CapabilityBoundingSet=~ CAP_SYS_ADM

Уведомление о неработающих службах

Для уведомления о неудачном запуске службы используется директива OnFailure= в соответствующем файле службы или drop-in файле. Чтобы эта директива возымела эффект для всех служб одновременно, её необходимо добавть в drop-in файл верхнего уровня, см. systemd.unit(5).

Создайте drop-in верхнего уровня:

/etc/systemd/system/service.d/toplevel-override.conf

[Unit]
OnFailure=failure-notification@%n

Это добавит строку OnFailure=failure-notification@%n в файл каждой службы. Если какой-то_юнит завершится с ошибкой, запустится экземпляр службы failure-notification@какой-то_юнит для создания уведомления (или любой другой задачи, которая была назначена).

Создайте юнит-шаблон failure-notification@:

/etc/systemd/system/failure-notification@.service

[Unit]
Description=Send a notification about a failed systemd unit
After=network.target

[Service]
Type=simple
ExecStart=/путь/к/failure-notification.sh %i

После этого создайте сценарий failure-notification.sh, в котором определите, каким именно способом будет создаваться уведомление (mail, gotify, xmpp). Параметр %i будет заменён на название неудачно завершившегося юнита и будет передан сценарию в качестве аргумента.

Чтобы предотвратить регрессию экземпляров failure-notification@.service, создайте пустой файл drop-in настроек с именем, совпадающим с названием drop-in файла верхнего уровня (пустой файл "уровня служб" будет иметь приоритет над файлом "верхнего уровня"):

# mkdir -p /etc/systemd/system/failure-notification@.service.d
# touch /etc/systemd/system/failure-notification@.service.d/toplevel-override.conf

Решение проблем

Неудачно запущенные службы

Следующая команда найдёт все службы, которые не смогли выполнить запуск:

$ systemctl --state=failed

Чтобы определить причину, по которой служба не запустилась, необходимо изучить записи её логов. Подробнее см. systemd/Журнал#Фильтрация вывода.

Диагностика загрузки системы

В systemd есть несколько опций для диагностики проблем процесса загрузки. В статье об отладке загрузки описано, как получить доступ к сообщениям, выданным процессом загрузки до того, как systemd перехватил управление. Также смотрите документацию по отладке systemd.

Диагностика службы

Если какая-либо служба systemd ведет себя не так, как ожидается, и вы хотите получить дополнительную информацию о том, что происходит, присвойте переменной окружения SYSTEMD_LOG_LEVEL значение debug. Например, чтобы запустить демон systemd-networkd в режиме отладки:

Добавьте drop-in файл для службы:

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

Или, как вариант, пропишите переменную окружения вручную:

# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

После этого перезапустите systemd-networkd и следите за журналом службы с помощью опции -f/--follow.

Выключение/перезагрузка происходят ужасно долго

Если процесс выключения занимает очень долгое время (или выглядит зависшим), то, вероятно, виновата служба, которая не может завершить свою работу. Systemd ожидает некоторое время, пока каждая служба прекратит работу самостоятельно, и только потом пробует завершить её принудительно. Если вы столкнулись с такой проблемой, обратитесь к Shutdown completes eventually в systemd-вики.

По-видимому, процессы с кратким сроком жизни не оставляют записей в логах

Если команда journalctl -u foounit не даёт вывода для службы с коротким сроком жизни, вместо названия службы используйте её PID. Например, если загрузка службы systemd-modules-load.service завершилась неудачно и команда systemctl status systemd-modules-load показывает, что она была запущена с PID 123, то вы сможете посмотреть вывод процесса в журнале под данным PID, то есть командой journalctl -b _PID=123. Поля метаданных для журнала вроде _SYSTEMD_UNIT и _COMM собираются асинхронно и полагаются на каталог /proc в случае с действующими процессами. Для решения проблемы требуется внести исправления в ядро, чтобы эти данные можно было собирать через сокет, наподобие SCM_CREDENTIALS. В общем, это баг. Имейте в виду, что быстро падающие службы могут не успеть оставить сообщения в журнале из-за особенностей systemd.

Время загрузки системы увеличивается с течением времени

После использования systemd-analyze некоторые пользователи заметили, что время загрузки системы значительно увеличилось. После использования systemd-analyze blame NetworkManager запускался необычно долго.

Проблема связана с тем, что файл /var/log/journal стал слишком большим. При этом также может уменьшаться скорость работы других команд, например, systemctl status или journalctl. Для решения проблемы можно удалить все файлы из каталога журнала (в идеале — сделав где-нибудь резервные копии, хотя бы временно), а затем ограничить размер журнала.

systemd-tmpfiles-setup.service не запускается во время загрузки

Начиная с версии Systemd 219, /usr/lib/tmpfiles.d/systemd.conf определяет ACL-атрибуты для каталогов в /var/log/journal и, следовательно, требует включённой поддержки ACL для той файловой системы, в которой находится журнал.

Отключение emergency mode на удалённой машине

Вам может понадобиться отключить emergency mode на удалённой машине, например на виртуальных машинах Azure или Google Cloud. Это связано с тем, что в случае ухода системы в emergency mode она отключится от сети и лишит вас возможности подключения к ней.

Для отключения этого режима замаскируйте emergency.service и emergency.target.

Потоки

2023-05-22T18:06:25.837Z

Стандартные потоки

Начнем с основного понятия - терминал. Он уходит корнями в далекое (по компьютерным меркам) прошлое и обозначает собой оконечное устройство, предназначенное для взаимодействия оператора и компьютера, к одному компьютеру может быть присоединено несколько терминалов, каждый из которых работает самостоятельно и независимо от других. Смысл современного терминала, а приложение для работы с командной строкой называется в Linux именно так, не изменился и сегодня, хотя, если быть точными, его название - эмулятор терминала.

Данное приложение все также эмулирует оконечное устройство, предназначенное для взаимодействия пользователя с компьютером. Точно также мы можем запустить сразу несколько терминалов, каждый из которых будет работать независимо. Кроме того, следует понимать, что терминал может быть запущен как локально, так и удаленно, способ подключения к компьютеру может быть разным, но свойства терминала от этого не изменяются.

Работая с терминалом нам нужно каким-то образом передавать ему команды и получать результаты. Для этого предназначена консоль - совокупность устройств ввода-вывода обеспечивающих взаимодействие пользователя и компьютера. В качестве консоли на современных ПК выступают клавиатура и монитор, но это только один из возможных вариантов, например, в самых первых моделях терминалов в качестве консоли использовался телетайп. Консоль всегда подключена к текущему рабочему месту, в то время как терминал может быть запущен и удаленно.

Но в нашей схеме все еще чего-то не хватает. При помощи консоли мы вводим определенные команды и передаем их в терминал, а дальше? Терминал - это всего лишь оконечное устройство для взаимодействия с компьютером, но не сам компьютер, выполнять команды или производить какие-либо другие вычисления он не способен. Поэтому на сцену выходит третий компонент - командный интерпретатор. Это специальная программа, обеспечивающая базовое взаимодействие пользователя и ОС, а также дающая возможность запускать другие программы. В большинстве Linux-дистрибутивов командным интерпретатором по умолчанию является bash.

Теперь все становится на свои места. Для каждого сеанса взаимодействия пользователя и компьютера создается отдельный терминал, внутри терминала работает специальная программа - командный интерпретатор. При помощи консоли пользователь передает командному интерпретатору или запущенной с его помощью программе входящие данные и получает назад результат их работы. Осталось разобраться каким именно образом это происходит.

Для взаимодействия запускаемых в терминале программ и пользователя используются стандартные потоки ввода-вывода, имеющие зарезервированный номер (дескриптор) зарезервированный на уровне операционной системы. Всего существует три стандартных потока:

stdin (standard input, 0) - стандартный ввод, по умолчанию нацелен на устройство ввода текущей консоли (клавиатура)
stdout (standard output, 1) - стандартный вывод, по умолчанию нацелен на устройство вывода текущей консоли (экран)
stderr (standard error, 2) - стандартный вывод ошибок, специальный поток для вывода сообщения об ошибках, также направлен на текущее устройство вывода (экран)

Как мы помним, в основе философии Linux лежит понятие - все есть файл. Стандартные потоки не исключение, с точки зрения любой программы - это специальные файлы, которые открываются либо на чтение (поток ввода), либо на запись (поток вывода). Это вызывает очевидный вопрос, а можно ли вместо консоли использовать файлы? Да, можно и здесь мы вплотную подошли к понятию перенаправления потоков.

Перенаправление потоков

Начнем с наиболее простого и понятного - потока вывода. В него программа отправляет результат своей работы, и он отображается на подключенном к консоли устройстве вывода, в современных системах это экран. Допустим мы хотим получить список файлов в директории, для этого мы набираем на устройстве ввода консоли команду:

ls -l dir1

Которая через стандартный поток ввода будет доставлена командному интерпретатору, тот запустит указанную программу и передаст ей требуемые аргументы, а результат вернет через стандартный поток вывода на устройство отображения информации.

Но что, если мы хотим сохранить результат работы команды в файл? Нет ничего проще, воспользуемся перенаправлением, для этого следует использовать знак >.

ls -l dir1 > result

На экран теперь не будет выведено ничего, но весь вывод команды окажется в файле result, который мы можем прочитать следующим образом:

cat result

При таком перенаправлении вывода файл-приемник каждый раз будет создаваться заново, т.е. будет перезаписан. Это очень важный момент, сразу и навсегда запомните > - всегда перезаписывает файл!

Можно ли этого избежать? Можно, для того, чтобы перенаправленный поток был дописан в конец уже существующего файла используйте для перенаправления знак >>.

Немного изменим последовательность команд:

ls -l dir1 > resultls -l dir2 >> result

Теперь в файл попал вывод сразу двух команд, при этом, обратите внимание, первой командой мы перезаписали файл, а второй добавили в него содержимое из стандартного потока вывода.

Пойдем дальше. Как видим в выводе кроме списка файлов присутствуют строки "итого", нам они не нужны, и мы хотим от них избавиться. В этом нам поможет утилита grep, которая позволяет отфильтровать строки согласно некому выражению. Например, можно сделать так:

ls -l dir1 > resultls -l dir2 >> resultgrep rw result > result2

В целом результат достигнут, но ценой трех команд и наличием одного промежуточного файла. Можно ли сделать проще?

До этого мы перенаправляли поток вывода, но тоже самое можно сделать и с потоком ввода, используя для этого знак <. Например, мы можем сделать так:

grep rw < result

Но это ничего не изменит, поэтому мы пойдем другим путем и перенаправим на ввод одной команды вывод другой:

grep rw <(ls -l dir1) <(ls -l dir2)

На первый взгляд выглядит несколько сложно, но обратимся к man по grep:

grep [OPTIONS] PATTERN [FILE][FILE...]

В качестве паттерна мы используем rw, который есть в каждой интересующей нас строке, а в качестве файлов отдаем стандартный файл потока ввода, содержимого которого является результатом работы команды, указанной в скобках. А можно направить результат этой команды в файл? Конечно, можно:

grep rw <(ls -l dir1) <(ls -l dir2) > result

В последней команде мы перенаправили не только потоки ввода, но и поток вывода, при этом нужно понимать, что все перенаправления относятся к первой команде, иначе можно подумать, что в result будет выведен результат работы ls -l dir2, однако это неверно.

Немного особняком стоит стандартный поток вывода ошибок, допустим мы хотим получить список файлов несуществующей директории с перенаправлением вывода в файл, но сообщение об ошибке мы все равно получим на экран.

Почему так? Да потому что вывод ошибок производится в отдельный поток, который мы никуда не перенаправляли. Если мы хотим подавить вывод сообщений об ошибках на экран, то можно использовать конструкцию:

ls -l dir3 > result 2>/dev/null

В данном примере весь вывод стандартного потока ошибок будет перенаправлен в пустое устройство /dev/null.

Но можно пойти и другим путем, перенаправив поток ошибок в стандартный поток вывода:

ls -l dir3 > result 2>&1

В этом случае мы перенаправили поток вывода об ошибках в стандартный поток вывода и сообщение об ошибке не было выведено на экран, а было записано в файл, куда мы перенаправили стандартный поток вывода.

Конвейер

В предыдущих примерах мы научились перенаправлять стандартные потоки ввода-вывода и даже частично коснулись вопроса о направлении вывода одной команды на вход другой. А почему бы и нет? Потоки стандартные, это позволяет использовать вывод одной команды как ввод другой. Это еще один очень важный механизм, позволяющий раскрыть всю мощь Linux в реализации очень сложных сценариев достаточно простым способом.

Для того, чтобы перенаправить вывод одной программы на вход другой используйте знак |, на жаргоне "труба".

Самый простой пример:

dpkg -l | grep gnome

Первая команда выведет список всех установленных пакетов, вторая отфильтрует только те, в наименовании которых есть строка "gnome".

Длинна конвейера ограничена лишь нашей фантазией и здравым смыслом, никаких ограничений со стороны системы в этом нет. Но также в Linuх нет и единственно верных путей, каждую задачу можно решить самыми различными способами. Возвращаясь к получению списка файлов двух директорий мы можем сделать так:

cat <(ls -l dir1) <(ls -l dir2) | grep rw > result

Какой из этих способов лучше? Любой, Linux ни в чем не ограничивает пользователей и предоставляет им много путей для решения одной и той же задачи.

Еще один важный момент, если вы повышаете права с помощью команды sudo, то данное повышение прав через конвейер не распространяется. Например, если мы решим выполнить:

sudo command1 | command2

То первая команда будет выполнена с правами суперпользователя, а вторая с правами запустившего терминал пользователя.

Linux debug

2023-05-22T18:06:14.106Z

Что такое система инициализации

2023-05-22T18:04:39.813Z

Система инициализации — это система в Linux, которая подготавливает к работе операционную систему. Система инициализации запускается ядром как первый процесс в операционной системе. И уже затем, этот первый процесс, запускает все остальные процессы. Также при выключении система инициализации занимается остановкой всех процессов.

Алгоритм загрузки операционной системы я описывал в этой статье.

Систем инициализации много, первой такой системой была SysV, потом для Ubuntu написали Upstart. Но сейчас система инициализации SystemD становится системой инициализации по умолчанию во многих популярных дистрибутивах Linux. В том числе и в Ubuntu 22.04, и в Debian 11.

В этой статье я некоторые примеры выполнял на Debian 11, а другие на Ubuntu 22.04, разницы нет никакой. Единственная разница – это версия SystemD:

Ubuntu 22.04 – Version: 249.11-0
Debian 11 – Version: 247.3-7

Как видите в Ubuntu она поновее.

В первой системе инициализации SysV программа инициализации называлась init, для совместимости в SystemD оставили это название, но init это всего лишь символьная ссылка на systemd.

С помощью утилиты ps мы можем узнать какой процесс в системе является первым, то есть у какого процесса номер равен единице (PID=1).

alex@deb:~$ ps 1

PID TTY STAT TIME COMMAND

1 ? Ss 0:10 /sbin/init

Из вывода мы узнали, что первым процессом в системе является процесс приложения /sbin/init.

Посмотрим, что это за файл:

alex@deb:~$ ls -l /sbin/init

lrwxrwxrwx 1 root root 20 мар 20 22:55 /sbin/init -> /lib/systemd/systemd

Таким образом я подтвердил вам, что /sbin/init это всего лишь символьная ссылка на /lib/systemd/systemd.

Про ссылки я писал здесь.

Основная цель SystemD

Основная цель systemd это ускорение загрузки операционной системы за счет распараллеливания запуска процессов и отложенного запуска.

Распараллеливание достигается одновременным запуском не связанных служб. То есть, если одна служба не зависит от второй и у обоих есть достаточно ресурсов для запуска, то они запускаются одновременно.

Отложенный старт достигается за счет подготовки всего необходимого к запуску службы, но сама служба запускается позже, по требованию. Например, создаются все сокеты для работы службы, но служба запустится только когда к сокету обратятся.

Юниты

Все задачи которые выполняет SystemD описываются в специальных файлах, которые называются юниты (unit). Юниты бывают разных типов, в этом курсе мы рассмотрим только три типа юнитов:

service – описывает сервис (службу) или скрипт, в общем все то что можно запустить;
target – группирует юниты, то есть мы можем объединить две службы и запускать их как одну;
timer – определяет таймер (аналог cron). То есть службы могут запускаться по определённому расписанию, или с задержкой.

Вот примеры юнитов разных типов:

alex@deb:~$ ls -l /lib/systemd/system/ssh.service

-rw-r--r-- 1 root root 538 мар 13 2021 /lib/systemd/system/ssh.service

alex@deb:~$ ls -l /lib/systemd/system/default.target

lrwxrwxrwx 1 root root 16 мар 20 22:55 /lib/systemd/system/default.target -> graphical.target

alex@deb:~$ ls -l /lib/systemd/system/logrotate.timer

-rw-r--r-- 1 root root 191 окт 14 2019 /lib/systemd/system/logrotate.timer

ssh.service – служба ssh сервера, с помощью которого мы удалённо управляем linux системой;
default.target – таргет который запускается при включении системы по умолчанию, при этом запускаются службы у которых настроен автозапуск для этого таргета.
logrotate.timer – таймер, который запускает службу logrotate.service для ротации логов.

Список всех активных юнитов в системе можно посмотреть с помощью следующей команды:

alex@ubu:~$ systemctl list-units

Но так как юнитов слишком много, обычно выводят не все юниты а юниты определённого типа, например:

alex@ubu:~$ systemctl list-units -t service

alex@ubu:~$ systemctl list-units -t timer

alex@ubu:~$ systemctl list-units -t target

Если нужно получить список не только активных юнитов, то просто добавьте опцию all, например:

alex@ubu:~$ systemctl list-units -t target --all

Расположение юнитов

Юниты можно найти в следующих каталогах:

/lib/systemd/system — системные юниты, устанавливаются обычно вместе с приложениями. Они имеют самый низкий приоритет.
/run/systemd/system — динамически создаваемые юниты. Имеют средний приоритет.
/etc/systemd/system — юниты создаваемые вручную. Имеют наивысший приоритет.

alex@s-deb:~$ ls -ld /*/systemd/system

drwxr-xr-x 9 root root 4096 июн 20 15:09 /etc/systemd/system

drwxr-xr-x 19 root root 36864 июн 20 15:09 /lib/systemd/system

drwxr-xr-x 2 root root 40 июл 11 12:50 /run/systemd/system

Если мы создадим юнит в каталоге /etc/systemd/system, и с таким-же именем будет юнит в /lib/systemd/system, то наш созданный юнит будет иметь более высокий приоритет.

Итог

Вот мы и познакомились с системой инициализации SystemD, которая используется в Debian 11 и в Ubuntu 22.04 по умолчанию. В следующих статьях подробнее разберёмся с юнитами, и даже напишем свой сервис и таймер. А затем пробежимся по основным утилитам этой системы.

Узнали новую команду systemctl, с помощью которой в этой статье смотрели список юнитов в системе:

systemctl list-units # все активные юниты

systemctl list-units --all # все юниты (не только активные)

systemctl list-units -t <тип_юнита> # активные юниты определённого типа

systemctl list-units -t <тип_юнита> --all # все юниты определённого типа