Disclaimer

Настройки сети, пробросы портов и т.д. оставлю за кадром.

Nginx to the rescue

Для проброса TCP-соединений буду использовать модуль stream. В этом случае мне не придётся настраивать терминацию SSL на Nginx.

Установка модуля stream

sudo apt-get install libnginx-mod-stream

Подразумевается, что сам Nginx уже установлен и кеш пакетов apt свежий.

Настройка модуля stream

Добавляю в /etc/nginx/nginx.conf секцию stream для трафика с TLS:

stream {
    map_hash_bucket_size 64;

    map $ssl_preread_server_name $targetBackend {
        hostnames;

        *.domain1.tld   k8s1;
        domain1.tld     k8s1;

        *.domain2.tld   k8s2;
        domain2.tld     k8s2;

        default         local;
    }

    upstream k8s1 {
        server 10.0.0.2:443;
    }

    upstream k8s2 {
        server 10.0.0.3:443;
    }

    upstream local {
        server 127.0.0.1:8443;
    }

    server {
        listen      0.0.0.0:443;

        ssl_preread on;

        proxy_pass  $targetBackend;
    }
}

Где upstream k8s1 - адрес ингресса первого кубера, upstream k8s2 - адрес ингресса второго кубера, upstream local - локальный сервер nginx.

Для того, чтобы корректно перенаправить SSL-трафик на разные upstream, использую параметр ssl_preread on, позволяющий получить FQDN из SNI и записать его в переменную $ssl_preread_server_name. Далее, на основе заданного маппинга сопоставляем $ssl_preread_server_name с соответствующим $targetBackend.

Локальный nginx придётся перенастроить чтобы он слушал обращения к сайтам с TLS на https://127.0.0.1:8443.

Перезапускаю nginx после изменения конфигурации для применения новых настроек.

systemctl restart nginx

Дополнительная настройка nginx для корректной работы Cert Manager

Cert Manager уже задеплоен в кубере и настроен для автоматизации получения SSL-сертификатов от Let’s Encrypt. Создаём для Nginx по конфигу сайта под каждый кубер, чтобы туда мог подключиться проверяющий адреса бот. Приведена минимальная конфигурация, дополняйте по обстоятельствам.

/etc/nginx/sites-enabled/k8s1:

# HTTP
server {
    listen      80;

    server_name *.domain1.tld domain1.tld;

    location    / {
        allow               all;

        proxy_pass          http://10.0.0.2:80;
        proxy_pass_header   Set-Cookie;

        proxy_set_header    X-Real-IP           $remote_addr;
        proxy_set_header    X-Forwarded-Proto   $scheme;
        proxy_set_header    X-Forwarded-For     $remote_addr;
        proxy_set_header    Host                $host;
    }
}

/etc/nginx/sites-enabled/k8s2:

# HTTP
server {
    listen      80;

    server_name *.domain2.tld domain2.tld;

    location    / {
        allow               all;

        proxy_pass          http://10.0.0.3:80;
        proxy_pass_header   Set-Cookie;

        proxy_set_header    X-Real-IP           $remote_addr;
        proxy_set_header    X-Forwarded-Proto   $scheme;
        proxy_set_header    X-Forwarded-For     $remote_addr;
        proxy_set_header    Host                $host;
    }
}

Бонусы

Перенаправление http на https

/etc/nginx/sites-enabled/http2https:

server {
    listen  80  default_server;

    return  301 https://$host$request_uri;
}

Сайт-заглушка

/etc/nginx/sites-enabled/landing:

server {
    listen      127.0.0.1:8443 ssl http2 default_server;

    root        /srv/landing;

    index       index.html;

    location    / {
        try_files $uri $uri/ /index.html;
    }
}

