DevOps Notes

Хитрое шифрование диска dm-crypt nuke

Thu, 16 Jan 2025 00:00:00 +0000

Введение ¶

Шифрование диска с использованием dm-crypt — это надёжный способ защиты данных. Однако в экстремальных ситуациях может потребоваться мгновенное и необратимое уничтожение ключей шифрования, чтобы данные стали недоступными. Для этого можно использовать механизм nuke, который активируется при вводе специального пароля.

В этой статье рассмотрим, как реализовать nuke в dm-crypt, используя initramfs, cryptsetup и mkpasswd.

Разработанный хук умеет:

Расшифровывать диск используя данные с файла
Если файл не найден, спрашивает пароль
Если пароль это nuke пароль - удаляет все ключи

Важно! У меня это работает на Ubuntu 22.04.5, есть большая вероятность, что на других дистрибутивах нужно будет сделать что-то по другому. В любом случае, вот статья по восcтановлению Grub.

Установка ¶

Я подготовил DEB пакет для простой установки. Качаем и ставим вот такой командой.

1

sudo apt-get install -f dm-nuke.deb

Настройка загрузки ¶

В моём случае, у меня зашифрован / и не зашифрован /boot. Прежде всего, нужно добавить cryptdevice аргумент в /etc/default/grub. UUID можно получить из вывода blkid (берём UUID зашифрованного раздела).

1

GRUB_CMDLINE_LINUX_DEFAULT="... cryptdevice=UUID=bb85fe0a-4ef7-49c4-b15c-fb613d51e9ef:cryptroot"

Теперь, нужно добавить в /etc/crypttab указание использовать таш скрипт.

1

cryptroot UUID=bb85fe0a-4ef7-49c4-b15c-fb613d51e9ef keyfile-path=/dev/mmcblk0,keyfile-offset=8932578598,keyfile-size=11045,nuke=HASH luks,discard,keyscript=decrypt_smart_nuke

Описание аргументов:

cryptroot - имя раздела после расшифровки. В данном случае он появится в системе как /dev/mapper/cryptroot. Должно совпадать с тем, что мы написали в /etc/default/grub.
UUID=bb85fe0a-4ef7-49c4-b15c-fb613d51e9ef - то же, что мы прописали в /etc/default/grub.
Всё третье поле это аргумент к скрипту:
1. keyfile-path=/dev/mmcblk0 - путь к файлу или устройству откуда читать пароль, в моём случае это SD карта
2. keyfile-offset=4194836274 - отступ в байтах от начала файла, если не указано - читать с начала.
3. keyfile-size=7333 - длинна последовательности для чтения, если не указано - читать до конца.
4. nuke=HASH - хеш пароля самоуничтожения.
luks,discard,keyscript=decrypt_smart_nuke - опции для cryptsetup, где мы, среди всего прочего, указываем имя скрипта для получения пароля.

Замените HASH на хэш пароля, который можно получить вот так.

1

mkpasswd -m sha512crypt --rounds=5000

И keyfile, и nuke опциональны, можно не указывать их и скрипт отработает только на интерактивный ввод.

Файле для считывания ключа ¶

Тут идея в следующем. У меня на ноутбуке есть SD Card Reader, так вот он всегда живёт с заглушкой. Почему бы, подумал я, его не использовать для хранения ключа? Есть два интересных варианта:

Сделать раздел на флешке, но оставить буквально один мегабайт до или после него. Забить случайными данными и использовать этот кусок как ключ - незаметно. Сам раздел использовать с пользой.
Забить всю флешку случайными данными и использовать случайный адрес и длину последовательности.

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

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

/dev/disk/by-id/…
/dev/disk/by-uuid/…
/dev/disk/by-label/…

У меня просто SD Card Reader один физически и больше не планируется.

Обновление `initramfs` ¶

После внесения всех изменений обновите initramfs и grub.

1
2


sudo update-initramfs -u
sudo update-grub2

Итог ¶

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

Кроме того, система будет расшифровываться сама, а если нужно куда-то поехать с ноутбуком, то флешку можно вытащить и он будет спрашивать пароль.

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

1

sudo cryptsetup luksHeaderBackup /dev/sda1 --header-backup-file ./backup.luks

Подписываем Git коммиты

Tue, 10 Dec 2024 00:00:00 +0000

Как настроить подпись коммитов и тегов в Git с помощью GPG и SSH ¶

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

Основной файл конфигурации Git ¶

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

Пример базового файла конфигурации:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# ~/.gitconfig
[user]
 name = John Smith

[commit]
 gpgsign = true

[tag]
 gpgSign = true

[includeIf "gitdir:~/Personal/"]
 path = ~/Personal/.gitconfig

[includeIf "gitdir:~/Work/"]
 path = ~/Work/.gitconfig

С помощью директив [includeIf] Git будет подключать нужные конфигурации в зависимости от расположения репозитория.

Конфигурация для личных проектов ¶

Если Вы используете SSH для подписи в личных проектах, настройка будет выглядеть следующим образом. В конфигурационном файле ~/Personal/.gitconfig задаётся личный email, а формат подписи указывается как ssh. Команда, прописанная в настройках, позволяет Git автоматически находить нужный ключ в ssh-agent.

1
2
3
4
5
6
7
8
9


# ~/Personal/.gitconfig
[user]
 email = personal@a.com

[gpg]
 format = ssh

[gpg "ssh"]
 defaultKeyCommand = sh -c "ssh-add -L | awk '$3~/^personal@a\\.com$/{print \"key::\"$0}'"

Эта настройка позволяет использовать ключ, уже добавленный в ssh-agent, что упрощает процесс подписи.

Конфигурация для рабочих проектов ¶

Для рабочих проектов часто используется GPG. В конфигурации ~/Work/.gitconfig указывается рабочий email и идентификатор GPG-ключа, который будет использоваться для подписи.

Если у Вас ещё нет GPG-ключа, его можно создать с помощью команды:

1

gpg --full-gen-key

Для получения идентификатора ключа выполните:

1

gpg --list-keys

Пример файла конфигурации для рабочих проектов:

1
2
3
4
5
6
7


# ~/Work/.gitconfig
[user]
 email = company@b.com
 signingKey = 35C1A64CD7FC0AB6EB66756B2445463C3234ECE1

[gpg]
 format = openpgp

С помощью этого файла рабочие коммиты и теги будут подписаны с использованием указанного GPG-ключа.

Теперь Ваш Git настроен на автоматическое использование нужного ключа в зависимости от репозитория. Это поможет Вам поддерживать порядок и прозрачность при работе с коммитами и тегами.

Kubernetes Node role labeler

Tue, 08 Oct 2024 00:00:00 +0000

Описание ¶

Node Role Labeler давно руки чесались написать, примитивнейший оператор, но задачу выполняет. Проблема в том, что Kubernetes, а именно kubelet, не может назначить себе самому при создании узла label node-role.kubernetes.io/ROLE_NAME, потому что kubernetes.io защищённый префикс. Очень не удобно.

Вот у меня Karpenter, или Cluster Autoscaler, да не важно, я хочу чтобы узлы сразу были с красивыми ролями, а из коробки так не получается, только руками. Теперь можно навесить node-role.cluster.local/NAME и оператор создаст копию с доменом kubernetes.io автоматически. В обратную сторону тоже работает. Подробнее - читайте на GitHub.

Демо ¶

Karpenter конфигурация ¶

Вот таким образом можно сразу навешивать labels на узлы Karpenter-a.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97


apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
 name: private
spec:
 amiFamily: AL2
 metadataOptions:
 httpEndpoint: enabled
 httpProtocolIPv6: disabled
 httpPutResponseHopLimit: 2
 httpTokens: required
 role: Karpenter-development-role
 securityGroupSelectorTerms:
 - tags:
 karpenter.sh/discovery: development
 subnetSelectorTerms:
 - tags:
 karpenter.sh/discovery/development/subnet: private
 tags:
 karpenter.sh/discovery: development
---
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
 name: on-demand-amd64
spec:
 disruption:
 budgets:
 - nodes: 20%
 - nodes: "5"
 - duration: 20h
 nodes: "0"
 schedule: 0 5 * * *
 consolidationPolicy: WhenUnderutilized
 expireAfter: 720h
 limits:
 cpu: "200"
 memory: 400Gi
 template:
 metadata:
 labels:
 node-role.cluster.local/on-demand-amd64: ""
 spec:
 nodeClassRef:
 name: private
 requirements:
 - key: kubernetes.io/arch
 operator: In
 values:
 - amd64
 - key: node.kubernetes.io/instance-type
 operator: In
 values:
 - r5a.4xlarge
 - r5a.2xlarge
 - r5a.xlarge
 - r5a.large
 - r5a.medium
 - r5.4xlarge
 - r5.2xlarge
 - r5.xlarge
 - r5.large
 - r5.medium
 - m6i.4xlarge
 - m6i.2xlarge
 - m6i.xlarge
 - m6i.large
 - m6i.medium
 - m5a.4xlarge
 - m5a.2xlarge
 - m5a.xlarge
 - m5a.large
 - m5a.medium
 - m5.4xlarge
 - m5.2xlarge
 - m5.xlarge
 - m5.large
 - m5.medium
 - c6a.4xlarge
 - c6a.2xlarge
 - c6a.xlarge
 - c6a.large
 - c6a.medium
 - c6.4xlarge
 - c6.2xlarge
 - c6.xlarge
 - c6.large
 - c6.medium
 - t3a.4xlarge
 - t3a.2xlarge
 - t3a.xlarge
 - t3a.large
 - t3a.medium
 - key: karpenter.sh/capacity-type
 operator: In
 values:
 - on-demand

BTRFS checksum benchmark

Sun, 30 Jul 2023 00:00:00 +0000

Введение ¶

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

Тело ¶

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

Попал на утилиту rhash, у которой есть ключ --speed ним то я и попробовал замерять производительность, но результаты у blake2b и crc32c были практически идентичны, что показалось странным. В итоге пришёл к вот такому скрипту.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


#!/usr/bin/env bash
set -eo pipefail

TMPFS="$(mktemp -d)"
SIZE="5G"

mount -t tmpfs -o size="${SIZE}" tmpfs "${TMPFS}"
cd "${TMPFS}"
fallocate -l 4GiB btrfs