Появилась мысль закинуть в подрозетник к выключателю какое-нибудь реле с удалённым управлением, а пульт от него положить на тумбочку у кровати. От этой мысли я отказался почти сразу, потому что в тот момент уже искал куда закинул пульт от телевизора. Как начальный вариант — прикинул купить ночник с таймером и воткнуть его в одну из розеток в коридоре, но все попадавшиеся мне подобные ночники были либо уродливыми, либо неудобными. В итоге, первой моей домашней автоматизацией оказался электронный таймер для выключения на ночь вентилятора, обдувающего мою домашнюю «серверную». Второй такой же таймер, купленный через полгода, включал вечером гирлянду, повешенную в комнате за занавесками. Но проблему с выключателями это не решало. На тот момент я уже обладал начальной информацией про умный дом от Xiaomi и решился на покупку шлюза, нескольких розеток и датчиков. Ну и заказал из Китая для этой системы управляемые выключатели. Как я монтировал эти выключатели в квадратные китайские подрозетники (которые продавец положил в комплект, кстати) — отдельная история.

В общем, схема следующая:

Розовая «шестерёнка» — выключатель на две клавиши в прихожей у двери, управляет светом в прихожей (вторая клавиша оставлена под автоматизацию). Красная «шестерёнка» — выключатель на три клавиши на стене справа от входа в санузел, управляет светом в ванной, вытяжкой в ванной и светом в коридоре Розовая «звёздочка» — беспроводной выключатель на две клавиши на стене между входами в кухню и комнату, дублирует управление светом в прихожей и светом в коридоре. Зелёная «звёздочка» — беспроводной выключатель на стене в ванной, дублирует управление светом в ванной и вытяжкой в ванной.

Автоматизации в Mi Home выглядят следующим образом:

Второй выключатель по аналогии.

P.S.: а нормальные люди в обед обедают…

Ссылки на репозитории (код закрыт, ссылки для соавторов): Мой Gitlab, зеркало на Bitbucket

What you need to do instead is to reconfigure AccountsService.

To hide a user named XXX, create a file named

/var/lib/AccountsService/users/XXX

containing two lines:

[User]
SystemAccount=true

If the file already exists, make sure you append the SystemAccount=true line to the [User] section.

Via https://askubuntu.com/a/575390

Via https://community.acer.com/en/discussion/comment/845387/#Comment_845387

Прежде всего, смотрим диагностику:

cat /proc/mdstat

или

mdadm --detail /dev/md0

Если вместо [UU] видим [U_], то дело плохо, целостность одного из дисков нарушена — нужно менять диск.

Помечаем раздел как сбойный:

mdadm --manage /dev/md0 --fail /dev/sdb1

Отключаем раздел (удаляем из RAID1):

mdadm --manage /dev/md0 --remove /dev/sdb1

Выключаем машину, меняем диск.

Создаем через cfdisk или fdisk идентичные разделы, или c помощью sfdisk автоматически копируем структуру разделов первого диска /dev/sda:

sfdisk -d /dev/sda | sfdisk /dev/sdb

Этим способом можно пользоваться, поскольку в нашем примере «зеркальный» RAID1. При других уровнях (raid level), нужно разбить диск на раздел(ы) и пометить его(их) типом ФС «Linux raid autodetect».

Добавляем раздел в RAID1 массив:

mdadm --manage /dev/md0 --add /dev/sdb1

Ждем синхронизации массива:

watch cat /proc/mdstat

Ссылки:

http://avreg.net/howto_software-raid-replacing-faulty-drive.html

http://xgu.ru/wiki/mdadm

Преамбула

Есть такая интересная штука, как RabbitMQ. Написана на Erlang (это важно). В Docker запускается с пол-пинка, в кластер собирается тремя с половиной командами. Это если всё делать вручную по инструкции. Сразу скажу, корректные FQDN серверов и контейнеров — обязательное условие работоспособности.

Запускаем на первом сервере первую ноду будущего кластера:

docker run -dit -h docker-rabbitmq-01.domain.tld               \
           --name rabbit                                       \
           -p "4369:4369"                                      \
           -p "5671:5671"                                      \
           -p "15671:15671"                                    \
           -p "25672:25672"                                    \
           -p "35197:35197"                                    \
           -e "RABBITMQ_ERLANG_COOKIE=S0meL3ttersAndNumber5"   \
           -v rabbitmq_data:/var/lib/rabbitmq                  \
           -v /opt/ssl:/opt/ssl:ro                             \
           --restart unless-stopped                            \
           zimniy/rabbitmq:latest

Сразу определяем политику HA (запускаем также на первом сервере):

docker exec rabbit rabbitmqctl set_policy ha-all ".*" '{"ha-mode":"all", "ha-sync-mode": "automatic"}'

Запускаем на втором сервере вторую ноду будущего кластера:

docker run -dit -h docker-rabbitmq-02.domain.tld               \
           --name rabbit                                       \
           -p "4369:4369"                                      \
           -p "5671:5671"                                      \
           -p "15671:15671"                                    \
           -p "25672:25672"                                    \
           -p "35197:35197"                                    \
           -e "RABBITMQ_ERLANG_COOKIE=S0meL3ttersAndNumber5"   \
           -v rabbitmq_data:/var/lib/rabbitmq                  \
           -v /opt/ssl:/opt/ssl:ro                             \
           --restart unless-stopped                            \
           zimniy/rabbitmq:latest

Со второго сервера подключаем вторую ноду к первой:

docker exec rabbit rabbitmqctl stop_app
docker exec rabbit rabbitmqctl join_cluster rabbit@docker-rabbitmq-01.domain.tld
docker exec rabbit rabbitmqctl start_app

Всё, кластер собран и уже работает. Можно подключаться с учёткой guest:guest.

Фабула

Короче, теперь про то, какая гадость этот docker-compose…

Оказывается, у него есть два параметра: hostname и domainname.

И если задать только hostname как FQDN «docker-rabbitmq-01.domain.tld», то оно в контейнере обрезается до «docker-rabbitmq-01». Так что нужно обязательно задать ещё и domainname «domain.tld» иначе Erlang, на котором написан RabbitMQ, свой FQDN не определит и будет игнорировать попытки подключения.

В общем, используя docker-compose, нужно делать так:

docker-rabbitmq:
  image: zimniy/rabbitmq:latest
  container_name: rabbit
  hostname: docker-rabbitmq-01.domain.tld 
  domainname: domain.tld
  restart: unless-stopped
  ports:
    - "4369:4369"
    - "5671:5671"
    - "15671:15671"
    - "25672:25672"
    - "35197:35197"
  volumes:
    - "/opt/ssl:/opt/ssl:ro"
    - "rabbitmq_data:/var/lib/rabbitmq"

Внимание, hostname задать именно как FQDN.

И, для того, чтобы это выяснить, пришлось аж в исходники лезть…

Хук апта:
root@brain:~# cat /etc/apt/apt.conf.d/99upgradehook

DPkg::Post-Invoke {"/usr/local/sbin/pve-no-subscription-patcher";};

Исполнимый скрипт:
root@brain:~# cat /usr/local/sbin/pve-no-subscription-patcher

#!/bin/bash

SFILE=/usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js

cat "${SFILE}" | grep -qi "data.status !== 'Active'" || exit 0

logger -t pve-no-subscription-patcher -s "Patching Proxmox widget toolkit"
cp -f "${SFILE}" "/root/$(basename ${SFILE}).bak"
sed -i "${SFILE}" -e "s/data.status\ !==\ 'Active'/false/"

Фабула: Решил починить неработающую синхронизацию времени в домашнем домене (да, у меня дома домен). Выяснилось, что apparmor не даёт взаимодействовать ntp-серверу с samba-сервером. Быстрое раскуривание логов и гугление показало, как надо объяснить apparmor’у его неправоту — вставляем в /etc/apparmor.d/local/usr.sbin.ntpd следующие строки:

#include <abstractions/dbus-strict>

# samba4 ntp signing socket
/var/lib/samba/ntp_signd/socket rw,

# samba4 winbindd pipe
/run/samba/winbindd/pipe rw,

Перезапускаем сервис apparmor: service apparmor restart. Если ругнулось на синтаксис и упало — значит, где-то закрались лишние пробелы или строки, убираем их. Да, между значком «#» и словом «include» пробела НЕТ, а до этой строки не должно быть пустых строк, разве что с комментариями.

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

Вишенка на торте: если использовать встроенный в Samba DNS-сервер, то нужно откуда-то узнать, что в Ubuntu без установленного пакета dnsutils не будет работать динамическое обновление адресов…