for CSUM in crc32c xxhash sha256 blake2; do
 mkfs.btrfs -f -d single -m single --csum "${CSUM}" btrfs
 mount btrfs /mnt
 echo "
 cd /mnt
 echo "info: ${CSUM}"
 dd if=/dev/urandom of=test bs=4M count=1024 2>/dev/null
 rm -f test
 for i in {1..1000}; do
 dd if=/dev/urandom of="\$i" bs=4M count=1 2>/dev/null
 done
 rm -f /mnt/*
 " | /usr/bin/time bash
 umount /mnt
done

umount "${TMPFS}"
rm -rf "${TMPFS}"

Что здесь происходит?

Создаётся tmpfs временная точка монтирования на 5 ГБ (прямо в оперативной памяти, чтобы не зависет от SSD/HDD)
Создаётся внутри файл на 4 ГБ и по очереди форматируется в BTRFS с разными алгоритмами хеширования
Для каждого алгоритма выполняется запись файлов в двух режимах
1. Один большой файл на 4 ГБ
2. 1000 файлов по 4 МБ
По итогу команда time выводит время выполнения скрипта

Так вот на моём 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz лучший результат показал старый, добрый crc32c (~35 секунд), а остальные были по ~52 секунды.

Redis Migration Script

Sun, 25 Jun 2023 00:00:00 +0000

Старый способ ¶

Иногда нужно мигрировать данные из одного Redis в другой, или между базами другого. Ранее, я мог перенести данные с сервера на сервер только через полный бекап, но это не позволяет мигрировать данные между базами. Всё равно, приведу здесь этот алгоритм.

Зайти в исходный Redis и сделать Save

1
2
3


REDISCLI_AUTH="password"
redis-cli CONFIG GET DIR
redis-cli SAVE

Первая команда выведет путь к папке, где будет лежать дамп.

Добавить к целевому Redis аргументы для отключения AppendOnly и перезапустить его

1
2


--dbfilename dump.rdb
--appendonly no

Скопировать дамп в целевой Redis и выполнить его загрузку

1
2


REDISCLI_AUTH="password"
redis-cli BGREWRITEAOF

Перевести целевой Redis в AppendOnly режим убрав ранее добавленные ключи

Зачем мигрировать данные между базами?

В старом кластере у меня два сервиса, у каждого свой Redis. В любом Redis есть по умолчанию 16 баз, почему бы не использовать №0 для сервиса А и №2 - для сервиса Б? Вот тут то ты и сталкиваешься с задачей миграции из базы в базу.

Новый способ ¶

Основан на MIGRATE. Скрипт представлен ниже. Преимущества этого способа - тоже.

Можно мигрировать между базами
Не нужно перезапускать Redis-ы
Не нужно копировать бекапы
Есть проверка после переноса путём вычисления хеш суммы учитывая так же и содержимое ключей

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


#!/usr/bin/env sh
set -e

SRC_HOSTNAME='source-redis-hostname'
SRC_PORT='6379'
SRC_PASSWORD='password'
SRC_DATABASE='0'
DEST_HOSTNAME='destination-redis-hostname'
DEST_PORT='6379'
DEST_PASSWORD='password'
DEST_DATABASE='1'

main() {
 migrate | xargs -0 printf 'migration status: %s'
 CHECKSUM="$(mktemp)"
 hash --no-auth-warning -h "${SRC_HOSTNAME}" -p "${SRC_PORT}" \
 -a "${SRC_PASSWORD}" -n "${SRC_DATABASE}" | tee "${CHECKSUM}" | xargs -0 printf 'source checksum: %s'
 CHECKSUM_VERIFY="${CHECKSUM}" hash --no-auth-warning -h "${DEST_HOSTNAME}" -p "${DEST_PORT}" \
 -a "${DEST_PASSWORD}" -n "${DEST_DATABASE}" | xargs -0 printf 'target checksum validation: %s'
 rm -f "${CHECKSUM}"
}

hash() {
 EXTRA_ARGS="${@}"
 redis-cli ${EXTRA_ARGS} --raw --scan | \
 sed -r 's/"/\\"/g; s/^(.+)$/GET "\1"/g;' | \
 redis-cli ${EXTRA_ARGS} | sort | \
 if [ -f "${CHECKSUM_VERIFY}" ]; then
 sha256sum -c "${CHECKSUM_VERIFY}"
 else
 sha256sum -
 fi
}

migrate() {
 AUTH="--no-auth-warning -h ${SRC_HOSTNAME} -p ${SRC_PORT} -a ${SRC_PASSWORD} -n ${SRC_DATABASE}"
 redis-cli ${AUTH} --raw --scan | \
 tr '\n' '\0' | \
 xargs -0 redis-cli ${AUTH} \
 MIGRATE "${DEST_HOSTNAME}" "${DEST_PORT}" "" "${DEST_DATABASE}" 5000 \
 COPY REPLACE AUTH "${DEST_PASSWORD}" KEYS
}

main

Мой опыт с Git

Sun, 18 Jun 2023 00:00:00 +0000

Введение ¶

Часто используемые мною команды и пояснения к ним. Надеюсь будет кому-то так же полезно как и мне.

Основное ¶

В Git есть встроенный графический интерфейс ¶

Gitk - простой встроенный графический интерфейс. Мне очень нравится из-за своей точности и наглядности. Я стараюсь не пользоваться какими-либо Git UI и всё делаю командами, а эта и так работает только в режиме просмотра.

Дерево коммитов с тегами и ветками
Хеш выбранного коммита из дерева
Список изменённых файлов в этом коммите
Переключатель режима diff
Сам diff из коммита с его описанием в начале

На Manjaro кроме самого Git, нужно поставить ещё и tk, тогда заработает. Как на других дистрибутивах - не знаю.

1

pacman -Sy git tk

Как обновлять настройки окружений основываясь на diff-е нового окружения ¶

Тут вот какой момент. У меня в инфраструктурном репозитории есть, к примеру, values для Helmfile окружений Development и Production.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


.
├── development
│ ├── main.yaml
│ └── values
│ ├── cert-manager.yaml.gotmpl
│ ├── external-secrets.yaml.gotmpl
│ ├── fluentbit.yaml.gotmpl
│ ├── kube-prometheus-stack.yaml.gotmpl
│ ├── loki.yaml.gotmpl
│ └── promtail.yaml.gotmpl
└── production
 ├── main.yaml
 └── values
 ├── cert-manager.yaml.gotmpl
 ├── external-secrets.yaml.gotmpl
 ├── fluentbit.yaml.gotmpl
 ├── kube-prometheus-stack.yaml.gotmpl
 ├── loki.yaml.gotmpl
 └── promtail.yaml.gotmpl

5 directories, 14 files

И вот разрабатывал я разрабатывал новые приложения, менял настройки в development и теперь мне нужно всё то же самое перенести в production. Чтобы не вспоминать все мелочи где что нужно поменять делаю следующее.

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

1

git checkout development

Смотрим когда последний раз менялся production

1

git log -n 1 --oneline -- ./production

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

Смотрим изменения с этого момента и по сей день

Теперь нам нужно отследить все изменения с момента последней версии production по текущий момент, который является актуальным development.

1

git diff 493d3aa..HEAD -- ./development

Хеш 493d3aa это тот самый, который я получил в прошлом пункте для production.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


diff --git a/development/values/cert-manager.yaml.gotmpl b/development/values/cert-manager.yaml.gotmpl
index 493d3aa..cb34bd2 100644
--- a/development/values/cert-manager.yaml.gotmpl
+++ b/development/values/cert-manager.yaml.gotmpl
@@ -34,7 +34,8 @@ asdf:
 alpha: cert-manager-a
 contextKey:
 beta: something-else
- key: json
+ someSetting:
+ subkey: cert-manager-example
 urls:
 api: {{ quote .Values.apiURL }}
 web: {{ quote .Values.webURL }}

Таким образом, мы теперь можем в ручном режиме перенести все интересующие нас изменения в production и ничего не потерять.

Как искать пароли и чувствительные данные используя поиск по коммитам ¶

У Git есть встроенный поиск по файлам в коммитах. Можно использовать регулярные выражения для поиска секретный данных. Это применимо в отдельных ручных операциях, но намного правильнее будет настроить и постоянно иметь Gitleaks или Trivy.

1
2


git rev-list --all | \
xargs git grep -irnE '"type":\s*"service_account"'

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

Rebase стратегии ¶

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

Убеждаемся, что наша локальная ветка (которую мы будем rebase-ить) запушена и такая же как в облаке

Для чего это нужно? Для самоконтроля. К примеру, у меня задача сделать rebase development ветки на main да так, чтобы она не поменялась, просто перенести. Если на момент начала переноса я проверил, что diff-a origin/development у меня нет, то после переноса, я смогу сравнить git diff origin/development..development и там так же должно быть пусто.

1
2


git pull
git push

Выполняем одну из операций ниже

1
2


git rebase -i --strategy=ort -Xtheirs main --empty=keep
git rebase -i --strategy=ort -Xours main --empty=keep

Git разрешит все конфликты в пользу одной из веток, в зависимости от ours или theirs.

Как сбросить локальную ветку до состояния облачной, если кто-то пушил с форсом ¶

Тут всё довольно просто. К примеру, мы работаем на development.

Переходим на ветку

1

git checkout development

Делаем git fetch

1

git fetch --all

Делаем reset

1

git reset --hard origin/development

Всё, наша ветка точно такая как облаке.

Kubernetes in Docker

Mon, 12 Jun 2023 00:00:00 +0000

Введение ¶

Частенько бывает, что нужен Kubernetes под рукой для быстрого запуска чего-то.

Отладить самописный Helm чарт
Спросить что-то у kubectl explain
Проверить какие-то настройки

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

Minikube - один из старейших, так сказать. Столкнулись с тем, что стандартная инсталяция kube-prometheus-stack на нём просто не завелась, а на следующем - с ходу.
k3s - один из трёх движков от Rancher. Отличная вещь, использовал и использую на проде небольших проектов. Так же, у меня два личных кластера именно на k3s, но он тоже не ванильный, всё собрано в один бинарь. Это и хорошо, и плохо. Очень легковесный и легко устанавливается, но нарвался на то, что он ломал мне Wireguard VPN своими правилами IPTables. Пришлось поменять Wireguard FwMark на 0x8000 и всё заработало.
rke - ещё один из трёх движков. Первый из движков от Rancher. Очень классный, а особенно тем, что под него есть Terraform Module - кайф. Уже более похож на ванильную инсталяцию.
rke2 - rke + k3s. Тут всё собрано в один бинарь, но apiserver, scheduler etc. всё ещё видны как отдельные поды. Пробовал его, жаль, что нет поддержки из Terraform как у rke. Не понравился, на практике оказался менее стабильным чем k3s, или у меня просто руки кривые.
Microk8s - от Canonical, не пробовал.
k0s - то же самое, как по мне, что k3s, только сообщество меньше и документация хуже, а так - хорош.
kind - гвоздь программы сегодня. Про него поподробнее.

kind ¶

Почему хочу рассказать о нём. Это самый ванильный из всех способ для получения Kubernetes локально. У него масса плюсов.

Есть возможность подкинуть конфиг
Создаёт Kubernetes в Docker
Можно создать больше одного узла!
Под коробкой использует ванильный kubeadm!
Все конфиги, пути и форматы - стандартный kubeadm!
Он не лезет в iptables на хосте

Из минусов.

Control-plane ест в состоянии простоя 900 MiB RAM с ходу
Нужно выбрасывать порты с узлов на хост

Вот пример конфига kind

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
 extraMounts:
 - hostPath: /home/bzm/projects/kind/
 containerPath: /host
 kubeadmConfigPatches:
 - |
 kind: InitConfiguration
 nodeRegistration:
 kubeletExtraArgs:
 seccomp-default: "true"
 apiServer:
 extraArgs:
 enable-admission-plugins: NodeRestriction
- role: worker
 extraPortMappings:
 - containerPort: 80
 hostPort: 80
 listenAddress: "127.0.0.1"
 - containerPort: 443
 hostPort: 443
 listenAddress: "127.0.0.1"

То есть, можно на одном компьютере, поднять кучу узлов и всё в контейнерах. Конфиги и настройки все - как в официальной документации. Нужно попробовать какие-то ключи к api-server - пожалуйста, нужно отточить что-то по безопасности - легко. Мне очень понравился.

Redis Sentinel Watchdog

Fri, 09 Jun 2023 00:00:00 +0000

Введение ¶

Очень люблю чарты от Bitnami, хорошо написаны и довольно стабильны. Среди прочего, всегда ставлю Redis из их чарта. Всё бы хорошо, когда тебе нужен просто Redis без всякого там High Availability, но так бывает не всегда.

В чём сложность поднять Redis HA?

Тут дело в том, что драйверы подключения к Redis в сервисах-клиентах должны поддерживать Redis Sentinel. Когда мы поднимаем кластер с Redis, так же поднимается по контейнеру с Sentinel - это своего рода контроллер для кластера, который сделает замену мастера если текущий пропадёт. Очень похоже на Mongo Arbiter. Так вот механизм подключения из-за этого самого Sentinel меняется.

Подключаемся к Sentinel
Запрашиваем адрес мастера
Подключаемся к мастеру
Если мастер недоступен - опять идём к Sentinel

Очень часто приложения такое не поддерживают. Что же делать в таком случае? Я решил что мне поможет, как всегда, инкостыляция.

Ниже представлен фрагмент values.yaml, с которыми я запускаю bitnami/redis используя Helmfile.

Что там происходит?

Среди прочего, я создаю дополнительный sidecar контейнер, который каждые N секунд запрашивает у Sentinel адрес мастера и если он отличается от такового в созданном Service типа ExternalName - обновляет сервис. Таким образом, мы можем просто направить приложения, которые с Sentinel не умеют общаться, на этот сервис и всё будет работать, так как сервис всегда будет указывать на правильный под.

Потребляет такой sidecar контейнер ~65 mCPU и 1 MiB. Можно конечно собрать образ и включить туда redis-cli чтобы подключаться напрямую, но неохота поддерживать и хранить этот образ, обновлять его.

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132


# ┬─┐┬─┐┬─┐o┐─┐
# │┬┘├─ │ ││└─┐
# ┘└┘┴─┘┘─┘┘──┘

{{- $name := "redis" }}
{{- $masterServiceName := printf "%s-master" $name }}
nameOverride: {{ $name }}
fullnameOverride: {{ $name }}
architecture: replication
auth:
 enabled: true
 password: {{ quote .Values.secrets.redisPassword }}

replica:
 replicaCount: 3
 resources:
 limits:
 memory: 75Mi
 requests:
 cpu: 50m
 memory: 25Mi
 persistence:
 enabled: true
 storageClass: standard
 size: 1Gi
 podAntiAffinityPreset: hard
 sidecars:
 - name: master-service-watchdog
 image: '{{`{{ printf "bitnami/kubectl:%s.%s" .Capabilities.KubeVersion.Major .Capabilities.KubeVersion.Minor }}`}}'
 imagePullPolicy: IfNotPresent
 command: ["/bin/sh", "-ec"]
 args:
 - |
 while sleep 5; do
 MASTER_ADDRESS="$(kubectl exec -c sentinel "${POD_NAME}" -- sh -c "REDISCLI_AUTH='$REDISCLI_AUTH' redis-cli -p '${REDIS_SENTINEL_PORT}' SENTINEL get-master-addr-by-name this" | head -1)"
 if ! kubectl get svc "${MASTER_SERVICE}" -o jsonpath='{.spec.externalName}' | grep -qF "${MASTER_ADDRESS}"; then
 echo "info: master address has changed to ${MASTER_ADDRESS}"
 jq -Mnr --arg address "${MASTER_ADDRESS}" '[{op:"replace",path:"/spec/externalName",value:$address}]' | \
 xargs -0 kubectl patch svc "${MASTER_SERVICE}" --type=json --patch
 fi
 done
 env:
 - name: MASTER_SERVICE
 value: {{ quote $masterServiceName }}
 - name: POD_NAME
 valueFrom:
 fieldRef:
 fieldPath: metadata.name
 - name: REDISCLI_AUTH
 valueFrom:
 secretKeyRef:
 name: '{{`{{ template "common.names.fullname" . }}`}}'
 key: redis-password
 - name: REDIS_SENTINEL_PORT
 value: '{{`{{ .Values.sentinel.containerPorts.sentinel }}`}}'
 resources:
 limits:
 cpu: 100m
 memory: 50Mi
 requests:
 cpu: 100m
 memory: 50Mi
 securityContext:
 readOnlyRootFilesystem: true
 runAsNonRoot: true
 runAsUser: 1000
 privileged: false
 allowPrivilegeEscalation: false
 capabilities:
 drop: [ALL]
 seccompProfile:
 type: RuntimeDefault

serviceAccount:
 create: true

sentinel:
 enabled: true
 masterSet: this
 automateClusterRecovery: true
 downAfterMilliseconds: 2000
 resources:
 limits:
 memory: 50Mi
 requests:
 cpu: 50m
 memory: 50Mi

networkPolicy:
 enabled: true
 extraIngress:
 - ports:
 - port: 6379
 from:
 - namespaceSelector:
 matchLabels:
 kubernetes.io/metadata.name: {{ .Release.Namespace }}

rbac:
 create: true
 rules:
 # Allow watchdog update our service
 - apiGroups: [""]
 resources: ["services"]
 verbs: ["get", "update", "patch"]
 resourceNames: [{{ quote $masterServiceName }}]
 # Allow exec into Redis pods
 - apiGroups: [""]
 resources: ["pods/exec"]
 verbs: ["create"]
 - apiGroups: [""]
 resources: ["pods"]
 verbs: ["get", "list"]
pdb:
 create: true

raw:
 Service:
 apiVersion: v1
 kind: Service
 metadata:
 name: {{ $masterServiceName }}
 spec:
 type: ExternalName
 # 1.1.1.1 is just a stub value that is used for initial deployment
 # It will be overridden as soon as first watchdog will be ready
 externalName: 1.1.1.1
 ports:
 - port: 6379
 protocol: TCP
 targetPort: 6379
 name: redis

Timeshift BTRFS бекапы на Manjaro

Sun, 01 Jan 2023 00:00:00 +0000

Введение ¶

Timeshift инструмент просто обалденный! Помогает делать автоматические бекапы системы. Можно и вручную делать, если очень хочется. Поддерживает он работу в двух режимах.

Копирование куда-то rsync-ом, с хитрым линкованием, чтобы место экономить по максимуму
Использование BTRFS snapshot

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

Требования к системе ¶

Часть, описана на главной странице репозитория, но есть ещё и то, что я нашёл сам.

Подраздел по умолчанию для файловой системы BTRFS должен быть /

Когда монтируешь раздел с BTRFS куда либо без указания опции монтирования subvol=… должен монтироваться именно корень, иначе программа падает. Вот скрипт, который это проверяет и ставит правильно.

1
2
3
4


MP="$(mktemp -d)"
mount | awk '/on \/ type btrfs/{print $1}' | sudo xargs -I{} mount {} "$MP" && \
sudo btrfs subvolume set-default 5 "$MP"; \
sudo umount "$MP"

В /etc/fstab корневой раздел системы должен быть прописан корректно

Та самая опция subvol=… должна быть установлена в @ или /@, не важно. Вот этот скрипт подскажет прописано ли у Вас всё верно.

1
2
3
4
5
6


grep -E '^[^#].+/\s+btrfs' /etc/fstab | \
grep -oE 'subvol=[^,]+' | \
cut -d= -f2 | \
grep -qE '^/?@$' && \
echo 'OK' || \
echo 'Not OK'

Как работает ¶

При установке любого пакета через pamac или yay, в моём случае, timeshift срабатывает автоматически, если в /etc/timeshift-autosnap.conf не прописано его пропускать.

Удобный и красочный ZSH с p10k

Sun, 25 Dec 2022 00:00:00 +0000

Введение ¶

Ранее, я уже описывал мой опыт с ZSH здесь. Сейчас всё немного иначе, я полностью перешёл на Powerlevel10k.

Это очень красивый и удобный обвес, который просто ставится и настраивается на ходу.

Настройка p10k ¶

Настроить p10k можно очень просто, прямо на ходу, хоть по 10 раз на дню.

1

p10k configure

Установку самого p10k я зашил прямо в .zshrc, по этому, можно даже не следовать официальным инструкциям на сайте. Ну почти. Есть ещё рекомендованные шрифты, чтобы всё точно было красиво, описано вот здесь. Ниже, я записал и показал как выглядит настройка самого p10k. Вот только, в записи asciinema всё красивости квадратиками, не поддерживаются эти символы в записи, к сожалению. По этому, вот скриншот терминального окна.

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

Объяснение моего .zshrc ¶

Всё написанное далее это куски самого .zshrc, которые можно скачать в конце статьи. Для вашего удобства, продублирую ссылку ещё и здесь.

Установка p10k ¶

Выполнено это простым условием и прямым стягиванием из GitHub. Если у нас есть Git и ещё не стоит p10k - можем склонировать.

1
2
3
4


if command -v git >/dev/null && [ ! -d ~/powerlevel10k ]; then
 echo "info: installing p10k"
 git clone --depth 1 --single-branch https://github.com/romkatv/powerlevel10k.git ~/powerlevel10k
fi

Плагины ¶

Плагины ставлю просто, тоже клонированием из GitHub. Добавил комментарии прямо в код для пояснения происходящего.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


# if we have git installed
if command -v git >/dev/null; then
 # and folder with plugins is absent
 if [ ! -d /usr/share/zsh/plugins ]; then
 # let's create it with sudo
 sudo mkdir -p /usr/share/zsh/plugins
 fi
 # and jump in
 cd /usr/share/zsh/plugins
 # now, let's read every line between <<EOF and EOF lines below
 while IFS= read -r REPO; do
 # and for every line, which will be available in variable named REPO
 # let's cut only last part of the url (ex: zsh-autosuggestions.git) and save to BASENAME var
 BASENAME="$(basename "$REPO")"
 # now, we will remove .git from the end of BASENAME and check either such folder exists
 if [ ! -d "${BASENAME%.git}" ]; then
 # if not, let's print an info message
 echo "${REPO}: Cloning to $(pwd)/${BASENAME%.git}"
 # and finally clone that plugin
 sudo git clone --depth 1 --single-branch "$REPO"
 fi
 done <<EOF
https://github.com/zsh-users/zsh-history-substring-search.git
https://github.com/zsh-users/zsh-syntax-highlighting.git
https://github.com/zsh-users/zsh-autosuggestions.git
EOF
 # after all plugins cloned, we cd back to the location we were
 cd - >/dev/null
fi
# okay, now we assume that all plugins are cloned and we have to include them
# once again, for every hardcoded path to .zsh file
while IFS= read -r SOURCE; do
 # we skip the plugin if it starts with '#' (commented out)
 if echo "$SOURCE" | grep -qE '^#'; then
 continue
 elif [ -s "$SOURCE" ]; then
 # if it is enabled, we just include it in current shell session with source command
 source "$(realpath "$SOURCE")"
 fi
done <<EOF
/usr/share/zsh/plugins/zsh-history-substring-search/zsh-history-substring-search.zsh
/usr/share/zsh/plugins/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh
/usr/share/zsh/plugins/zsh-autosuggestions/zsh-autosuggestions.zsh
EOF

Добавление путей в PATH ¶

Часто бывает, что дополнительные бинарники мы ставим в нестандартные папки. У меня, к примеру, ~/.local/bin используется для всяких kubectl, helm, k9s и другого. Вот тут мы для каждой папочки, если она конечно есть, выполняем проверку и включаем её в переменную PATH.

1
2
3
4
5
6
7
8
9


while IFS= read -r P; do
 if [ -d "$P" ]; then
 export PATH="${P}:${PATH}"
 fi
done <<EOF
${HOME}/.local/share/gem/ruby/3.0.0/bin
${HOME}/projects/stm32/gcc-arm-none-eabi-10.3-2021.10/bin
${HOME}/.local/bin
EOF

Алиасы ¶

Ну тут всё понятно, много всяких алиасов.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


alias ..="cd .. && ls -lhA --color=auto"
alias d='sudo -E docker'
alias dc="docker-compose"
alias e="exit"
alias j="sudo journalctl"
alias l="ls -lh --color=always"
alias la="ls -lhA --color=always"
alias p="ping 8.8.8.8"
alias please='sudo'
alias reborn="sudo shutdown -r now"
alias s='sudo'
alias sctl="sudo systemctl"
alias svi="sudo vim"
alias svim="sudo vim"
alias t='terraform'
alias k="kubectl"
alias kd="kubectl describe"
alias kg="kubectl get"
alias ky="kubectl get -o yaml"
alias ke='kubectl exec -it'
alias vi="vim"
alias g="git"
alias b="sudo btrfs"
alias c="code ."
alias ansible-time="time ansible-playbook"

Git config ¶

К слову, у меня ж ещё есть и Git config. Ссылка тут или то же самое в конце страницы. Из интересного тут две команды.

git ps - пушит ветку, а если её ещё нет, ловит сообщение из лога ошибки git-а и пушит с –set-upstream
git dpush (dummy push) - добавляет в коммит все файлы и папки, пишет стандартное сообщение к комиту и пушит
git cc - просто делает коммит со стандартным сообщением

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


[alias]
co = checkout
a = add .
ci = commit
cc = commit -m 'Nothing special. Just regular commit.'
ps = ! sh -c 'git push >/tmp/git-ps 2>&1 || grep -- \"git push --set-upstream\" /tmp/git-ps | sh'
pt = push --tags
pts = ! sh -c 'git push && git push --tags'
pl = pull
st = status
br = branch
hist = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short
type = cat-file -t
dump = cat-file -p
dpush = ! sh -c 'git add . && git commit -m \"Nothing special. Just regular commit.\"' && git push

KUBECONFIG ¶

Тут ищется стандартный kubeconfig для k3s или rke2 и прописывается в KUBECONFIG.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


# if there is no file at the path that is already being set in KUBECONFIG var
if [ -z "$KUBECONFIG" ]; then
 # for every filepath from the list below
 while IFS= read -r K; do
 # check if file exists and it is not empty
 if [ -s "$K" ]; then
 # change owner and group to current user
 if ! stat -c '%u:%g' "$K" | grep -qF "$(id -u):$(id -g)"; then
 sudo chown "${USER}:${USER}" "$K"
 echo "info: chown $K"
 fi
 echo "info: selecting $K as kubeconfig"
 # and select as default KUBECONFIG
 export KUBECONFIG="$K"
 fi
 done << EOF
/etc/rancher/rke2/rke2.yaml
/etc/rancher/k3s/k3s.yaml
EOF
# last listed path wins
fi

Автоматическая загрузка утилит ¶

Тут, значится, происходит следующее: .zshrc сам следит за тем, чтобы у нас были установлены бинарники утилит, которые мы используем. Если утилиты нет вообще, он её качает, если нет - ничего не делает, но я вручную могу обновить k9s выполнив _update_k9s. Здесь ставятся такие вещи.

k9s - подробнее в моей статье
kubepug - утилита для проверки устаревших API в кластере перед обновлением версии самого Kubernetes
kubecolor - обёртка над kubectl для разноцветного вывода

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55


_update_kubepug() {
 mkdir -p ~/.local/bin
 LOCATION="$(curl --connect-timeout 1 -sS https://github.com/rikatz/kubepug/releases/latest -D- | awk '/^location:/{print $2}')"
 LATEST_VERSION="$(echo "$LOCATION" | awk -F/ '{print $NF}' | grep -oE '[0-9a-zA-Z_.-]+')"
 if ! k9s version --short | grep -qF "$LATEST_VERSION"; then
 printf "Updating kubepug to %s\n" "$LATEST_VERSION"
 printf 'https://github.com/rikatz/kubepug/releases/download/%s/kubepug_linux_%s.tar.gz' \
 "$LATEST_VERSION" "$(uname -p | sed 's/unknown/amd64/g' | tr -d '[[:space:]]')" | \
 xargs curl -sSL | \
 tar -xpzf - kubepug
 install kubepug ~/.local/bin/kubepug -m 0755
 rm -f kubepug
 fi
}
if ! command -v kubepug &>/dev/null; then
 _update_kubepug
fi

_update_k9s() {
 mkdir -p ~/.local/bin
 LOCATION="$(curl --connect-timeout 1 -sS https://github.com/derailed/k9s/releases/latest -D- | awk '/^location:/{print $2}')"
 LATEST_VERSION="$(echo "$LOCATION" | awk -F/ '{print $NF}' | grep -oE '[0-9a-zA-Z_.-]+')"
 if ! k9s version --short | grep -qF "$LATEST_VERSION"; then
 printf "Updating k9s to %s\n" "$LATEST_VERSION"
 printf 'https://github.com/derailed/k9s/releases/download/%s/k9s_Linux_%s.tar.gz' \
 "$LATEST_VERSION" "$(uname -p | sed 's/unknown/x86_64/g' | tr -d '[[:space:]]')" | \
 xargs curl -sSL | \
 tar -xpzf - k9s
 install k9s ~/.local/bin/k9s -m 0755
 rm -f k9s
 fi
}
if ! command -v k9s &>/dev/null; then
 _update_k9s
fi

_update_kubecolor() {
 mkdir -p ~/.local/bin
 LOCATION="$(curl --connect-timeout 1 -sS https://github.com/hidetatz/kubecolor/releases/latest -D- | awk '/^location:/{print $2}')"
 LATEST_VERSION="$(echo "$LOCATION" | awk -F/ '{print $NF}' | grep -oE '[0-9a-zA-Z_.-]+' | sed 's/^v//g')"
 if ! kubecolor --kubecolor-version | grep -qF "$LATEST_VERSION"; then
 printf "Updating kubecolor to %s\n" "$LATEST_VERSION"
 printf 'https://github.com/hidetatz/kubecolor/releases/download/%s/kubecolor_%s_Linux_%s.tar.gz' \
 "v$LATEST_VERSION" "$LATEST_VERSION" "$(uname -p | sed 's/unknown/x86_64/g' | tr -d '[[:space:]]')" | \
 xargs curl -sSL | \
 tar -xpzf - kubecolor
 install kubecolor ~/.local/bin/kubecolor -m 0755
 rm -f kubecolor
 fi
}
if ! command -v kubecolor &>/dev/null; then
 _update_kubecolor
 alias kubectl="kubecolor"
 typeset -g POWERLEVEL9K_KUBECONTEXT_SHOW_ON_COMMAND="${POWERLEVEL9K_KUBECONTEXT_SHOW_ON_COMMAND}|kubecolor"
fi

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

1
2
3
4
5
6


## Completions for 3-d party binaries
for COMMAND in kubectl helm k3d flux kubepug; do
 if command -v "$COMMAND" >/dev/null; then
 source <("$COMMAND" completion zsh)
 fi
done

Раздельные окружения ¶

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

Вот от этого как раз и спасает этот кусок кода.

1
2
3


if [ -f env.sh ]; then
 source ./env.sh
fi

Да всё так просто. А что собственно происходит? Дело в том, что zsh разово, при запуске, проверяет ту папку, в которой он запустился и если там есть файл с точным именем env.sh, то включает его в контекст. Объясняю.

Я использую Ranger для навигации по папкам из терминала. Допустим я работаю на проекте и у меня ещё блог есть. Создал вот такие папочки для проектов.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


.
├── MyBlog
│   ├── env.sh
│   └── kubeconfig.yaml
└── SuperWorkProject
 ├── development
 │   ├── env.sh
 │   └── kubeconfig.yaml
 └── production
 ├── env.sh
 └── kubeconfig.yaml

4 directories, 6 files

На боевом проекте у меня есть два окружения, везде Kubernetes, везде свои раздельные kubeconfig.yaml. Допустим мне нужно поработать на production. В его env.sh я запишу следующее.

1
2
3
4
5
6
7
8


#!/usr/bin/env sh

export KUBECONFIG='~/projects/SuperWorkProject/production/kubeconfig.yaml'
export AWS_PROFILE='production'

pf() {
 nohup sh -c 'kubectl get po -n monitoring -l app.kubernetes.io/name=grafana -o name | xargs -I{} kubectl port-forward {} 3000' 1>/dev/null &
}

Теперь, подключу открыв zsh в этой папке или просто через source ./env.sh. Всё, теперь я точно уверен, что работаю с production. Кроме того, объявил себе функцию для port-forward.

Kubernetes авторизация через OIDC

Thu, 01 Dec 2022 00:00:00 +0000

Введение ¶

Для того, чтобы авторизоваться в Kubernetes через kubeconfig для доступа через kubectl, как правило, используют ServiceAccounts. Их просто проще создать, но это совсем неправильно. Токены от ServiceAccount доступны любому, кто может читать секреты в пространстве имён, где создан ServiceAccount, а значит от Вашего имени можно произвести диверсию. Небезопасненько…

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

Недавно, таки дошли руки попробовать Authentik, а заодно попробовал привязать к нему кластер через настройку API сервера. Оказалось, это даже проще, местами, чем возится с сертификатами для пользователя. Вот об этом всём и разскажу

Доступ через ServiceAccount ¶

Создаём ServiceAccount.

1

kubectl create serviceaccount test

Раньше, до Kubernetes 1.22, автоматически генерировался токен, сейчас его нужно создавать отдельно. Можно сгенерировать временный.

1

kubectl create token test --duration=10m

Можно, по-старинке, получить постоянный, создав для него секрет.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
 name: test-sa-secret
 annotations:
 kubernetes.io/service-account.name: test
type: kubernetes.io/service-account-token
EOF
SA_TOKEN="$(kubectl get -o yaml secret test-sa-secret -o jsonpath='{.data.token}' | base64 -d)"

И вот мы его уже можем прописать в kubeconfig и использовать.

1
2
3
4


kubectl config current-context | \
xargs kubectl config get-contexts --no-headers | \
awk '{print $4}' | \
xargs kubectl config set-credentials "--token=${SA_TOKEN}"

Создание пользователя ¶

Тут придётся заморочится. Нужно создать сертификат, запрос на подпись, подписать, забрать публичную часть и вот только теперь мы приплыли. Скрипт я свой прилагаю, а описывать это всё не хочу. Горит именно о OIDC рассказать, так что воспринимайте это как приятный бонус 😄

Как пользоваться:

Пишем своё имя в переменную NAME
Пишем имя компании в переменную GROUP
Меняем CLUSTERROLE если очень хочется
Запускаем и читаем инструкцию на экране

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55


NAME='john-johnson'
GROUP='asdfqwer'
CLUSTERROLE='cluster-admin'

openssl ecparam -genkey -name prime256v1 | openssl ec -out "$NAME.key"
KEY_BASE64="$(base64 -w0 "$NAME.key")"
openssl req -new -key "$NAME.key" -out "$NAME.csr" -subj "/CN=$NAME/O=$GROUP"
CSR_BASE64="$(base64 -w0 "$NAME.csr")"
rm -f "$NAME.csr" "$NAME.key"

cat <<EOF
# ┬ ┐┐─┐┬─┐┬─┐ ┌─┐┬─┐┬─┐┬─┐┌┐┐o┌─┐┌┐┐
# │ │└─┐├─ │┬┘ │ │┬┘├─ │─┤ │ ││ ││││
# ┘─┘──┘┴─┘┘└┘ └─┘┘└┘┴─┘┘ ┘ ┘ ┘┘─┘┘└┘

1. Please, execute following code using kubectl that has access to the cluster (using default admin credentials, for example)

kubectl apply -f - <<EOT
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
 name: $GROUP:$NAME
spec:
 expirationSeconds: 31536000 # 1 year
 signerName: kubernetes.io/kube-apiserver-client
 usages: ["client auth"]
 username: $NAME
 request: $CSR_BASE64
EOT
kubectl certificate approve '$GROUP:$NAME'
kubectl apply -f - <<EOT
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: user:${NAME}:${CLUSTERROLE}
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: $CLUSTERROLE
subjects:
- apiGroup: rbac.authorization.k8s.io
 kind: User
 name: $NAME
EOT
kubectl get -o jsonpath='{.status.certificate}' csr '$GROUP:$NAME'
echo

2. Please, execute following code locally, on your PC, where you want to have that credentials inserted

kubectl config set "users.$GROUP:$NAME.client-key-data" "$KEY_BASE64"
kubectl config set "users.$GROUP:$NAME.client-certificate-data" "-" --set-raw-bytes=true

3. Now place certificate that has been printed during step #1 in your kubeconfig client-certificate-data for user $GROUP:$NAME marker
4. Specify $GROUP:$NAME user in the context you want to use
EOF

Google OIDC ¶

Настраиваем OAuth consent screen
Создаём OAuth2 креды тип Web application, Authorized redirect URIs - в списке ниже.
1 2 3 4

http://127.0.0.1:18000 http://127.0.0.1:8000 http://localhost:18000 http://localhost:8000
В итоге получили Client ID и Client Secret

Отлично, теперь нужно поставить kubectl oidc-login плагин.

После установки, пробуем, чтобы у нас всё работало.

1
2
3
4


kubectl oidc-login setup \
 --oidc-issuer-url=https://accounts.google.com \
 --oidc-client-id='YOUR CLIENT ID' \
 --oidc-client-secret='YOUR CLIENT SECRET'

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55


authentication in progress...
Opening in existing browser session.

## 2. Verify authentication

You got a token with the following claims:

{
 "iss": "https://accounts.google.com",
 "azp": "longalphanum",
 "aud": "longalphanum",
 "sub": "longalphanum",
 "at_hash": "longalphanum",
 "nonce": "longalphanum",
 "iat": longalphanum,
 "exp": longalphanum
}

## 3. Bind a cluster role

Run the following command:

 kubectl create clusterrolebinding oidc-cluster-admin --clusterrole=cluster-admin --user='https://accounts.google.com#12345678901234567890'

## 4. Set up the Kubernetes API server

Add the following options to the kube-apiserver:

 --oidc-issuer-url=https://accounts.google.com
 --oidc-client-id=longalphanum

## 5. Set up the kubeconfig

Run the following command:

 kubectl config set-credentials oidc \
 --exec-api-version=client.authentication.k8s.io/v1beta1 \
 --exec-command=kubectl \
 --exec-arg=oidc-login \
 --exec-arg=get-token \
 --exec-arg=--oidc-issuer-url=https://accounts.google.com \
 --exec-arg=--oidc-client-id=longalphanum \
 --exec-arg=--oidc-client-secret=longalphanum

## 6. Verify cluster access

Make sure you can access the Kubernetes cluster.

 kubectl --user=oidc get nodes

You can switch the default context to oidc.

 kubectl config set-context --current --user=oidc

You can share the kubeconfig to your team members for on-boarding.

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

Authentik ¶

Штука отличная! Из прямых аналогов, стоит отметить Okta и Keycloak. Все 3 продукта великолепные, на Okta вообще часто равняются как на эталон. Другое либо лучше, либо хуже, но всегда по сравнению с Okta 😄

Ставил я Authentik из официального чарта. Он у меня запущен локально, а сертификат нужен. Получил certbot-ом используя DNS проверку. После этого делаем следующее.

Applications > Providers

Создаём провайдер Kubernetes типа OAuth2/OIDC
- Client type: Confidential
- Client ID: запоминаем
- Client Secret: запоминаем
- Redirect URIs: http://(127.0.0.1|localhost):1?8000(/.*)?
Application > Applications

Создаем приложение Kubernetes и выбираем провайдером то, что создали в пункте 1.
System

В пользователях создаём пользователей (как неожиданно, неправда ли?), тут же создаём группы. Я сделал kubernetes:admin и kubernetes:restricted. Первым будет выдаваться cluster-admin роль в самом Kubernetes, а вторым - что-то readonly. Не забываем добавить пользователей в соответсвующие группы.
System > Certificates

Вот тут не уверен, просто не проверял без этого. Я загрузил сюда сертификат, который получил ранее certbot-ом, а потом этот сертификат выбрал в Application > Providers > Kubernetes > Edit > Signing Key. Kubernetes не ругался, может можно тут и self-signed было стандартный использовать, не знаю, в общем. Попробуете сами.

Customization > Property Mappings

Создаём вот с такими параметрами

Name: Kubernetes
Scope name: kubernetes

Expression

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


all_groups = [
 "kubernetes:admin",
 "kubernetes:restricted"
]
return dict(
 groups=[
 group for group in all_groups
 if ak_is_group_member(request.user, name=group)
 ]
)

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

Проверяем kube-oidc-login

1
2
3
4
5


kubectl oidc-login setup \
 --oidc-issuer-url=https://authentik.example.com/application/o/kubernetes/ \
 --oidc-client-id='YOUR CLIENT ID' \
 --oidc-client-secret='YOUR CLIENT SECRET' \
 --oidc-extra-scope=kubernetes

Всё там заводится, следуем дальше инструкциям.

Выделяем права на группу в Kubernetes

Authentik передаст список групп, теперь нужно чтобы Kubernetes на это обратил внимание. Добавляем к API серверу вот такие аргументы.

1
2


--oidc-groups-claim=groups
--oidc-groups-prefix=oidc:

Теперь, можно создать, к примеру, такие ресурсы.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: oidc:kubernetes:admin
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
 kind: Group
 name: oidc:kubernetes:admin
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: this-name-is-custom
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: view
subjects:
- apiGroup: rbac.authorization.k8s.io
 kind: Group
 name: oidc:kubernetes:restricted

wg-quick network namespace

Fri, 25 Nov 2022 00:00:00 +0000

TL;DR ¶

1
2
3


PreUp = ip netns list | grep -qF -- %i && ip netns delete %i || true
PostUp = (ip netns list | grep -qF -- %i || ip netns add %i) && ip -n %i link set up lo && IPS="$(ip address save dev %i | base64)" && ip link set %i netns %i && echo "$IPS" | base64 -d | ip -n %i address restore dev %i && ip -n %i link set up %i && (ip -n %i route show default | grep -qF default || ip -n %i route add default dev %i) && echo 'IyEvdXNyL2Jpbi9lbnYgc2gKc2V0IC1lCgpuZXRucz0nJXMnCgpjYXQgPDxFT0YgfCB4YXJncyAtMCBzdWRvIC1FIG5zZW50ZXIgIi0tbmV0PS92YXIvcnVuL25ldG5zLyRuZXRucyIgdW5zaGFyZSAtLW1vdW50IHNoIC1jCmZvciBjb25mIGluICIkbmV0bnMiICJ0dW4uJG5ldG5zIjsgZG8KICBpZiBbIC1mICIvdmFyL3J1bi9yZXNvbHZjb25mL2ludGVyZmFjZXMvXCRjb25mIiBdOyB0aGVuCiAgICBtb3VudCAtLWJpbmQgIi92YXIvcnVuL3Jlc29sdmNvbmYvaW50ZXJmYWNlcy9cJGNvbmYiIC9ldGMvcmVzb2x2LmNvbmYKICBmaQpkb25lCmV4cG9ydCBEQlVTX1NFU1NJT05fQlVTX0FERFJFU1M9dW5peDpwYXRoPS9kZXYvbnVsbApzdWRvIC1FIC11ICcjJHtTVURPX1VJRDotJChpZCAtdSl9JyAtZyAnIyR7U1VET19HSUQ6LSQoaWQgLWcpfScgLS0gJEAKRU9GCg==' | base64 -d | xargs -0 -I{} printf {} %i > /usr/local/bin/wg-%i-exec && echo 'IyEvdXNyL2Jpbi9lbnYgc2gKc2V0IC1lCgppZiBbICIkKGlkIC11KSIgLW5lIDAgXTsgdGhlbgogIGVjaG8gImVycm9yOiBydW4gbWUgYXMgcm9vdCIgMT4mMgogIGV4aXQgMQpmaQoKbmV0bnM9JyVzJwppcCBuZXRucyBleGVjICIkbmV0bnMiIGlwIGxpbmsgc2V0ICIkbmV0bnMiIG5ldG5zIDEKaXAgbmV0bnMgZGVsZXRlICIkbmV0bnMiCnN5c3RlbWN0bCBzdG9wICJ3Zy1xdWlja0AkbmV0bnMuc2VydmljZSIK' | base64 -d | xargs -0 -I{} printf {} %i > /usr/local/bin/wg-%i-down && chmod 0755 /usr/local/bin/wg-%i-* && chown root:root /usr/local/bin/wg-%i-* && echo 'bmV0bnM9JyVzJwpjYXQgPDxFT0YKIyAg4pSQIOKUrG/ilKzilIDilJDilKzilIDilJDilIzilIDilJDilKwg4pSQ4pSs4pSA4pSQ4pSs4pSA4pSQ4pSs4pSA4pSQICDilIzilJDilJDilKzilIDilJDilIzilJDilJDilIzilJDilJDilJDilIDilJAKIyAg4pSC4pSC4pSC4pSC4pSC4pSs4pSY4pSc4pSAIOKUgiDilKzilIIg4pSC4pSC4pSA4pSk4pSC4pSs4pSY4pSCIOKUgiAg4pSC4pSC4pSC4pSc4pSAICDilIIg4pSC4pSC4pSC4pSU4pSA4pSQCiMgIOKUlOKUtOKUmOKUmOKUmOKUlOKUmOKUtOKUgOKUmOKUmOKUgOKUmOKUmOKUgOKUmOKUmCDilJjilJjilJTilJjilJjilIDilJggIOKUmOKUlOKUmOKUtOKUgOKUmCDilJgg4pSY4pSU4pSY4pSA4pSA4pSYClRoYW5rcyBmb3IgdXNpbmcgbmV0bnMgd2ctcXVpY2sgd3JhcHBlciEKCi91c3IvbG9jYWwvYmluL3dnLSRuZXRucy1leGVjIENPTU1BTkQgICAtIGV4ZWN1dGUgc2hlbGwgY29tbWFuZCBpbiAkbmV0bnMgbmV0d29yayBuYW1lc3BhY2UKL3Vzci9sb2NhbC9iaW4vd2ctJG5ldG5zLWRvd24gICAgICAgICAgIC0gdXNlIGl0IGluc3RlYWQgb2Ygd2ctcXVpY2sgZG93biAkbmV0bnMKRU9G' | base64 -d | xargs -0 -I{} printf {} %i | sh - 
PostDown = rm -f /usr/local/bin/wg-%i-* || true

Введение ¶

Wireguard – обалденный, простой VPN, который уже включён в состав ядра. Очень мощный и простой инструмент. Ставиться в разы проще чем OpenVPN. Для его простой настройки используется утилита wg-quick, которая входит в состав wireguard tools. Для более полного понимания, дополнительно уточню, что из моего опыта большинство решений, таких как WGDashboard и wireguard-ui генерируют клиентские конфиги именно под wg-quick.

Постановка задачи ¶

Переносить wireguard интерфейс в отдельное сетевое пространство имён, чтобы потом в нём запускать приложения. Зачем это делать? Это избавляет от необходимости проксировать трафик на заблокированные сайты через Wireguard какими-то сложными решениями. Нужно зайти куда-то в такое место - просто запустил ещё один браузер в пространстве Wireguard и всё! Я так, к примеру, переписал Exec строку в ярлыке Thunderbird, которому альтернативы пока столь же функциональной нет, и теперь он всегда запускается через VPN и может спокойно собирать почту с любых SMTP. Использовать нужно ванильный wg-quick без доработок, чтобы это работало с ходу.

Разбор решения ¶

В документации, есть 4 пути к дополнительной настройке wg-quick интерфейса. PreUp, PostUp, PreDown, PostDown. Значит нужно написать скрипты таким образом, чтобы они делали всё что нужно. Готовое решение представлено в начале статьи, а теперь его разберём. Я преобразую этот ужатый код в человекочитаемый вид, выглядит иначе, но содержательно буква в букву. Замечание: в коде встречается %i, это макрос самого wg-quick, везде где он встретит этот макрос, подставит имя создаваемого интерфейса.

PreUp ¶

Тут всё просто.

1
2
3
4
5


# в списке сетевых пространств ищем наше
if ip netns list | grep -qF -- %i; then
 # если нашли - удаляем
 ip netns delete %i
fi

PostUp ¶

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78


if ! ip netns list | grep -qF -- %i; then
 # создаём сетевое пространство если его ещё нет (а его и не должно быть)
 ip netns add %i
fi
# запускаем там loopback интерфейс (127.0.0.1 который)
ip -n %i link set up lo
# сохраняем список сетевых адресов которые wg-quick навесил на интерфейс при создании
# и кодируем это в base64, потому что это бинарный поток в формате утилиты ip
IPS="$(ip address save dev %i | base64)"
# переносим интерфейс в наше специальное пространство имён
ip link set %i netns %i
# навешиваем адреса обратно, раскодируя их из переменной созданной ранее
echo "$IPS" | base64 -d | ip -n %i address restore dev %i
# запускаем сетевой интерфейс в том пространстве имён
ip -n %i link set up %i
# ищем маршрут на 0.0.0.0/0 в списке путей нашего пространства имён
if ! ip -n %i route show default | grep -qF default; then
 # добавляем если не нашли
 ip -n %i route add default dev %i
fi
# тут был скрипт в base64, я его прямо для вас в тексте раскодировал, чтобы просто было понятно что там
# скрипт этот раскодируется и в него с помощью printf вставляется имя интерфейса с которым всегда будет
# работать скрипт
cat <<EOT | xargs -0 -I{} printf {} %i > /usr/local/bin/wg-%i-exec
#!/usr/bin/env sh
set -e

# вот сюда это имя интерфейса залетит в переменную
netns='%s'

# а вот эту лабуду я отдельно поясню
cat <<EOF | xargs -0 sudo -E nsenter "--net=/var/run/netns/$netns" unshare --mount sh -c
for conf in "$netns" "tun.$netns"; do
 if [ -f "/var/run/resolvconf/interfaces/\$conf" ]; then
 mount --bind "/var/run/resolvconf/interfaces/\$conf" /etc/resolv.conf
 fi
done
export DBUS_SESSION_BUS_ADDRESS=unix:path=/dev/null
sudo -E -u '#${SUDO_UID:-$(id -u)}' -g '#${SUDO_GID:-$(id -g)}' -- $@
EOF
EOT
# вот такой же скрипт, но мы там выполняем не пользовательскую команду, а wg-quick down
cat <<EOT | xargs -0 -I{} printf {} %i > /usr/local/bin/wg-%i-down
#!/usr/bin/env sh
set -e

# необходимо запускать от рута
if [ "$(id -u)" -ne 0 ]; then
 echo "error: run me as root" 1>&2
 exit 1
fi

netns='%s'
# возвращаем интерфейс обратно в корневой netns
ip netns exec "$netns" ip link set "$netns" netns 1
# сносим наш кастомный netns
ip netns delete "$netns"
# и останавливаем через wg-quick, который сам снесёт интерфейс
systemctl stop "wg-quick@$netns.service"
EOT
# меняем собственника и права на файлы
chmod 0755 /usr/local/bin/wg-%i-*
chown root:root /usr/local/bin/wg-%i-*
# просто выводим текст на экран в момент поднятия интерфейса - справка для пользователя,
# которая рассказывает о двух скриптах созданных ранее. Этот текст раскодируется и прямо
# кидается в sh, то есть выполняется на ходу, а там только и есть что один cat
cat <<EOT | xargs -0 -I{} printf {} %i | sh -
netns='%s'
cat <<EOF
# ┐ ┬o┬─┐┬─┐┌─┐┬ ┐┬─┐┬─┐┬─┐ ┌┐┐┬─┐┌┐┐┌┐┐┐─┐
# │││││┬┘├─ │ ┬│ ││─┤│┬┘│ │ │││├─ │ │││└─┐
# └┴┘┘┘└┘┴─┘┘─┘┘─┘┘ ┘┘└┘┘─┘ ┘└┘┴─┘ ┘ ┘└┘──┘
Thanks for using netns wg-quick wrapper!

/usr/local/bin/wg-$netns-exec COMMAND - execute shell command in $netns network namespace
/usr/local/bin/wg-$netns-down - use it instead of wg-quick down $netns
EOF
EOT

А вот тут самое сумашествие. Поясняю основные моменты.

Когда переносишь сетефой интерфейс в другое пространство, с него, к сожалению, слетают все IP адреса. По-этому, мы их в начале сохраняем, а потом восстанавливаем, после переноса.
Loopback интерфейс в новом пространстве по умолчанию выключен, по-этому мы его включаем сами
Добавляется маршрут только на 0.0.0.0/0 потому что у нас в принципе трафику кроме как на wireguard ходить некуда, по-этому весь туда пускаем и без разницы, что в AllowedIPs на интерфейсе прописано. Так скрипт проще, работает так же, уязвимостей не создаёт.
Создаются два скрипта: wg-%i-exec, wg-%i-down. Первый нужен чтобы ним запускать программы в нашем сетевом пространстве, а второй нужен чтобы просто сделать wg-quick down, потому что просто выполнив wg-quick down остановить интерфейс не выйдет, нужно wg-quick выполнять внутри нашего пространства имён

Как работает wg-%i-exec ¶

Тут есть ряд проблем, которые решает скрипт:

Внутри пространства имён нет resolv.conf-а, или может не быть. Всегда его создаёт себе сам wg-quick через resolvconf, даже без всех наших ухищрений. То есть он создаётся для интерфейса. Это нужно для разрешение DNS имён.
Нужно сделать так, чтобы даже запукая exec пользователь, не получал права root в подарок, а оставался со своими привилегиями.

Я раскидаю скрипт по строкам в, возможно, даже не рабочий shell код, но так удобнее будет коментировать.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


#!/usr/bin/env sh
set -e

# вот сюда это имя интерфейса залетит в переменную
netns='%s'

# а вот эту лабуду я отдельно поясню
cat <<EOF | xargs -0 sudo -E nsenter "--net=/var/run/netns/$netns" unshare --mount sh -c
for conf in "$netns" "tun.$netns"; do
 if [ -f "/var/run/resolvconf/interfaces/\$conf" ]; then
 mount --bind "/var/run/resolvconf/interfaces/\$conf" /etc/resolv.conf
 fi
done
export DBUS_SESSION_BUS_ADDRESS=unix:path=/dev/null
sudo -E -u '#${SUDO_UID:-$(id -u)}' -g '#${SUDO_GID:-$(id -g)}' -- $@
EOF


# выполняем от имени судо, сохраняя env текущего пользователя, это будет всё равно с правами рута
sudo -E
# nsenter запустит нам в этом пространстве имён
nsenter "--net=/var/run/netns/$NETNS"
# а потом размонтирует, всё что монтировалось
unshare --mount
# команду shell-a, который выполнит скрипт
sh -c
'
# где мы монтируем resolv.conf созданный wg-quick-ом, если такой вообще есть
# на Ubuntu и Fedora это нужно, на Manjaro - /etc/resolv.conf и так на месте
for conf in "$netns" "tun.$netns"; do
 if [ -f "/var/run/resolvconf/interfaces/\$conf" ]; then
 mount --bind "/var/run/resolvconf/interfaces/\$conf" /etc/resolv.conf
 fi
done
# браузеры не запускаются без этого
export DBUS_SESSION_BUS_ADDRESS=unix:path=/dev/null
# и с помощью sudo сохраняя всё тот же env текущего пользователя
sudo -E
# не не от имени рута, а уже от имени пользователя, который запустил exec скрипт
-u '#${SUDO_UID:-$(id -u)}' 
-g '#${SUDO_GID:-$(id -g)}'
# выполняем то, что он попросил
-- $@
'

Итог ¶

Просто вставляем эти 3 строки в конфиг и всё! Никакого Ansible, танцев с бубном, сложной настройки и поддержки.

GPT (UEFI) for Btrfs (/ and /boot) over dm-crypt

Sun, 20 Mar 2022 00:00:00 +0000

Введение ¶

Программа на фото статьи это GParted. Люблю, практикую. Удобно и просто можно творить с разделами всё, что вздумается. Не смог выбрать, что поставить заглавным изображением статьи. Пусть будет моя текущая разметка 😄
Системы я переставлял и переставляю довольно часто, пару раз в год будет. Причины разные: то сервачок собрал, то на рабочий ПК поменял на ноутбук, то на компьютер родителей винт побольше поставил… По мелочи в общем. Опыт и с Windows, и с разными дистрибутивами Linux имел обширный, как мне кажется. Статься в целом, больше болтология, не обижайтесь. Если кто-то вдруг обнаружит, что на сайте комментарии уже как полгода можно оставлять, буду искренне рад 😄

Тип таблицы разделов ¶

Как я думал раньше: “Вот, есть старый добрый MBR, а GPT придумали с этими их UEFI-ями проклятыми, чтобы на ноуты катать и не давать людям другие ОСи ставить! 4 раздела ограничение - ну и что. Хочешь больше - логические в помощь.” Думал я так до января 2022, а потом получил по работе ноутбук, ну и конечно, стал думать как чем бы его зарядить. “А попробую-ка GPT, ну никогда не брал ведь. Пусть будет, какая разница. Работать будет и ладно”. Итог: GPT UEFI форева! Почему…

Нет ограничения по количеству разделов
Нет области прописывания загрузчика в начале диска, то есть BIOS грузит не диск, следуя на нём по ссылке в самом начале, а конкретную найденную на одном из сколько хош FAT32 разделов программу.
GRUB видит всех соседей на диске, а также сам BIOS так как оказалось, что точка входа в него это точно такая же UEFI программа. Можно из меню загрузчика попасть в BIOS, оттуда опять в загрузчик, оттуда опять в BIOS, ну вы поняли…
Когда ты ставишь Windows и она сносит MBR тебя даже не спрашивая (своё красноречивое, нецензурное мнение по поводу уважения Microsoft к продуктам иным, нежели тем, которые были разработаны в Microsoft, я писать здесь не буду), а потом тебе нужно с LiveUSB восстанавливать GRUB, или просто система неудачно обновилась какая-то. Не важно, что случилось. Ты просто грузишь другую ОС прямо из BIOS-a! Вот это мне очень понравилось.
Недостатком, но просто мелочью по факту, является то, что программы UEFI могут быть только на разделах FAT32. Ну и ладно. Создал и забыл.
Windows в начале не планировалась, но когда появилась, оказалось, что она прекрасно может стать на любые по порядку разделы, а не только на первый как в случае MBR, а это очень большой плюс.

Файловые системы ¶

Я переехал на BTRFS везде, и на рабочей машине, и на сервере, и раздел архива (авто, мото, фото …) тоже на BTRFS. Очень люблю и уважаю, попробовал тоже недавно. Искал разные замеры производительности и понял, что в среднем BTRFS такая же, как EXT4, но медленнее XFS. “Брать или не брать?” - думал я. Так вот взял по одной простой, но понятной причине: мои машины это не высоконагруженные сервера и разницы я не почувствую этой в производительности 😄 Выбором остался доволен.

У меня на домашнем сервере BTRFS RAID1 на двух HDD Barracuda 1TB - программный рейд, без проблемы и с одного тычка.
Встроенные: сжатие, дефрагментация, контроль ошибок (по которому можно судить, когда винты умирают), снапшоты. Сказка!
Как оказалось, GRUB грузит BTRFS и грузится с BTRFS без проблем!
Жаль нет встроенного шифрования. Пришлось навесить сверху dm-crypt - и ничего, всё отлично.
Весь BTRFS это как логический раздел с резиновыми разделами внутри, которые не располагаются привычно нам друг за другом, а просто есть, скопом 😄 Не нужно добавлять места, если закончилось или как-то продумывать что, сколько будет есть.

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# монтируем корень btrfs на старой машине
mount /dev/sda1 -o subvol=/ /mnt
# то же на новой машине
ssh user@new-pc mount /dev/sda1 -o subvol=/ /mnt
# делаем readonly снапшот раздела с системой
btrfs subvolume snapshot -r /mnt/@manjaro /mnt/@manjaro-ro
# пересылаем по SSH! обалдеть просто...
btrfs send /mnt/@manjaro-ro | ssh user@new-pc btrfs receive /mnt/@manjaro-ro
# там на месте из полученного readonly делаем readwrite снапшот
ssh user@new-pc btrfs subvolume snapshot /mnt/@manjaro-ro /mnt/@manjaro
# удаляем readonly
ssh user@new-pc btrfs subvolume del /mnt/@manjaro-ro
# размонтируем всё
umount /mnt
ssh user@new-pc umount /mnt

Так просто и легко я ещё не перезжал. Что нужно не забыть, конечно, сделать потом руками:

Поправить UUID-ы в /etc/fstab
Поправить /etc/hostname
grub-install ... && grub-mkconfig ...

Разделы GPT ¶

Если Windows нужно будет больше места - отрежу с конца у Manjaro
Если нужен будет ещё Linux, то для него понадобиться тоже EFI раздел, а вот boot - нет! Потому что из одного BTRFS boot могут грузиться сколько хочешь линуксов - просто разделы (subvolume) разные

Операционные системы ¶

Лучше Manjaro трудно что-то представить. Мне очень нравиться всё - документация, утилиты, простота контроля обновления ядра с mhwd-kernel, совместимость со всей документацией Vanilla Arch. Свежий софт, но не настолько как у Fedora, что тоже радует! Есть mari0
Windows 10, просто для игрушек и Steam.

Важные заметки ¶

Windows никого не спрашивает и форматирует раздел с флагами boot,esp в FAT32 и кладёт туда свой EFI. Решилось ручным созданием раздела EFI-Windows и навешиванием на него этих флагов. Linux-у фиолетово где они висят - на загрузку не влияет, а вот установка Windows влезла в нужное мне место.
Я вначале boot не выносил и он тоже был зашифрован! Работает на ура! Есть одна неприятность: GRUB драйвера не подтягивает и для расшифровки раздела использует программно реализованные алгоритмы, не привлекая аппаратные возможности CPU. Первоначальная расшифровка занимала у меня 5-7 секунд. Люди в сети жалованись на десятки… Для меня было не критично те 5-7 секунд, тем более, что на работе потом это не сказывается, только на самом начале загрузки, но решил убрать эту задержку, безопасность мне параноидальная тоже не нужна.
Для восстановления загрузчика нужно также примонтировать efivars перед chroot
Вот отличная документация по вопросу восстановления загрузчика
Лучше документации по установке системы, чем эта, на зашифрованный раздел (по всякому) просто представить трудно
UUID-ы из /etc/fstab должны совпадать с нужными Вам из вывода blkid

Не важные заметки ¶

А вот так у меня выглядит экран загрузки благодаря plymouth. Тема Pack 2 - Flame. (подёргивания картинки только в браузере, во время загрузки всё гладко)
Здесь я тему выбрал себе для самого Grub. Вот та, которую я взял.
dm-crypt можно пропатчить и сделать nuke пароль. Если его ввести, то все ключи будут уничтожены и раздел уже не расшифровать. Сколько бы вас не пытали, они уже ничего не получат… ха-ха.. ха… мда.. ну что есть, то есть

Grub recovery script ¶

Имена разделов точно как у меня на изображении к посту. Это поможет сориентироваться.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


# расшивровуем раздел с системой
cryptsetup luksOpen /dev/nvme0n1p1 cryptroot
# монтируем систему
mount /dev/mapper/cryptroot -o subvol=@root /mnt
# монтируем boot
mount /dev/nvme0n1p2 -o subvol=@boot /mnt/boot
# создаём папку efi если нет
mkdir -p /mnt/boot/efi
# монтируем efi в boot
mount /dev/nvme0n1p3 /mnt/boot/efi
# монтируем кучу всего для chroot
for i in dev proc sys ; do mount --bind /$i /mnt/$i; done
# монтируем efivars а то grub не встанет
mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars
# запрыгиваем в нашу систему
chroot /mnt
# ставим grub. тут нужны пояснения
# 1. в случае с mbr мы привыкли указывать диск, куда прописать загрузчик
# в случае с efi он ничего никуда не прописывает, а просто наполняет /boot
# 2. bootloader-id это просто для красоты - именно так BIOS будет подписывать нашу ось в списке
# можно и не писать, там по умолчанию будет manjaro
grub-install --bootloader-id="Manjaro"
# если профукал весь раздел /boot вместе с образами ядра, то вот так они перегенерятся
pacman -S linux
# собираем initramfs образы
mkinitcpio -P
# собираем меню grub
grub-mkconfig -o /boot/grub/grub.cfg
# выходим из chroot
exit
# размонтируем и закрываем всё в обратном порядке
umount /mnt/sys/firmware/efi/efivars
for i in dev proc sys; do umount /mnt/$i; done
umount /mnt/boot/efi
umount /mnt/boot
umount /mnt
cryptsetup luksClose cryptroot

Простыми словами о загрузке ОС (EFI) ¶

BIOS запускается и находит всё FAT32, в которых есть папка EFI и знакомые ему файлы. Грузит одну из найденных програм, какую попросили.
Программа EFI штука не такая тупая как MBR и может делать, что угодно. В нашем случае, она лезет на /boot раздел c GRUB, открывает для себя BTRFS и подгужает меню GRUB и именно здесь загружается и отрисовывается тема, которую мы выбрали для GRUB
Теперь мы в меню GRUB выбираем что грузить
GRUB загружает в оперативку целяком initramfs того, что мы попросили грузить. Это то, что мы генерили командой mkinitcpio. Initcpio это программа на подобии EFI, но когда его придумывали, EFI ещё не было, был только тупой MBR. Что-то мне кажется, что можно напрямую с EFI грузить систему без лишней прослойки. Ну да ладно… Кроме того, вместе с initramfs именно тут грузится уже ядро, так как оно вынесено на /boot тоже.
Initcpio это слоёный пирог хуков, которые выполняются по очереди. Каждый делает что-то важное и нужное. Так вот если мы поставили plymouth, вот тут же, в одном из самых первых хуков на экран рисуется какая-то красотень, чтобы спрятать кучу логов загрузки.
Один из хуков это encrypt или plymouth-encrypt. Вот как раз этот кусочек слоёного пирога initramfs спрашивает у нас пароль от зашифрованного root-а. То есть, до этого момента он вообще не трогался 😄
Расшифровка, создание первого процесса, запуск служб, драйвером, графической оболочки и процего шлака.

Вопросы ¶

Если будут вопросы или чем помочь, подсказать как у меня настроен конкретно тот или иной кусок - пишите в Telegram или в комментарии. Буду рад помочь!

Обзор k9s

Mon, 17 Jan 2022 00:00:00 +0000

Введение ¶

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

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

Обзор ¶

Просмотр логов ¶

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

Копирование в буфер обмена ¶

По нажатию C в режиме просмотра логов или манифеста объекта, содержимое экрана (весь файл или лог, не только видимое содержимое) копируется в буфер обмена. Нужно чтобы был установлен так же xsel.

Проброс портов ¶

Нажав Shift + F можно выбрать какие порты пробросить на локальную машину, чтобы достучаться до какого-нибудь сервиса.

Просмотр проблемных подов ¶

Нажав Ctrl + Z в списке подов остаются только те, что не Running.

Поиск по подстроке ¶

Просто нажимаем слеш и пишем подстроку которую нужно искать в имени или метках объектов из списка. Удобно, когда объектов много.

Демонстрация ¶

Заметки о Terraform

Sun, 16 Jan 2022 00:00:00 +0000

Введение ¶

Terraform - это прекрасный инструмент для автоматизации создания ресурсов в облаках AWS, Azure, GCP, Hetzner и ещё много где. Штука классная. С помощью tfenv можно просто и удобно обновлять сам Terraform локально и выбирать нужную версию. Можно создать файлик в корне проекта и прописать нужную версию, чтобы tfenv автоматически нужную версию Terraform подставлял под проект.
Есть ряд практических рекомендаций которые я вывел для себя читая официальную документацию, которая прям очень хороша, а так же модули и код написанный AWS-ом.

Figlet ASCII графика

Fri, 07 Jan 2022 00:00:00 +0000

Бомберман отсюда.

Введение ¶

1
2
3
4
5
6
7


# ┬ ┬┬─┐┬ ┬ ┌─┐ # ┳━┓┳━┓┏┓┓┳━┓┳━┓┳━┓┓━┓┳━┓┓━┓
# │─┤├─ │ │ │ │ # ┃ ┃┃━┫ ┃ ┃━┫┃━┃┃━┫┗━┓┣━ ┗━┓
# ┘ ┴┴─┘┘─┘┘─┘┘─┘ # ┇━┛┛ ┇ ┇ ┛ ┇┇━┛┛ ┇━━┛┻━┛━━┛

# ┳━┓┓ ┳┓━┓ ┳━┓┏━┓┏━┓ # ┌┐┐┬─┐┌┐┐┐ ┬┌─┐┬─┐┬┌
# ┃━┫┃┃┃┗━┓ ┣━ ┃ ┏━┛ # │││├─ │ ││││ ││┬┘├┴┐
# ┛ ┇┗┻┇━━┛ ┻━┛┗━┛┗━━ # ┘└┘┴─┘ ┘ └┴┘┘─┘┘└┘┘ ┘

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

Установка ¶

Устанавливаем figlet как угодно для своего дистрибутива.
Качаем дополнительные шрифты.

1
2


curl -Lo- 'https://github.com/vlasov-y/figlet-fonts/archive/refs/tags/v1.1.tar.gz' | \
sudo tar -C "$(figlet -I2)" --strip-components 1 -xpzvf -

Просмотр всех шрифтов ¶

1
2
3
4


find "$(figlet -I2)" -type f -name '*.*f' | while read -r i; do
 echo "> $i"
 figlet -f "$i" "$(basename "$i")"
done | less

Функция для .bashrc ¶

Вот тут внимательно. В подавляющем большинстве шрифтов используются знаки, которые у ваших коллег, которые тот же код из Git стянут, либо вообще не отобразятся, либо будут показаны не правильно, прямоугольниками. Я методом проб и ошибок нашёл для себя универсальный и красивый шрифт - Rusto. Есть ещё RustoFat, и он мне даже больше нравиться, но он уже проблемный 😢

1
2
3
4
5
6
7


# ┬─┐┬ ┐┐─┐┌┐┐┌─┐
# │┬┘│ │└─┐ │ │ │
# ┘└┘┘─┘──┘ ┘ ┘─┘

# ┳━┓┳ ┓┓━┓┏┓┓┏━┓┳━┓┳━┓┏┓┓
# ┃┳┛┃ ┃┗━┓ ┃ ┃ ┃┣━ ┃━┫ ┃ 
# ┇┗┛┇━┛━━┛ ┇ ┛━┛┇ ┛ ┇ ┇ 

Надписи выше, я получил уже используя свою функцию, по этому у Вас Rusto будет немного отличаться. Добавьте эту функцию к себе в .bashrc или .zshrc и можно будет пользоваться. Кроме того, нужно будет поставить xsel.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


rusto () {
 figlet -f rusto "$*" | sed "s@^@${P:-# }@g; s@┆@┘@g" | tee /tmp/tt | xsel -i -b
 cat /tmp/tt
 rm -f /tmp/tt
}

rustofat () {
 figlet -f rustofat "$*" | sed "s@^@${P:-# }@g" | tee /tmp/tt | xsel -i -b
 cat /tmp/tt
 rm -f /tmp/tt
}

Что тут творится? Выполняя команду в консоли rusto или rustofat текст, который будет передан как аргументы к командам, будет преобразован, написан на экране и сразу скопирован в буфер обмена. И да, ещё символ ┆ заменяется на ┘, чтобы Rusto был полностью безпроблемным. Также, дописывается # к началу каждой строки, чтобы можно было сразу в исходники вставлять. Решётку можно заменить указав переменную P.

1
2
3
4
5
6
7
8
9


❯ rusto hello world
# ┬ ┬┬─┐┬ ┬ ┌─┐ ┐ ┬┌─┐┬─┐┬ ┬─┐
# │─┤├─ │ │ │ │ ││││ ││┬┘│ │ │
# ┘ ┴┴─┘┘─┘┘─┘┘─┘ └┴┘┘─┘┘└┘┘─┘┘─┘

❯ P='// ' rustofat changed comment char
// ┏━┓┳ ┳┳━┓┏┓┓┏━┓┳━┓┳━┓ ┏━┓┏━┓┏┏┓┏┏┓┳━┓┏┓┓┏┓┓ ┏━┓┳ ┳┳━┓┳━┓
// ┃ ┃━┫┃━┫┃┃┃┃ ┳┣━ ┃ ┃ ┃ ┃ ┃┃┃┃┃┃┃┣━ ┃┃┃ ┃ ┃ ┃━┫┃━┫┃┳┛
// ┗━┛┇ ┻┛ ┇┇┗┛┇━┛┻━┛┇━┛ ┗━┛┛━┛┛ ┇┛ ┇┻━┛┇┗┛ ┇ ┗━┛┇ ┻┛ ┇┇┗┛

Бонус ¶

Форму для дневные отчётов я генерю так.

1
2
3
4


LC_ALL=C.POSIX date '+%d %B' | \
figlet | \
xargs -0 printf '```\n%s```\nNo blocks\nNo questions\nDone\\Doing:\n' | \
xsel -ib

Получается вот такое.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


```
 ___ __ _ 
 / _ \ / /_ | | __ _ _ __ _ _ __ _ _ __ _ _ 
| | | | '_ \ _ | |/ _` | '_ \| | | |/ _` | '__| | | |
| |_| | (_) | | |_| | (_| | | | | |_| | (_| | | | |_| |
 \___/ \___/ \___/ \__,_|_| |_|\__,_|\__,_|_| \__, |
 |___/ 
```
No blocks
No questions
Done\Doing:
- Drinking tee
- Sleeping
- Writing evening report
- Emulating work

Потом дописываю что я делал и сбрасываю в Slack.

Безопасное обновление Manjaro

Thu, 06 Jan 2022 00:00:00 +0000

История ¶

Как-то так вышло, что обновив систему полностью у меня сломалось две машины: рабочая и личный сервер. Библиотека Python 3.10 падала в segfault, что привело к неработоспособности Kodi медиасервера. Пропал Python Pip. Весело в общем. Хорошо, что был бекап.
К слову, я очень люблю Manjaro - это лучшая операционная система для профессионального использования, и проблем с обновлением никогда не было, кроме Нового года 😄 У меня это второй раз и оба раза были на Новый Год.
31 декабря 2020 я сделал полное обновление системы, а на утро в Новом Году обнаружил, что X11 не стартуют, потому что отпали драйвера на Nvidia. И вот, чиню я их открыв новый tty, просто установив снова через mhwd и перезапустив lightdm и думаю: “Ну ладно я, починил за 5 минут, а вот как другие? Не DevOps-ы или вообще простые обыватели? Это ж разрабы дистрибутива спешили к Новому Году так…”. Насколько я понял, там был перенос драйверов в репозитории дистрибутива, переименование просто, но этого хватило.
И вот снова Новый Год! Я ставлю обнову и ломается Python3 на уровне .so библиотеки 😄 Система в целом работает, но он много где нужен и часть программного обеспечения может отказать. Сразу перестал работать ranger, пришлось ставить снова.
Вот такая история, а скрипт я ниже оставлю.

Скрипт ¶

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


#!/usr/bin/env sh
## Making root btrfs subvolume snapshot before making full Manjaro update

set -e

PARTITION="$(mount | awk '$3~/^\/$/{print $1}')"
SUBVOL="$(mount | awk '$3~/^\/$/{print $6}' | grep -oE 'subvol=[^,)]+' | cut -d= -f2- | sed -r 's/^\///g')"
MOUNTPOINT="/mnt"
BACKUP="$(date +%Y-%m-%d | xargs printf "backup/%s-%s" "$SUBVOL")"

main() {
 backup
 update
}

backup() {
 echo "Mounting $PARTITION to $MOUNTPOINT"
 mount "$PARTITION" "$MOUNTPOINT" -o subvol=/
 cd "$MOUNTPOINT"
 dirname "$BACKUP" | xargs mkdir -p
 if [ ! -d "$BACKUP" ]; then
 echo "Backing up $SUBVOL to $BACKUP"
 btrfs sub snap -r "$SUBVOL" "$BACKUP"
 else
 echo "$BACKUP exists already"
 fi
 cd /
 echo "Unmounting $MOUNTPOINT"
 umount "$MOUNTPOINT"
}

update() {
 echo "Running update"
 yay -Syu
}

main "$@"

Пример работы ¶

А вот что будет, если бэкап за сегодня уже есть.

PulseAudio по TCP

Wed, 17 Nov 2021 00:00:00 +0000

Введение ¶

PulseAudio – звуковой сервер, в моём понимании. Выполняется на любом Linux ПК. Микрофоны, динамики, виртуальные устройства - всё идёт через PulseAudio и им контролируется.

Задача ¶

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

Источники ¶

Решение ¶

Трафик будет передаваться по TCP с ПК на сервер (для простоты буду просто называть его в тексте ТВ, но по факту это сервер на Manjaro).

И там, и там ставим модуль Zeroconf, чтобы компы друг друга находили без проблем.

1

yay -S pulseaudio-zeroconf

Теперь, возьмём cookie файл с одного и скопируем на второй, чтобы были одинаковые. Я нашёл у себя на ПК в домашнем каталоге у пользователя.

1
2


scp ~/.config/pulse/cookie server:/etc/pulse/cookie
sudo cp -f ~/.config/pulse/cookie /etc/pulse/cookie

А теперь настраиваем:

ТВ будет PulseAudio сервером, потому что он принимает аудио поток
ПК будет PulseAudio клиентом, потому что он отдаёт поток

На ТВ - выполняем от имени обычного пользователя, потому что pulseaudio --kill/--start от рута не нужно запускать.

1
2
3
4
5
6
7
8
9


SUBNET='192.168.0.0/24'
sudo mkdir -p /etc/pulse/default.pa.d/
cat <<EOF | sudo tee /etc/pulse/default.pa.d/zeroconf.pa
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;${SUBNET}
load-module module-zeroconf-publish
EOF
sudo systemctl enable --now avahi-daemon.service
pulseaudio --kill
pulseaudio --start

На ПК то же самое почти.

1
2
3
4
5
6
7
8
9


SUBNET='192.168.0.0/24'
sudo mkdir -p /etc/pulse/default.pa.d/
cat <<EOF | sudo tee /etc/pulse/default.pa.d/zeroconf.pa
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;${SUBNET}
load-module module-zeroconf-discover
EOF
sudo systemctl enable --now avahi-daemon.service
pulseaudio --kill
pulseaudio --start

Вот и всё. Теперь в pavucontrol можно какое-то приложение направить по туннелю до ПК!

Бонус, который не работает ¶

Что хочется дальше? Правильно, то что совсем не пригодиться, но интересно. Хочется чтобы и ПК, и ТВ проигрывали один и тот же поток.

На ПК посмотрим какие у нас есть outputы и получим их имена.

1
2
3
4
5


# pacmd list-sinks | grep name:
name: <alsa_output.pci-0000_00_1b.0.analog-stereo>
name: <tunnel.aurelius.local.auto_null>
name: <tunnel.aurelius.local.auto_null.2>
name: <tunnel.aurelius.local.alsa_output.pci-0000_00_0e.0.hdmi-stereo>

Вот и видно, что первый, похоже, наушники, а остальное прилетело по сети. 2-й и 3-й скорее всего задний и фронтальный выходы на корпусе, а последний явно HDMI компьютера - то что нужно. Объединить, значится, нужно 1-й и 4-й.

Всё там же на ПК

1
2
3
4
5
6
7
8
9


SLAVE_1='alsa_output.pci-0000_00_1b.0.analog-stereo'
SLAVE_2='tunnel.aurelius.local.alsa_output.pci-0000_00_0e.0.hdmi-stereo'
DEFAULT_SLAVE="$SLAVE_1"
cat <<EOF | sudo tee -a /etc/pulse/default.pa.d/zeroconf.pa
load-module module-combine-sink sink_name=combined sink_properties="device.description='Combined TV and PC' slaves=${SLAVE_1},${SLAVE_2}"
set-default-sink ${DEFAULT_SLAVE}
EOF
pulseaudio --kill
pulseaudio --start

Вот и всё 😄 … Вот только не работает. Не знаю почему. Устройство-то добавилось, выбрать можно, ошибок в журнале нет, но звук идёт только в наушники и не идёт на ТВ. В то же время, просто выбираю ТВ - работает. Значит просто этот модуль не может совместить туннельное и простое устройство. Решил всё равно написать, может кому пригодиться.

Wireguard Ansible

Tue, 16 Nov 2021 00:00:00 +0000

GitHub

Обновление от 25 ноября 2022 ¶

Перешёл на классический wg-quick с этого Ansible. Решение получилось в целом много проще технически, а по функционалу меня удовлетворяет.

Обновление от 21 марта 2022 ¶

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

Введение ¶

Wireguard – обалденный, простой VPN, который уже включён в состав ядра. Очень мощный и простой инструмент. Ставиться в разы проще чем OpenVPN.

Постановка задачи ¶

Я живу в Украине и, к сожалению, у нас заблокированы некоторые Интернет ресурсы, а доступ иногда нужен.
Хочется иметь возможность достучаться по удалённому доступу с телефона или чужого компьютера до домашнего сервера.
Хочется, чтобы на ПК проксировался трафик только на домены из списка, а не вообще всё.

Вот с такими запросами я стал работать. Для себя, всё для себя. Больше пока никому не нужен, хотя на GitHub выложил. Выложил - это тоже громко сказано. Ни документации, ничего! Да! Лень просто написать… Ну да ладно.

Обзор решения ¶

Использовал Ansible, который может настроить сразу сеть. Что умеет:

Использование константного preshared ключа для всех соединений
Возможность прописывать свои AllowedIPs
Возможность добавлять пиров со статически прописанными ключами (на телефоне-то Ansible не запустить)
Автоматический подбор свободных rt_table ID и fwmark-ов
Возможность за один запуск поднимать больше одной сети на тех же машинах!

Чего не умеет.

Отдельный запуск на одном или подгруппе хостов. Только на всём сразу.

Разбираем переменные Ansible ¶

all.yml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


# CIDR сетей
wireguard_networks:
 home: 192.168.99.0/24
 vpn: 10.0.0.0/24
# марки для маршрутизации - для каждой сети своя
wireguard_fwmarks:
 home: 1000
 vpn: 2000
# по прешаренному ключу на сеть
wireguard_preshared_keys:
 home: longalphanum
 vpn: longalphanum
# ключи каждого сервера в каждой сети где он есть
wireguard_keys:
 home:
 public_host:
 public: longalphanum
 private: longalphanum
 home_server:
 public: longalphanum
 private: longalphanum
 laptop:
 public: longalphanum
 private: longalphanum
 vpn:
 public_host:
 public: longalphanum
 private: longalphanum
 laptop:
 public: longalphanum
 private: longalphanum
 smartphone:
 # у телефона, только публичный, так как приватный тут не нужен
 public: longalphanum
wireguard_addresses:
 # адреса каждого сервера в каждой сети
 home:
 public_host: 192.168.99.1
 laptop: 192.168.99.2
 home_server: 192.168.99.3
 vpn:
 public_host: 10.0.0.1
 laptop: 10.0.0.2
 smartphone: 10.0.0.3

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


# это переменнные для отдельно взятого хоста - сервера
wireguard_enabled: yes
# wireguard-tools поставили уже, по-этому тут это выключаем
wireguard_install_tools: no
# список пиров
wireguard_peers:
 # для домашней сети
 home:
 # первый пир это наш ноутбук, на котором мы Ansible запускаем
 - name: laptop
 # а второй, имеет inventory_hostname home_server
 - name: home_server
 # и поддерживай сеть, чтобы всегда можно было достучаться,
 # потому что сервер за NAT-ом
 keepalive_seconds: 25
 # вторую сеть только с телефона и ПК использовать будем
 vpn:
 - name: laptop
 # а вот и телефон
 - name: smartphone
# ну и выберем порты, по которым он должен слушать
# для остальных можно не указывать - не важно, а вот
# для сервера лучше всё сразу прописать статикой
# чтобы ничего не было перегенерено если что
# и не нужно было перенастраивать всех клиентов
# на новые креды сервера
wireguard_ports:
 home: 2000
 vpn: 3000
# включаем маскарад, чтобы сервер через себя в Интернет
# выпускал трафик пиров как gateway
wireguard_masquarade:
 vpn: auto

А теперь укажем переменные для ноутбука, за которым работаем.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


# и опять включем роль явным образом
wireguard_enabled: yes
wireguard_peers:
 vpn:
 # из пиров в сети VPN только наш публичный сервер
 - hostname: public_host
 # у нас есть домен, который указывает на сервер чтобы адрес не запоминать
 endpoint: vpn.example.com
 # направляем через VPN весь трафик, и тут важно понимать,
 # что мы не весь трафик системы пускаем через wireguard
 # мы говорим wireguard-у на хосте, что в эту сетку пускай
 # всё, что к тебе конкретно пришло на выход и не подходит
 # в другие сети по более узким правилам
 allowed_ips:
 - 0.0.0.0/0
 - ::0
 keepalive_seconds: 25
 home:
 # точкой связи для домашней сети является он же
 - hostname: public_host
 endpoint: vpn.example.com
 keepalive_seconds: 25
 allowed_ips:
 # а в путях прописываем только подсеть домашней сети
 - "{{ wireguard_networks.home }}"
# и включаем проксирование отдельных доменов через сеть VPN
wireguard_proxy_domains:
 vpn:
 list:
 - site.we.want.access
 - another.one

Ну и домашний сервер, просто должен быть доступен. В VPN ему ни к чему.

1
2
3
4
5
6
7
8
9


# тут я надеюсь уже всё понятно
wireguard_enabled: yes
wireguard_peers:
 home:
 - hostname: public_host
 endpoint: vpn.example.com
 allowed_ips:
 - "{{ wireguard_networks.home }}"
 keepalive_seconds: 25

Итог ¶

С любого пира на любой есть доступ в пределах сети. Трафик находит свой путь через публичный сервер. Всё работает. Померял iperf-ом, из 80 Мбит, Wireguard отдаёт ~60 - как по мне, так это блестящий результат!

Age шифрование

Sun, 12 Sep 2021 00:00:00 +0000

Введение ¶

Age – новейшая утилита, написанная на Go, которая по заверениям выполняет прекрасное потоковове ассиметричное шифрование и не только. По виду действительно простая и, мне лично, чем-то напоминает Wireguard (утилиту wg). Шифрует входоной поток в выходной. Просто и понятно. Из отличительных особенностей, можно зашифровать для группы получателей, так чтобы каждый мог расшифровать.
На повестке дня у меня нынче мысли о создании бекапов btrfs разделов с домашними фото\видео куда-то в облако, например в Backblaze, чтобы подешевле было. Вот только облакам доверия нет (никаким). Данные нужно шифровать. Раздел, допустим, 300 GiB и грузить его одним куском, да и хранить в целом, очень не интересно. Split поможет раздробить файл на куски.

Генерируем ключ ¶

Утверждается, что можно просто SSH public key использовать, кроме ключа age. Попробуем и то, и то.

1
2
3
4


ssh-keygen -t ed25519 -o -a 150 -qN '' -f id_ed25519
age-keygen -o age.key
age-keygen -y age.key > recipients.txt
cat id_ed25519.pub >> recipients.txt

Получаем вот такие ключи.

1
2


age1qrcn5glms66thfv9cj5pzdwl3z87t9evzaqlxdj9ksravmw3mypswawuag
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIObk2OuhYlrr3ezvf5gAWXgUdcLn4XQFa8B8GCRpBr9q user@host

Шифрование ¶

Для простоты, просто сгенерим 10 MiB со случайными данными и сразу сделаем копию, чтобы потом сравнить хеш-суммы.

1
2


dd if=/dev/urandom of=data bs=1M count=10
cp data data.orig

Теперь можно шифровать. Использую и архивацию, и разделение.

1

tar -cz data | age -R recipients.txt | split -b 1MiB -d - chunk-

Получаем 10 файлов от chunk-00 до chunk-10.

Расшифровка ¶

Расшифруем используя SSH ключ.

1
2


cat chunk-* | age -d -i id_ed25519 | tar xz
mv data data.ssh

Расшифруем используя Age ключ.

1
2


cat chunk-* | age -d -i age.key | tar xz
mv data data.age

Проверка ¶

Сверим Hash суммы.

1
2
3
4


# sha256sum data*
5ebc271a22cfb9af0430253c2d8f3b83d1c3f5fdd062dd0ecc6c1f2d7925b828 data.age
5ebc271a22cfb9af0430253c2d8f3b83d1c3f5fdd062dd0ecc6c1f2d7925b828 data.orig
5ebc271a22cfb9af0430253c2d8f3b83d1c3f5fdd062dd0ecc6c1f2d7925b828 data.ssh

Вроде работает. Как и всегда, позже найдут какие-то уязвимости, но использовать можно. Множественные адресаты это интересная особенность.

Установка Python пакетов в оффлайн

Sun, 29 Aug 2021 00:00:00 +0000

Допустим, мы хотим поставить Ansible в оффлайне.

Создаём Virtualenv ¶

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

1
2


python3 -m pip install --upgrade --user virtualenv
python3 -m pip virtualenv venv

Теперь можем активировать его.

1

. ./venv/bin/activate

Теперь до конца терминальной сессии, мы в изолированном Python virtualenv.

Готовим нужные пакеты ¶

Установив в чистом окружении только то, что нужно, мы заодно подтянем все зависимости, но кроме всего прочего, захватите с собой ещё setuptools и pip.

1

python3 -m pip install --upgrade pip setuptools ansible

Теперь можем составить список того, что получилось.

1

python3 -m pip freeze > requirements.txt

Можно просто дописать pip и setuptools в requirements.txt без указания версий (если их вообще нет в списке)

Пример requirements.txt

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


ansible==3.4.0
ansible-base==2.10.11
cryptography==2.8
jinja2==2.11.3
netaddr==0.7.19
pbr==5.4.4
jmespath==0.9.5
ruamel.yaml==0.16.10
ruamel.yaml.clib==0.2.2
MarkupSafe==1.1.1
pip
setuptools

Имея список пакетов с зависимостями, мы можем их скачать даже без venv.

1

python3 -m pip download --dest my-pip-packages -r requirements.txt

Для удобства, упакуем всё в архив.

1

tar -cpvzf pips.tgz my-pip-packages requirements.txt

Устанавливаем в окружении без Интернета ¶

Python должен быть уже установлен заранее

Распакуем свой архив и установим всё что принесли. Pip и setuptools поставим отдельно в начале, а потом всё остальное. Если команда выполняется не от имени суперпользователя, то нужно либо:

Добавить sudo в начале
Добавить аргумент --user к pip-у для установки пакетов только для пользователя выполняющего команду

1
2
3


tar -xpzvf pips.tgz
python3 -m pip install --upgrade --no-index --find-links python-packages pip setuptools
python3 -m pip install --upgrade --no-index --find-links my-pip-packages -r requirements.txt

Теперь можно запускать Ansible!

1
2
3
4
5
6
7


root@289f34a67cbd:/host# ansible --version
ansible 2.10.11
 config file = None
 configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
 ansible python module location = /usr/local/lib/python3.6/dist-packages/ansible
 executable location = /usr/local/bin/ansible
 python version = 3.6.9 (default, Jan 26 2021, 15:33:00) [GCC 8.4.0]

Локали ¶

Случалось так, что в сильно урезанном окружении, как, к примеру, Docker Ubuntu 18.04, утановка пакетов падает со следующей ошибкой.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


ERROR: Exception:
Traceback (most recent call last):
 File "/usr/local/lib/python3.6/dist-packages/pip/_internal/cli/base_command.py", line 173, in _main
 status = self.run(options, args)
 File "/usr/local/lib/python3.6/dist-packages/pip/_internal/cli/req_command.py", line 203, in wrapper
 return func(self, options, args)
 File "/usr/local/lib/python3.6/dist-packages/pip/_internal/commands/install.py", line 316, in run
 reqs, check_supported_wheels=not options.target_dir
...
 File "/usr/local/lib/python3.6/dist-packages/pip/_internal/operations/prepare.py", line 249, in unpack_url
 unpack_file(file.path, location, file.content_type)
 File "/usr/local/lib/python3.6/dist-packages/pip/_internal/utils/unpacking.py", line 256, in unpack_file
 untar_file(filename, location)
 File "/usr/local/lib/python3.6/dist-packages/pip/_internal/utils/unpacking.py", line 226, in untar_file
 with open(path, "wb") as destfp:
UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in position 117: ordinal not in range(128)

Решается установкой переменных окружения перед установкой пакетов.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


export LANGUAGE=""
export LANG="C.UTF-8"
export LC_CTYPE="C.UTF-8"
export LC_NUMERIC="C.UTF-8"
export LC_TIME="C.UTF-8"
export LC_COLLATE="C.UTF-8"
export LC_MONETARY="C.UTF-8"
export LC_MESSAGES="C.UTF-8"
export LC_PAPER="C.UTF-8"
export LC_NAME="C.UTF-8"
export LC_ADDRESS="C.UTF-8"
export LC_TELEPHONE="C.UTF-8"
export LC_MEASUREMENT="C.UTF-8"
export LC_IDENTIFICATION="C.UTF-8"
export LC_ALL="C.UTF-8"

Создаём виртуальную камеру для конференций

Thu, 22 Jul 2021 00:00:00 +0000

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


#!/usr/bin/env sh
set -e

# label for the new webcam as it will be seen in browser
LABEL="VirtualCam #0"

# module insertion in case if it was not inserted during this boot
if ! lsmod | grep -qE '^v4l2loopback'; then
 # camera is being created during the module loading
 sudo modprobe v4l2loopback devices=1 exclusive_caps=1 max_buffers=2 card_label="$LABEL"
 # wait for a while to finish module initialization
 sleep 1
fi

# path to media file
F="${1:?File is not passed}"
# getting path to newly created camera device
DEV="$(v4l2-ctl --list-devices 2>/dev/null | grep -A1 "$LABEL" | grep -oE '/dev/video[0-9]+')"

if [ ! -f "$F" ]; then
 # check in case if media file path does not exists
 echo "error: file $F does not exists" >&2
 exit 1
fi

# get file type and use proper streaming command
case "$(file --mime-type --brief "$F" | cut -d/ -f1)" in
 video)
 # in case if file is video
 ffmpeg -re -i "$F" -f v4l2 -vcodec rawvideo -pix_fmt yuv420p "$DEV"
 ;;
 image)
 # in case if file is picture
 ffmpeg -loop 1 -re -i "$F" -f v4l2 -vcodec rawvideo -pix_fmt yuv420p "$DEV"
 ;;
 *)
 # in case if file is something else
 echo 'error: unknown mime type' >&2
 exit 2
 ;;
esac

Как итог, получилось стримить Rick Ashley - Never Gonna Give You Up.

Из недостатков стоит упомянуть потребление почти целого ядра ffmpeg-ом. Также, мы, понятное дело, передаём только картинку, без звука.

Обновление CEPH

Mon, 16 Nov 2020 00:00:00 +0000

Вводные ¶

Имеется такой кластер

Ceph 15.2.1 установленный с cephadm
14 OSD
3 MON
3 RGW
3 MDS
3 CRUSH

Вышла версия 15.2.4, хотим обновиться.

Запускаемся ¶

Cephadm предоставляет механизм для обновления, но с ходу у меня он не завёлся, пришлось его сопровождать. Давайте посмотрим что вообще нужно обновить.

1

ceph orch upgrade check ceph/ceph 15.2.4

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

ceph status - для получения обобщённой информации о состоянии кластера. Можно в отдельном терминале запустить так: watch -n 10 ceph status
ceph status -W cephadm - вот эту команду точно стоит запустить в терминале, чтобы смотреть именно лог оркестратора.

Временные трудности ¶

Вызываем ceph orch ps и видим, что все мониторы и менеджеры обновлены, хорошо, но теперь мы в HEALTH_ERROR с ошибкой, что я привёл ниже.

1

module 'cephadm' has failed: auth get failed: failed to find client.crash.01 in keyring retval: -2

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

1
2
3
4
5
6
7


for i in $(ceph orch ps | grep -oE 'crash.[0-9]+'); do
 ceph auth get-or-create "client.$i" mgr "profile crash" mon "profile crash"
done
ceph orch upgrade stop
ceph mgr module disable cephadm
ceph mgr module enable cephadm
ceph orch upgrade start ceph/ceph 15.2.4

И вот мы видим, что crash-ы тоже готовы, хорошо, но дальше что-то всё висит. Да, HEALTH_OK, но ceph orch ps показывает, что все OSD ещё на старой версии. В логах видим следующее.

1

Upgrade: It is NOT safe to stop osd.0

Ага, оркестратор боится останавливать демоны osd с данными. Поможем. У меня ситуация обстоит так.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 14.00000 root default
-3 5.00000 host 01
 0 hdd 1.00000 osd.0 up 1.00000 1.00000
 1 hdd 1.00000 osd.1 up 1.00000 1.00000
 2 hdd 1.00000 osd.2 up 1.00000 1.00000
 3 hdd 1.00000 osd.3 up 1.00000 1.00000
 4 hdd 1.00000 osd.4 up 1.00000 1.00000
-5 5.00000 host 02
 5 hdd 1.00000 osd.5 up 1.00000 1.00000
 6 hdd 1.00000 osd.6 up 1.00000 1.00000
 7 hdd 1.00000 osd.7 up 1.00000 1.00000
 8 hdd 1.00000 osd.8 up 1.00000 1.00000
 9 hdd 1.00000 osd.9 up 1.00000 1.00000
-7 4.00000 host 03
10 hdd 1.00000 osd.10 up 1.00000 1.00000
11 hdd 1.00000 osd.11 up 1.00000 1.00000
12 hdd 1.00000 osd.12 up 1.00000 1.00000
13 hdd 1.00000 osd.13 up 1.00000 1.00000

Сначала я останавливал osd по одному.

1

ceph osd out osd.0

Потом расслабился и стал выбрасывать по очереди целый сервер. Когда мы выводим из оборота osd.0, через время, когда балансировка заканчивается, ceph status -W cephadm жалуется уже на osd.1, а ceph orch ps показывает, что osd.0 обновлён. Мысль ясна, главное назад не забыть ввести.

1

ceph osd in osd.0

Короче говоря, выводим osd первого сервера, ждём пока cephadm жалуется на следующие и вводим обратно. Дальше, стоит дождаться HEALTH_OK, прежде чем выводить osd следующего сервера, а то так и без данных не долго остаться…
Опираясь на свой osd tree, план, если делать начисто, таков:

out 0, 1, 2, 3, 4
ждём жалобу на 5
in 0, 1, 2, 3, 4
ждём HEALTH_OK
out 5, 6, 7, 8, 9
ждём жалобу на 10
in 5, 6, 7, 8, 9
ждём HEALTH_OK
out 10, 11, 12, 13
смотрим, что всё обновилось ceph orch ps
in 10, 11, 12, 13
ждём HEALTH_OK

1
2
3


╔═╗╔═╗╔═╗╦ ╦ ╦ ╦╔═╗╔═╗╦═╗╔═╗╔╦╗╔═╗╔╦╗┬
║ ║╣ ╠═╝╠═╣ ║ ║╠═╝║ ╦╠╦╝╠═╣ ║║║╣ ║║│
╚═╝╚═╝╩ ╩ ╩ ╚═╝╩ ╚═╝╩╚═╩ ╩═╩╝╚═╝═╩╝o

Заметки ¶

Кластер полупустой, по этому было быстро. Будь оно иначе, заняло бы дни…

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


% sudo ceph osd df [22]
ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META AVAIL %USE VAR PGS STATUS
 0 hdd 1.00000 1.00000 5.5 TiB 1.4 GiB 438 MiB 39 KiB 1024 MiB 5.5 TiB 0.03 1.11 37 up
 1 hdd 1.00000 1.00000 5.5 TiB 1.4 GiB 454 MiB 2.2 MiB 1022 MiB 5.5 TiB 0.03 1.12 46 up
 2 hdd 1.00000 1.00000 5.5 TiB 1.3 GiB 314 MiB 1.0 MiB 1023 MiB 5.5 TiB 0.02 1.01 24 up
 3 hdd 1.00000 1.00000 5.5 TiB 1.2 GiB 161 MiB 2.5 MiB 1022 MiB 5.5 TiB 0.02 0.90 34 up
 4 hdd 1.00000 1.00000 5.5 TiB 1.2 GiB 242 MiB 21 KiB 1024 MiB 5.5 TiB 0.02 0.96 34 up
 5 hdd 1.00000 1.00000 5.5 TiB 1.2 GiB 212 MiB 3.0 MiB 1021 MiB 5.5 TiB 0.02 0.93 34 up
 6 hdd 1.00000 1.00000 5.5 TiB 1.5 GiB 485 MiB 533 KiB 1023 MiB 5.5 TiB 0.03 1.14 35 up
 7 hdd 1.00000 1.00000 5.5 TiB 1.3 GiB 280 MiB 1.8 MiB 1022 MiB 5.5 TiB 0.02 0.99 41 up
 8 hdd 1.00000 1.00000 5.5 TiB 1.3 GiB 265 MiB 19 MiB 1005 MiB 5.5 TiB 0.02 0.97 38 up
 9 hdd 1.00000 1.00000 5.5 TiB 1.4 GiB 359 MiB 949 KiB 1023 MiB 5.5 TiB 0.02 1.05 28 up
10 hdd 1.00000 1.00000 5.5 TiB 1.2 GiB 179 MiB 467 KiB 1024 MiB 5.5 TiB 0.02 0.91 33 up
11 hdd 1.00000 1.00000 5.5 TiB 1.1 GiB 132 MiB 2.8 MiB 1021 MiB 5.5 TiB 0.02 0.87 23 up
12 hdd 1.00000 1.00000 5.5 TiB 1.3 GiB 358 MiB 19 MiB 1005 MiB 5.5 TiB 0.02 1.04 36 up
13 hdd 1.00000 1.00000 5.5 TiB 1.3 GiB 301 MiB 734 KiB 1023 MiB 5.5 TiB 0.02 1.00 39 up
 TOTAL 76 TiB 18 GiB 4.1 GiB 54 MiB 14 GiB 76 TiB 0.02
MIN/MAX VAR: 0.87/1.14 STDDEV: 0.00

Знакомство с Docker

Fri, 21 Aug 2020 00:00:00 +0000

Написано вместе с ReBrainMe

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

Задача данной статьи состоит в том, чтобы поставить и запустить Docker локально, начать знакомство с этой интереснейшей системой и усвоить основы.

Установка Docker ¶

У Docker есть официальные инструкции по установке. На практике, я пользовался установочным скриптом (для Linux):

1

curl -LO get.docker.com | sudo sh -

Если утилита curl у Вас не установлена, скачайте скрипт и выполните его вручную:

1

sh /path/to/downloaded/script.sh

Если Вы хотите установить определённую версию Docker, то можете воспользоваться установочными скриптами Rancher-a, которые можно подобрать и скачать здесь. Запускается так же, можете прямо в команде с curl адрес поменять, всё будет работать.

Настройка Docker ¶

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

Настроить logging driver ¶

Дело в том, что по умолчанию используется драйвер json-file, который по умолчанию не имеет ограничения на размер [JSON](https://ru.wikipedia.org/wiki/JSON#:~:text=JSON%20(%D0%B0%D0%BD%D0%B3%D0%BB.,JSON%20%D0%B1%D1%8B%D0%BB%20%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D0%BD%20%D0%94%D1%83%D0%B3%D0%BB%D0%B0%D1%81%D0%BE%D0%BC%20%D0%9A%D1%80%D0%BE%D0%BA%D1%84%D0%BE%D1%80%D0%B4%D0%BE%D0%BC.) файла, где будут скапливаться логи с соответствующего контейнера. Подправить на Linux это можно отредактировав файл /etc/docker/daemon.json. Файла, по умолчанию, может и не быть – создайте. Содержимое к добавлению:

1
2
3
4
5
6
7


{
 "log-driver": "json-file",
 "log-opts": {
 "max-size": "100m",
 "max-file": "1"
 }
}

Таким образом мы настраиваем json-file, чтобы он не создавал более одного файла с логами на контейнер, причём файл не должен превышать 100 МБ. Это всё можно переопределить на этапе запуска контейнера, но в будущем, эти умолчания освобождают от поисков ответа на вопрос: “Куда делить 6 ГБ за день?”

Запустить службу Docker ¶

Бывает, не запускается он сам после установки. Можно поправить на Linux с помощью:

1

sudo systemctl enable --now docker.service

Здесь, мы с помощью systemctl, запустили Docker Engine и поставили его в автозагрузку.

Добавить пользователя в группу docker ¶

Чтобы иметь возможность обращаться к Docker Engine от имени не привилегированного пользователя (без sudo), нужно добавить его в группу docker.

1

sudo usermod -aG docker "$USER"

Для того, чтобы изменения вступили в силу нужно перезагрузиться или воспользоваться ACL.

1

sudo setfacl -m "u:${USER}:rwx" /var/run/docker.sock

Знакомство с DockerHub ¶

Контейнеры, создаются из образов. Образ – упорядоченный набор слоёв файловой системы, которые были получены на этапе сборки. Люди делятся образами выкладывая их на Docker Registry. Самый популярный – DockerHub. Множество программных продуктов выкладываются здесь и поддерживаются официально, а есть много инструментов, собранных простыми людьми или небольшим сообществом, которые не уступают по качеству и поддержке официальным. Важно, смотрите, что Вы качаете и выполняете – noname не понятно какой и без документации, или официальную сборку, которая регулярно обновляется и сопровождается ясной документацией. Бывали слухи, что в noname образах майнеры попадались… но это больше редкость, чем правило (исходя из личного опыта).

Для примера, вот несколько ссылок на официальные образы: HaProxy, Nginx, PostgreSQL, MySQL, Grafana, Prometheus.

Запустим первый контейнер ¶

1

sudo docker run --rm -it -p 8080:80 nginx:stable-alpine

Открыв http://localhost:8080 видим:

Что мы сделали? Разберём команду по порядку.

sudo – запуск последующей команды от имени другого пользователя, по умолчанию – суперпользователя root.
docker – запускаем исполняемый файл Docker-а, который командная оболочка найдёт в одном из путей, найденных в переменной PATH.
run – создать и запустить новый контейнер.
–rm – после завершения его выполнения – удалить, чтобы место не занимал.
-i – присоединить stdin/out/err из командной оболочки в контейнер; запуск в интерактивном режиме.
-t – создать tty для контейнера.
-p 8080:80 – перенаправить порт 8080 с хоста на 80 внутри контейнера.
nginx:stable-alpine – использовать для создания контейнера образ nginx с тегом stable-alpine. Другие теги можно найти на странице Nginx на DockerHub.

Монтирование ¶

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

1
2


echo "Hello world! Date: $(date)" > /tmp/my_file.txt
sudo docker run --rm -it -p 8080:80 -v /tmp/my_file.txt:/usr/share/nginx/html/index.html:ro nginx:stable-alpine

Здесь мы создали файл /tmp/my_file.txt и примонтировали его по пути /usr/share/nginx/html/index.html. Согласно описанию контейнера, можно так же эмпирическим путём определить, что путь к файлам веб-сервера в стандартном конфигурационном файле именно /usr/share/nginx/html, а файл по умолчанию, который будет открываться как главная – index.html. Вот мы и монтируем с хоста в контейнер по найденному пути.

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

Запуск в фоновом режиме ¶

1

sudo docker run -d --name my1 -p 3000:3000 grafana/grafana

Здесь появилась пара новых ключей. -d – запуск в фоне. –name my1 – задать имя контейнеру “my1”, так как по умолчанию генерируется случайное, а мы хотим назначить своё. Проверим состояние контейнера.

1
2


sudo docker ps
sudo docker stats

Первая команда выводит информацию о всех запущенных контейнерах, вторая – отдаёт краткую сводку по потреблению ресурсов. Откроем Grafana.

Можем зайти, поизучать (логин admin, пароль admin), а потом остановить контейнер.

1
2


sudo docker stop my1
sudo docker ps -a

Как видим, контейнер остановлен, но не удалён. Можно вновь запустить, а можно удалить.

1
2


sudo docker start my1
sudo docker rm -f my1

Заключение ¶

Мы поставили Docker, познакомились с DockerHub, запустили пару контейнеров и опробовали базовые команды для запуска приложений с помощью Docker Community Edition.

Планы

Wed, 22 Jul 2020 00:00:00 +0000

Статьи к написанию ¶

Обратное SSH туннелирование. Была статья, да потерялась. Проброс порта с удалённого хоста на текущий используя SSH
Переезд с GHost на Hugo. О том как и почему я решился переехать на Hugo
Утилита k9s. Отличное приложение, которое я использую каждый день для работы с Kubernetes
Советы по Terraform. Трюки, примеры и полезные ссылки по работе с Terraform
Болтология о проявлении правила 20\80 в IT. Как многие знают, 20% усилий дают 80% результата, но для оставшихся 20% результата, нужно потратить целых 80% усилий. Из этого можно сделать много умозаключений
Wireguard Ansible. Статья о собственной разработке - Ansible плейбуки для установки и настройки Wireguard
Healthcheck.io. Замечательный сервис, с которым можно быть уверенным в том, что бекапы точно проходят.
Как искать и работать с Helm чартами.
Мой опыт с ArgoCD. (Стабильно, автоматизированно, гибко, но не без изъянов, причём значительных. Использую на большом проде с чистой душой. Рекоммендую)

Резюме

Wed, 22 Jul 2020 00:00:00 +0000

xFreeRDP

Tue, 07 Jul 2020 00:00:00 +0000

xFreeRDP – утилита для подключения по RDP c Linux. После переезда на Manjaro я не смог поставить Remmina, пришлось искать альтeрнативу. Этот вариант меня порадовал. Можно создать по однострочному скрипту для хостов, к которым Вы часто подключаетесь и пользоваться как каталогом.

1
2


#!/usr/bin/env sh
xfreerdp /v:1.2.3.4 /u:username /p:password /w:1360 /h:730 /drive:tmp,/tmp

Здесь я явно задаю размер дисплея для подключения и монтирую /tmp с локальной машины на удалённую, чтобы иметь возможность забрать какие-то файлы.

Архив

Wed, 01 Jul 2020 00:00:00 +0000

О себе

Wed, 01 Jul 2020 00:00:00 +0000

О себе ¶

Работаю системным инженером (DevOps), учусь и стараюсь делать своё дело хорошо. В процессе труда я понял, насколько всё, порою, плачевно с наличием системного понимания процессов протекающих на разных этапах жизненного цикла разработки ПО.
Обучался в ХАИ на компьютерного инженера и получил магистра в мае 2020. Вам стоит отнестись к сказанному на этом сайте критично - не стоит верить всему на слово. Я бываю невежествен во многих вопросах, но в любом случае стараюсь писать то, в чём уверен.
Почему блог на русском, а не на английском? - Очень много хорошего материала на англ. языке. Кто если не мы напишем лучше на русском?

Вектор целей ¶

Список содержит цели, которые я преследую поддерживая на плаву этот блог. Упорядочены по приоритету важности в порядке убывания:

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

Поиск

Wed, 01 Jul 2020 00:00:00 +0000

Rsnapshot

Tue, 12 May 2020 00:00:00 +0000

Введение ¶

Rsnapshot - классная утилита которая умеет:

Делать бекапы папок по пути в локальной системе и складывать их в бекап хранилище (специально отведённая папка тут же где-то)
Выполнять скрипты которые делают бекапы, ложат рядом с собой, а rsnapshot берёт эти данные и складывает в то же хранилище-папку
Может закинуть бекапы по sftp куда-то
Хранит только diff-ы между бекапами, что экономит место

Retantion ¶

У rsnapshot есть Retantion Policies (могу не точно называть), они в конфигурации начинаются с retain. Это описание абстрактных планов по поводу того, сколько последних копий бэкапов хранить. Я долго мучался пока не понял, что их названия ни на что не влияют. То есть, если план называется daily rsnapshot каждый день его запускать не будет, можете его в cron-е хоть раз в месяц запускать. Мне удобнее использовать для конфигурации (чтения, сопровождения) daily, weekly, monthly и т. д.

Те retention, которые в конфиге записаны ниже, считаються теми, что должны делаться реже верхних, то есть цифра у них должна быть меньше. Rsnapshot для каждого retention i+1 берёт содержимое со старшего сделанного для retention i. Пример:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


+ date
Tue May 12 05:58:33 UTC 2020
+ rsnapshot daily
+ ls -la /data/backups
total 48
drwxrwxr-x. 11 y.vlasov y.vlasov 4096 May 12 05:57 .
drwxrwxr-x+ 6 root root 4096 Apr 27 09:43 ..
drwxr-xr-x. 6 root root 4096 May 12 05:57 daily.0
drwxr-xr-x. 6 root root 4096 May 12 00:00 daily.1
drwxr-xr-x. 6 root root 4096 May 11 00:00 daily.2
drwxr-xr-x. 6 root root 4096 May 10 00:00 daily.3
drwxr-xr-x. 6 root root 4096 May 9 00:00 daily.4
drwxr-xr-x. 6 root root 4096 May 8 00:00 daily.5
drwxr-xr-x. 6 root root 4096 May 7 00:00 daily.6
drwxr-xr-x. 6 root root 4096 May 4 00:00 weekly.0
drwxr-xr-x. 6 root root 4096 May 2 00:00 weekly.1
+ rsnapshot weekly
+ ls -la /data/backups
total 48
drwxrwxr-x. 11 y.vlasov y.vlasov 4096 May 12 05:57 .
drwxrwxr-x+ 6 root root 4096 Apr 27 09:43 ..
drwxr-xr-x. 6 root root 4096 May 12 05:57 daily.0
drwxr-xr-x. 6 root root 4096 May 12 00:00 daily.1
drwxr-xr-x. 6 root root 4096 May 11 00:00 daily.2
drwxr-xr-x. 6 root root 4096 May 10 00:00 daily.3
drwxr-xr-x. 6 root root 4096 May 9 00:00 daily.4
drwxr-xr-x. 6 root root 4096 May 8 00:00 daily.5
drwxr-xr-x. 6 root root 4096 May 7 00:00 weekly.0
drwxr-xr-x. 6 root root 4096 May 4 00:00 weekly.1
drwxr-xr-x. 6 root root 4096 May 2 00:00 weekly.2

Backup, backup_script ¶

Как собственно он делает бекап? Rsnapshot делает бекапы по всем шагам, которые есть в конфигурации при каждом вызове.

backup - указываешь путь к папке, которую нужно сохранять и он её полностью к себе копирует в хранилище;
backup_script - указываешь путь к Shell скрипту, которые делает бекап сам и складывает результирующие файлы\папки рядом с собой, rsnapshot их перемещает в хранилище;
другие варианты - man rsnapshot.

План ¶

Создать папку по пути snapshot_root.
Написать rsnapshot.conf файл (по умолчанию берётся /etc/rsnapshot.conf).
Добавить вызов rsnapshot в планировщик - cron.

Пример ¶

Создадим папку snapshot_root: mkdir -p /data/backups.

Содержимое /etc/rsnapshot.conf ¶

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


## Заметка 1: Вы обязаны использовать табы для разделения аргументов в одной строке
config_version 1.2
snapshot_root /data/backups
no_create_root 1
## Заметка 2: Пути могут вариироваться от ОСи к ОСи
cmd_rm /usr/bin/rm
cmd_rsync /usr/bin/rsync
cmd_logger /usr/bin/logger
## Конфигурация планов сохранения
retain daily 7
retain weekly 4
## Настройки логгирования
verbose 2
loglevel 3
lockfile /var/run/rsnapshot.pid

## Собственно описание совершаемых действий
backup /data/ghost ghost/
backup_script /srv/my_soft/backup.sh my_soft/

Содержимое crontab ¶

1
2


0 0 * * * /usr/bin/rsnapshot daily 2>&1 | systemd-cat -t rsnapshot-daily
10 0 * * 0 /usr/bin/rsnapshot weekly 2>&1 | systemd-cat -t rsnapshot-weekly

Содержимое /srv/my_soft/backup.sh ¶

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


#!/usr/bin/env sh
set -e

CMD='''
rm -rf backup; \
pg_basebackup -U my_user -X stream -F plain -D backup 1>/dev/null 2>&1 && \
tar -C backup -czf - $(ls backup)
'''

docker exec \
 -w /tmp \
 my_soft.postgres \
 /bin/sh -c "$CMD 1>pg_basebackup.tgz

Содержимое daily.0 ¶

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


/data/backups/daily.0
├── ghost
│   └── data
├── my_soft
│   └── pg_basebackup.tgz
├── proxy
│   ├── certificates.tgz
│   └── haproxy.tgz
└── another_one
 └── another_backup_from_backup_script.tgz

5 directories, 4 files

RPM2PKG

Mon, 27 Apr 2020 00:00:00 +0000

Оказалось, что и Skype, и Slack можно поставить из AUR одной коммандой
1
yay -S slack-desktop skype
Статью оставил просто для истории

Перешёл на Manjaro и столкнулся с тем, что Skype и Viber поставляются в RPM и DEB. Что делать с Arch? На GitLab я поместил простой скрипт, который конвертирует rpm в pkg.

Использование скрипта ¶

Ставим зависимости

1
2


sudo pacman -S rpm rpm2cpio cpio git
python3 -m pip install --upgrade --user pip pyyaml jinja2

Клонируем репозиторий

1
2


git clone --depth 1 --single-branch git@gitlab.com:vlasov-y/rpm2pkg.git
cd rpm2pkg

Конвертируем

1
2
3
4


curl -fLO https://repo.skype.com/latest/skypeforlinux-64.rpm
python3 rpm2pkg skypeforlinux-64.rpm
# or add --install to install package automatically (interactive mode, will prompt you for confirmation)
# python3 rpm2pkg --install skypeforlinux-64.rpm

Устанавливаем

1

sudo pacman -U skype*.pkg.tar.gz

Удаляем

1

sudo pacman -R skype

Nextcloud

Sat, 25 Apr 2020 00:00:00 +0000

Запускаем стек ¶

Nextcloud - личное облако с галереей, проверкой почты, онлайн редактированием документов, прослушиванием аудио и радио, и т. д. Демо можно посмотреть здесь. Клон OwnCloud, пробовал вначале и его - претензий нет, но тут приложений чутка больше, как мне показалось.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


version: '3.7'

services:
 nextcloud:
 image: nextcloud:18.0.3-apache
 container_name: nextcloud
 restart: unless-stopped
 depends_on:
 - postgres
 ports:
 - '8080:80'
 volumes:
 - ./nextcloud:/var/www/html:rw
 logging:
 driver: json-file
 options:
 max-size: 100m

 postgres:
 image: postgres:11.7-alpine
 container_name: postgres
 restart: unless-stopped
 networks:
 - nextcloud
 volumes:
 - ./postgres:/var/lib/postgresql/data:rw
 environment:
 - POSTGRES_DB=nextcloud
 - POSTGRES_USER=nextcloud
 - POSTGRES_PASSWORD=94dbd6b2-bd9f-4867-99af-37f8e4444640
 logging:
 driver: json-file
 options:
 max-size: 100m

Заметки ¶

Пробовал обновиться с 16.0.4.1 до 18.0.3 через 17.0.5 - поломалось всё. Переустанавливал и закидывал назад файлы предварительно скачав их себе из ./nextcloud/data/username/files. Назад забросил используя синхронизацию через клиентское приложение.
Admin не удаляется через UI. Я создал себе аккаунт, а потом захотел удалить стандартный так как считаю, что аккаунты всегда должны быть именными, никакой шары. Удалить можно так:

1

sudo docker-compose exec -u www-data nextcloud php occ user:delete admin

Для правильной работы WebDAV, CalDAV нужно настроить перенаправление, если перед Nextcloud есть прокси. В моём случае HAproxy.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61


global
 log 127.0.0.1 local0
 stats socket /var/run/haproxy.sock mode 660 level admin expose-fd listeners
 stats timeout 30s
 user root
 group root
 daemon
 maxconn 4096
 nbproc 1
 # Default SSL material locations
 ca-base /etc/ssl/certs
 crt-base /etc/ssl/private
 # general SSL config
 ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
 ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tlsv12 no-tls-tickets
 tune.ssl.default-dh-param 4096
 ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
 ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tlsv12 no-tls-tickets

defaults
 log global
 mode http
 option http-buffer-request
 option httplog
 option dontlognull
 option forwardfor
 timeout connect 5s
 timeout client 25s
 timeout server 25s
 timeout tunnel 3600s
 timeout http-keep-alive 1s
 timeout http-request 15s
 timeout queue 30s
 timeout tarpit 60s
 compression algo gzip
 compression type text/plain text/css text/xml text/javascript application/javascript application/x-javascript application/xml application/json
 errorfile 400 /usr/local/etc/haproxy/errors/400.http
 errorfile 403 /usr/local/etc/haproxy/errors/403.http
 errorfile 408 /usr/local/etc/haproxy/errors/408.http
 errorfile 500 /usr/local/etc/haproxy/errors/500.http
 errorfile 502 /usr/local/etc/haproxy/errors/502.http
 errorfile 503 /usr/local/etc/haproxy/errors/503.http
 errorfile 504 /usr/local/etc/haproxy/errors/504.http

frontend http_https
 bind :80
 bind :443 ssl crt /certificates/cloudflare.haproxy alpn h2,http/1.1
 # acls
 acl dav path_reg -i ^/.well-known/(carddav|caldav).*$
 acl webfinger path_reg -i ^/.well-known/(carddav|caldav).*$
 # proxy headers
 http-request set-header X-Forwarded-Port %[dst_port] if forwarded_port
 # http-response set-header Access-Control-Allow-Credentials "true"
 http-request add-header X-Forwarded-Proto https if https forwarded_proto
 http-request replace-path (.*) /remote.php/dav if dav
 http-request replace-path (.*) /public.php?service=webfinger if webfinger
 default_backend cloud

backend nextcloud
 http-response set-header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload;"
 server default nextcloud:80 check

Авторизация крутилась бесконечно, и лишь F5 нам позволял входить. Проблемы на ПК не стало, но как с клиентом для Android быть? Тут, оказалось, можно очень просто, решить проблему раз и навсегда - добавь в конфиг волшебное ты слово и сможешь заходить и выходить.

Remmina

Wed, 22 Apr 2020 00:00:00 +0000

Отличное клиентское приложения для подключения по RDP/VNC/etc. Установил на Ubuntu 18.04 вот так:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


sudo add-apt-repository ppa:remmina-ppa-team/remmina-next
sudo apt update
sudo apt install remmina \
 remmina-plugin-exec \
 remmina-plugin-kwallet \
 remmina-plugin-nx \
 remmina-plugin-rdp \
 remmina-plugin-secret \
 remmina-plugin-spice \
 remmina-plugin-vnc \
 remmina-plugin-www \
 remmina-plugin-xdmcp \
 libfreerdp-plugins-standard
sudo ln -s /usr/lib/x86_64-linux-gnu/libssh.so.4 /usr/lib/x86_64-linux-gnu/libssh_threads.so.4

Больше информации у них на странице.

Знакомство с CEPH

Wed, 22 Apr 2020 00:00:00 +0000

Установка ¶

CEPH - распределённое сетевое хранилище, которое выбрасывает S3, iSCSI, RBD etc. Классная вещь, документации много, но очень сильно подводит то, что не сразу ясно стало, как правильно установить.

Rook ¶

Официально рекомендуемый способ установки в Kubernetes. Опыт ребят из Фланта-а можно почитать здесь.

Cephadm ¶

Написал на основе этого Ansible playbook-и и успешно эксплуатировал кластер развёрнутый на хосте. По локалке принял в себя 40 Gib за 2 минуты и остался жив :)

Deprecated / not recommended ¶

То, что я пробовал, а потом оказалось, что оно либо не рабочее, либо deprecated:

ceph-deploy где-то в документации нарывался на то, что этот способ не рекомендуется. Жаль потратил на него на тот момент уже пару дней. Ссылку привести не могу, у ребят истёк SSL сертификат и из-за HTST меня не пускает на сайт с документацией :)
ceph ansible - жирно, классно, много функционала, но master CentOS 7 уже не поддерживает, мониторы у меня так и не засинхронизировались, возможности поставить dashboard без мониторинга я не нашёл, реализовал сам, набрался опыта с Ansible, но потом полезли новые проблемы и я с этого комбайна слез на cephadm, чему очень рад.

Полезные команды ¶

Ну прежде всего, вот понравившийся мне cheatsheet.
Посмотреть список используемых винтов по серверам:

1
2
3


ceph orch device ls
ceph device ls
ceph device ls-by-host ceph-server-0

Посмотреть сводку занимаемого места.

1
2
3


ceph osd df
ceph df
ceph df | grep -oE '[0-9.]+\s*[a-zA-Z]+$' | uniq | sort -n

Посмотреть состояние кластера.

1
2


ceph status
ceph -w

Посмотреть инфраструктуру, какие сервисы\контейнеры работают и где.

1
2


ceph orch ls
ceph orch ps

Замена OSD ¶

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

Кластер должен быть в состоянии HEALTH_OK
Выводим OSD из кластера
Удаляем демон (контейнер по факту), который держит этот osd
Делаем purge
Очищаем раздел
Подключаем снова
Ждём HEALTH_OK

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


# OSD который мы хотим пересоздать
OSD='osd.0'

# находим хост
HOST="$(ceph device ls | awk "/${OSD}/{print \$2}" | cut -d: -f1)"

# и имя блочного устройства отведённого под OSD
DEV="/dev/$(ceph device ls | awk "/${OSD}/{print \$2}" | cut -d: -f2)"

# п.1
ceph health | grep -q 'HEALTH_OK'

# п.2
ceph osd out "$OSD"

# п.3
ceph orch daemon rm "$OSD" --force

# п.4
ceph osd purge "$OSD" --force

# п.5
ceph orch device zap "${HOST}:${DEV}" --force

# п.6
NEW_ID="osd.$(ceph orch daemon add osd "${HOST}:${DEV}' | awk '{print $3}')"
sleep 5
ceph osd crush reweight "$NEW_ID" 1

# п.7
while ! ceph health | grep -q 'HEALTH_OK'; do
 sleep 5
done

Из моего опыта, на замену OSD в котором было 15 GiB занято, уходит 30 минут. Тестировал на трёх CX21 Hetzner.

RBD and Docker ¶

Запуск RBD и связка с Docker:

Создать пул.
Проинициализировать пул.
Создать пользователя для запуска.
Выключить лишние фичи. Дело в том, что в ядре линукс до 4.17 не поддерживается ряд фич для RBD, которые пришлось отключить. Посмотреть справку можно так:

1

ceph config help rbd_default_features

Поставить Docker volume plugin.
Проверить на контейнере.
Примонтироваться и посмотреть, есть ли файл.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# п.1
ceph osd pool create rbd

# п.2
rbd pool init rbd

# п.3
ceph auth get-or-create client.rbd mon 'profile rbd' osd 'profile rbd pool=rbd' mgr 'profile rbd pool=rbd' > /etc/ceph/ceph.client.rbd.keyring

# п.4
ceph config set global rbd_default_features 7

Ставил вот этот volume driver. Всё остальное, что находилось, последний раз обновлялось 3-4 года назад (проект скорее мёртв, чем жив). Кроме того, этот драйвер не требует запуска чего либо на стороне, встраивается в сам Docker. Поставить можно так:

1
2
3
4
5
6
7
8
9


# п.5
docker plugin install wetopi/rbd \
 --alias=rbd \
 --grant-all-permissions \
 LOG_LEVEL=1 \
 RBD_CONF_POOL=rbd \
 RBD_CONF_CLUSTER=ceph \
 RBD_CONF_KEYRING_USER=client.rbd \
 MOUNT_OPTIONS='--options=noatime,discard'

Запустим простой docker-compose стек и примонтируем образ:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


version: "3.8"

services:
 test:
 image: alpine
 command: sh -c 'cat /vol/test; date | tee /vol/test'
 volumes:
 - data-volume:/vol

volumes:
 data-volume:
 name: vol1
 driver: rbd
 driver_opts:
 size: 123 # MiB

Запускаем и проверяем:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# п.6
sudo docker-compose up

# п.7
rbd map vol1
mkdir /tmp/vol1
mount /dev/rbd0 /tmp/vol1
cd /tmp/vol1
ls -la
cat test
cd /
umount /tmp/vol1
rbd unmap /dev/rbd0

Настройка командной строки

Wed, 22 Apr 2020 00:00:00 +0000

Написано вместе с ReBrainMe

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

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

Оболочки командной строки ¶

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

bash – де-факто стандартная оболочка, базовая автоподстановка и дополнение путей, есть в большинстве дистрибутивов по умолчанию, часто используется как оболочка для скриптов.
fish и zsh – две разные оболочки, которые намного превосходят bash по функционалу, часто на слуху.
ksh, tsh, csh … другие оболочки, могут быть ничем не хуже и даже лучше, просто чуть менее распространены

Задача данной статьи субъективно разобраться в том, чем действительно нужно занимать окно терминала и предложить решение на базе zsh.

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

Требования к оболочке ¶

Автодополнение путей. Это бесспорно главная функция, которая требуется для перемещения по древу директорий. Казалось бы, в Bash по умолчанию есть автодополнение путей по нажатию Tab дважды. Попробуйте Zsh – там нужно нажать Tab один раз, мелочь казалось бы … А теперь вернитесь на Bash :) Кроме того, Zsh можно настроить таким образом, что выбрасывается список файлов подпадающих под заданный префикс, что лишает необходимости прерывать ввод и делать ls -la, можно вообще стрелочками вариант выбрать. Это не часто используется, но удобно.
Поиск по истории команд. Если Вы уже перешли на ranger, то главным значимым для Вас требованием скорее всего станет это. Сначала мы узнаём про Ctrl+R для поиска команды в истории уже набранных. Удобно, но не совсем. В Zsh можно просто набрать кусочек команды и стрелочками выбрать нужную из автоподсказки. Субъективно удобнее и вот почему: для показа следующей команды из истории нужно опять нажать Ctrl+R, что не совсем удобно, особенно когда прощёлкал нужную.
Выделение начала приглашения ко вводу. Когда листаешь большое количество логов в терминале от разных команд, начинаешь теряться и тратить дополнительное время на различение того, к какой команде относиться тот или иной блок логов, где сама команда и т. д. Выделять текст приглашения ко вводу действительно нужно, но не так, чтобы он затмевал всё… Зачастую, первое что меняет начинающий пользователь нестандартной оболочки – это содержимое переменной PS1. Вот неплохое описание переменных PS1-4.
Легковесность. Вкратце: когда ломишься на сервер, на котором loadavg в десятки раз превышена, очень жалеешь, что поставил в motd или начало .zshrc (.bashrc) прожорливый код по выводу развёрнутой статистики о потреблении ресурсов процессора, памяти, сети, диска и т. д.
Не перегруженность. Пусть и выбрана zsh для ежедневного пользования, все скрипты пишу с shabang на классический sh, потому что она практически везде есть, и синтаксис унифицирован. Иными словами, не рекомендуется писать скрипты используя нестандартные синтаксисы крутых оболочек, заморочишься ставить их на каждый сервер.
Комфортность. Эффективность и комфорт, всё-таки, плотно связаны. Поставить полупрозрачную картинку на фон или подобрать шрифты по вкусу тоже очень важно, когда ловишь себя на мысли, что корявые шрифты и угловатость интерфейса отбивает желание трудиться напрочь. Главное не переусердствовать.

Алиасы ¶

Очень удобно объявлять алиасы для ускорения набора команд.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


alias ..="cd .. && ls -lhA --color=auto"
alias a="ls -lhA --color=auto"
alias d="sudo docker"
alias dc="sudo docker-compose"
alias die="sudo shutdown now"
alias e="exit"
alias g="git"
alias j="sudo journalctl"
alias k="kubectl"
alias l="ls -lh --color=auto"
alias la="ls -lhA --color=auto"
alias p="ping 8.8.8.8"
alias r="ranger"
alias reborn="sudo shutdown -r now"
alias s="sudo"
alias sctl="sudo systemctl"
alias sr="screen -R"
alias svi="sudo vim"
alias svim="sudo vim"
alias t="terraform"

Ну и немного юмора: alias please=‘sudo’ сделает Ваше общение с компьютером намного мягче.

Конфигурация zsh ¶

Как можно заметить, выделяется каждая команда между операндами разделения типа ; && |, при этом команда вводиться на второй строке, после приглашения с указанием каталога текущей директории и имени пользователя с хостом, это сделало длинные команды более удобными для чтения и сопровождения. Справа честно взятое из стандартных настроек поставляемых к zsh в Manjaro указание текущей ветки Git репозитория. В случае наличия изменений, удалений, добавлений появляются жёлтый, зелёный, красный кружочки – много места не занимало, по этому решено оставить. Пусть будет. При наборе команды, предлагается последняя, которая подходит по префиксу. Подтвердить выбор можно нажав стрелочку вправо. Окно эмулятора Terminator.

Для установки и настройки окна терминала как в примере нужно сделать следующее.

Установить ohmyzsh
Скопировать .zshrc к себе в домашний каталог

1

install -o "$(id -u)" -g "$(id -g)" -m 0644 .zshrc ~/.zshrc

Распаковать плагины

1
2


sudo tar -xpzvf plugins.tgz /
sudo usermod -s "$(command -v zsh)" "$USER"

Сделать zsh интерпретатором по умолчанию

1

sudo usermod -s "$(command -v zsh)" "$USER"

Основы SSH

Mon, 09 Mar 2020 00:00:00 +0000

Введение ¶

Secure Shell - де-факто стандартный способ получения доступа к терминалу на удалённом\виртуальном сервере. На компьютере, куда нужно получить доступ устанавливается ssh сервер, на компьютер за которым работает оператор - ssh клиент. Посредством SSH можно:

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

На Linux и MacOS у нас есть терминал - SSH, как правило, установлен по умолчанию. Для Windows я использовал такие варианты:

MobaXTerm - удобно, но платно. Для некомерческого использования подходит, для использования в компании - придётся купить лицензию. Преимущества:
- сразу предоставляет файловый менеджер с drag-n-drop файлов на целевую систему
- нормальная подстветка и поддержка RSA ключей
Git - при установке Git-a, он в комплекте поставляет Git Bash и SSH клиент. Очень приближённая среда к обычному Bash.

Как подключаться? ¶

1

ssh [-p <ssh порт>] <пользователь>@<ip целевого хоста>

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

Копирование файлов ¶

Скопировать файлы на целевой хост, можно с помощью scp.

1

scp [-P <ssh порт>] /path/to/local/file <пользователь>@<ip целевого хоста>:<путь на сервере назначения>

Обратите внимание:

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

Первый пост в Ghost

Sun, 08 Mar 2020 00:00:00 +0000

Сейчас блог написан на Hugo. Эта статья является первым постом из старого блога, который, как раз, был на Ghost.

Заметки

Первая статья. Вспомнился рассказ Айзека Азимова “Последний вопрос”, прослушанный по пути на работу в один из обычных дней. Хорошая вещь - рекомендую.
Писать хорошие статьи, прочтение которых будет разумной тратой времени, не так просто, как могло показаться. Причин тому две:

Мысли должны быть полезными.
Изложение должно быть систематизированным.

Система запущена на Ghost - сервер хороший, шустренький, запустился легко, инструментария для такого псевдо-блогера как я более чем хватает. Есть встроенны плагин для выбора картинок с Unspalsh - изображения, которые можно публиковать и не боятся, что к тебе придут с претензией на нарушение авторских прав.
docker-compose.yml, которым это всё дело можно с лёгкостью поднять, представлен ниже.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


version: '3.7'

services:
 ghost:
 image: ghost:3.9.0-alpine
 container_name: ghost
 restart: unless-stopped
 port:
 - '80:2368'
 volumes:
 - /data/ghost:/var/lib/ghost/content:rw
 environment:
 - url=http://example.com
 logging:
 driver: json-file
 options:
 max-size: 100m

Заметки ¶

Всегда стоит закреплять версию образа, с которого будет запускаться контейнер. Это поможет избежать проблем с перезапуском стека в дальнейшем. Если версия была latest, то при пересоздании стека по каким-то причинам down -> up может стянуться более новая версия, которая будет не совместима с текущими данными\настройками и т. д. Кроме того, невозможно через неделю быстро и легко вспомнить какая же точно версия была запущена на момент старта?
Всегда нужно контролировать процесс логгирования. Если используется стандартный Docker logging driver - json-file, то, по умолчанию, Docker daemon будет принимать логи и писать их в json файл для этого контейнера пока место на диске не закончится. По умолчанию, файл всегда будет один, а вот его место мы можем ограничить установив значение опции max-size: 100m (я взял такое, просто так - больше 100 МБ логов вряд ли кто-либо будет читать). Подробнее о json-file Docker logging driver.
Рекомендую всегда прописывать container_name - удобнее потом читать docker ps.

Обратные SSH тунели

Sun, 20 Oct 2019 00:00:00 +0000

Введение ¶

Если нужно добраться до сервера, который находиться за NAT, то напрямую это сделать нельзя, нужно как-то извращаться. Рассмотрим как можно использовать прямые и обратные SSH туннели для этих целей.

О туннелях ¶

Обратный туннель – создаётся от целевого сервера (ЦС) к промежуточному (ПС). Сокет в этом случае создаётся на ПС.
Прямой туннель – создаётся от начального сервера (НС) к ПС. Сокет в этом случае находиться на НС.

Используя два туннеля мы можем добраться до ЦС. Можно пробросить порт какого-то сайта или просто выбросить порт SSH сервера ЦС, а через него войти в систему. Так же можно пробросить SOCKS5 прокси и выходить в сеть через ЦС. Вариантов достаточно.

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

Создание пользователя на ПС ¶

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


sudo adduser -s /bin/false -M -N tunnel
sudo usermod -d / tunnel
echo 'tunnel:tunnel' | sudo chpasswd
cat <<EOF | sudo tee -a /etc/ssh/sshd_config

Match User tunnel
 PasswordAuthentication yes
 AuthenticationMethods "password"
EOF
sudo systemctl restart sshd

Обратный тунель ¶

Теперь давайте приступим к созданию тунелей. Нам понадобиться обратный от ПС к ЦС. Далее используется sshpass, который нужен для автоматического ввода пароля при подключении по SSH.

Для создания обратного тунеля, его нужно создавать со стороны ЦС. Добавим ПС в список известных на ЦС.

1
2


mkdir -p ~/.ssh
ssh-keyscan -H jump-host >> ~/.ssh/known_hosts

И создадим тунель.

1

sshpass -p 'password' ssh -fNR 2222:localhost:22 tunnel@jump-host

ssh-keyscan -H jump-host - добавляем ключи SSH сервера на ПС в список доверенных на ЦС
sshpass -p ‘password’ – sshpass введёт пароль к новосозданному ранее пользователю на ПС
-fN – выполнить команду и не создавать сессию tty
-R - создание обратного тунеля
2222:localhost:22 – формат такой <адрес в начале тунеля>:<порт в начале тунеля>:<адрес на конце тунеля>:<порт на конце тунеля>. Стало быть, команда делает конкретно следующее: проксирует 127.0.0.1:2222 (адрес начала по умолчанию это localhost) к ПС на 127.0.0.1:22 но уже ПС. Теперь мы можем достучаться до ЦС с ПС. Проверить можно командой ниже

1

ssh -p 2222 localhost hostname

Начало тунеля на ПС, конец на ЦС. Для прямого было бы наоборот. Если обратиться на внешний IP адресс ПС на порт 22, то в тунель мы не попадём, так как трафик должен заходить только с 127.0.0.1, то есть с самого ПС

Прямой тунель ¶

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

1
2
3


mkdir -p ~/.ssh
ssh-keyscan -H jump-host >> ~/.ssh/known_hosts
sshpass -p 'password' ssh -fNL 1234:localhost:2222 tunnel@jump-host

1234:localhost:2222 – проксируем трафик с 127.0.0.1:1234 НС на 127.0.0.1:2222 ПС, а фактически трафик пойдёт сразу по обратноме тунелю к ЦС на порт 22.

SOCKS5 proxy ¶

Мы можем настроить любой браузер, чтобы тот использовал SOCKS5 прокси для направления всего трафика. Это удобно, если нужно обратиться к ресурсам в локальной сети ЦС с НС. Выполним команду ниже на НС (после создания всех тунелей).

1

ssh -fND 1329 -p 1234 user-on-th@localhost

Осталось настроить использование прокси. Может выглядеть так.

OpenSSL снипет

Thu, 25 Apr 2019 00:00:00 +0000

Здесь очень много полезных команд, но полную работоспособность проверять лень 😄

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91


#!/usr/bin/env sh
set -e

# path to private part of CA (PEM encoded)
CA_KEY='ca.key'
# path to public part of CA (PEM encoded)
CA_CRT='ca.crt'
# password to use CA
CA_PASSWORD='longalphanum'

# Country
C='UA'
# State
ST='Kiev'
# Location
L='Kiev'
# Organization
O='No organization'
# Organization unit
OU='No unit'
# Domain to issue final cert for
DOMAIN='vlasov.pro'
# Days while the certificate will be valid
DAYS='365'

subj() {
 echo "/C=${C}/ST=${ST}/L=${L}/O=${O}/OU=${OU}/CN=$1"
}

if [ ! -f "$CA_KEY" ] || [ "$1" = '-ca' ]; then
 echo 'basicConstraints=CA:true' > extfile.txt
 # CA - used for signing of both server and client certs
 # generate private key
 openssl ecparam -genkey -name prime256v1 | openssl ec -out "$CA_KEY"
 # generate signing request
 openssl req -new -key "$CA_KEY" -out ca.csr -subj "$(subj "$O CA")"
 # csr + key = crt
 openssl x509 -req -days 3650 -in ca.csr -signkey "$CA_KEY" -extfile extfile.txt -out "$CA_CRT"
 rm -f ca.csr
 # convert crt to DER format
 openssl x509 -inform PEM -outform DER -in "$CA_CRT" -out "$CA_CRT.der"
 echo 'Generated CA'
fi

# generate and sign certificate
 cat <<EOF >extfile.txt
[ req ]
req_extensions = req_ext
distinguished_name = req_distinguished_name

[req_distinguished_name]

[ req_ext ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = $DOMAIN
DNS.2 = *.$DOMAIN
EOF
 # issue
 openssl ecparam -genkey -name prime256v1 | openssl ec -out "${DOMAIN}.key" # key
 openssl req -new -key "${DOMAIN}.key" -out "${DOMAIN}.csr" -config extfile.txt -subj "$(subj $DOMAIN)" # csr
 openssl x509 -req \
 -days "$DAYS" \
 -in "${DOMAIN}.csr" \
 -CA "$CA_CRT" \
 -out "${DOMAIN}.crt" \
 -CAkey "$CA_KEY" \
 -CAcreateserial \
 -passin "pass:$CA_PASSWORD" \
 -extensions req_ext -extfile extfile.txt # csr + rootCA.crt = crt 
 rm -f "${DOMAIN}.csr"
 # convert DER -> PEM
 openssl x509 -inform PEM -outform DER -in "${DOMAIN}.crt" -out "${DOMAIN}.der.crt" # convert
 # convert PEM -> pkcs12
 openssl pkcs12 -export \
 -inkey "${DOMAIN}.key" \
 -in "${DOMAIN}.crt" \
 -out "${DOMAIN}.pfx" \
 -password "pass:$JKS_PASSWORD" \
 -name "$DOMAIN"
 # create fullchain
 cat "${DOMAIN}.crt" "$CA_CRT" > "${DOMAIN}.full"
 # verify
 openssl verify -CAfile "$CA_CRT" "${DOMAIN}.crt"
 # info
 log_info "Generated $DOMAIN"
done
rm -f extfile.txt

Файл	Содержание
vars.tf	Все переменные
outputs.tf	Выходные параметры
versions.tf	Секция с требованиями к провайдерам
main.tf	Файл с корневым содержимым

DevOps Notes

Хитрое шифрование диска dm-crypt nuke

Введение ¶

Установка ¶

Настройка загрузки ¶

Файле для считывания ключа ¶

Обновление initramfs ¶

Итог ¶

Подписываем Git коммиты

Как настроить подпись коммитов и тегов в Git с помощью GPG и SSH ¶

Основной файл конфигурации Git ¶

Конфигурация для личных проектов ¶

Конфигурация для рабочих проектов ¶

Kubernetes Node role labeler

Описание ¶

Демо ¶

Karpenter конфигурация ¶

BTRFS checksum benchmark

Введение ¶

Тело ¶

Redis Migration Script

Старый способ ¶

Новый способ ¶

Мой опыт с Git

Введение ¶

Основное ¶

В Git есть встроенный графический интерфейс ¶

Как обновлять настройки окружений основываясь на diff-е нового окружения ¶

Как искать пароли и чувствительные данные используя поиск по коммитам ¶

Rebase стратегии ¶

Как сбросить локальную ветку до состояния облачной, если кто-то пушил с форсом ¶

Kubernetes in Docker

Введение ¶

kind ¶

Redis Sentinel Watchdog

Введение ¶

Timeshift BTRFS бекапы на Manjaro

Введение ¶

Требования к системе ¶

Как работает ¶

Удобный и красочный ZSH с p10k

Введение ¶

Настройка p10k ¶

Объяснение моего .zshrc ¶

Установка p10k ¶

Плагины ¶

Добавление путей в PATH ¶

Алиасы ¶

Git config ¶

KUBECONFIG ¶

Автоматическая загрузка утилит ¶

Раздельные окружения ¶

Kubernetes авторизация через OIDC

Введение ¶

Доступ через ServiceAccount ¶

Создание пользователя ¶

Google OIDC ¶

Authentik ¶

wg-quick network namespace

TL;DR ¶

Введение ¶

Постановка задачи ¶

Разбор решения ¶

PreUp ¶

PostUp ¶

Как работает wg-%i-exec ¶

Итог ¶

GPT (UEFI) for Btrfs (/ and /boot) over dm-crypt

Введение ¶

Тип таблицы разделов ¶

Файловые системы ¶

Разделы GPT ¶

Операционные системы ¶

Важные заметки ¶

Не важные заметки ¶

Grub recovery script ¶

Простыми словами о загрузке ОС (EFI) ¶

Вопросы ¶

Обзор k9s

Введение ¶

Обновление `initramfs` ¶