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

apt update
apt install mimedefang -y

Правим файл /etc/default/mimedefang:

SOCKET=/var/spool/postfix/mimedefang/mimedefang.sock
MD_ALLOW_GROUP_ACCESS=yes

Добавляем пользователя postfix в группу defang:

usermod -aG defang postfix

Так как postfix работает в chroot-окружении, создаем папку для сокета mimedefang:

mkdir /var/spool/postfix/mimedefang

Правим /etc/postfix/main.cf:

milter_default_action = accept
milter_protocol = 6
smtpd_milters = unix:mimedefang/mimedefang.sock
non_smtpd_milters = unix:mimedefang/mimedefang.sock

Теперь нужно добавить следующее в конец функции filter в файле /etc/mail/mimedefang-filter:

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

    # Максимальный размер вложения (например, 10MB)
    my $MAX_ATTACHMENT_SIZE = 10 * 1024 * 1024;
    # Директория для сохранения вложений
    my $ATTACHMENTS_DIR = "/var/mail/attachments";
    # URL, по которому будут доступны вложения
    my $ATTACHMENTS_URL = "https://mail.kini24.ru/attachments";

    # Создаем директорию, если её нет
    mkdir $ATTACHMENTS_DIR unless -d $ATTACHMENTS_DIR;

    $size = (stat($entity->bodyhandle->path))[7];
    if ($size > $MAX_ATTACHMENT_SIZE) {
        md_graphdefang_log("The attached file $fname is too big, replaced with a link");
        return action_replace_with_url($entity,
            "$ATTACHMENTS_DIR",
            "$ATTACHMENTS_URL",
            "Размер вложения превысил ограничения сервера, поэтому оно было удалено.\n" .
            "Вы можете скачать его по следующей ссылке:\n\n" .
            "_URL_");
    }

В результате аыполнения функции action_replace_with_url в конец письма будет вставлен текст и ссылка для скачивания вложения, а сам файл бует сохранен в папку /var/mail/attachments. Надо, кстати, покопаться и найти как вставлять ссылку в текст самого письма. Но пока что оставим как есть.

У меня почтовый и веб-сервер находятся на разных виртуальных машинах, поэтому папку /var/mail/attachments надо сделать общей. На почтовом сервере устанавливаем пакет сервера NFS:

apt install nfs-kernel-server -y

Открываем файл /etc/exports и вписываем в конец файла что-то вроде такого:

/var/mail/attachments 192.168.1.0/24(rw,sync,no_subtree_check)

И выполняем в консоли команду:

exportfs -a

Теперь переходим на веб-сервер и выполняем следующие команды:

apt update
apt install nfs-common -y

Открываем файл /etc/fstab и дописываем в конец:

192.168.1.12:/var/mail/attachments /var/www/mail/attachments nfs4 defaults 0 0

где 192.168.1.12 — IP-адрес почтового сервера.
Дальше выполняем команды:

mkdir -p /var/www/mail/attachments
chown -R www-data:www-data /var/www/mail/attachments
mount -a

И проверяем что папка смонтировалась:

ls -l /var/www/mail/attachments

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

В Home Assistant у меня было отслеживание почти всех счетов по квартире: электроэнергия, коммунальные платежи, ТКО, капитальный ремонт и т. д. Проблема была только с сайтом компании СГК, которая занимается предоставлением горячей и холодной воды, отоплением и водоотведением. При помощи таких интеграций, как scrape и multiscrape загрузить данные с их сайта не получалось, поэтому пришлось пойти более сложным путем и написать свой скрипт. На деле он оказался совсем простым, требует доработки в плане проверок ответов сервера, но даже в таком виде он вполне работоспособен. Чтобы не перечислять все данные, возьму только отопление.

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

Далее просто создаем автоматизацию в Home Assistant, которая будет запускать этот скрипт. Для надежности перед первым запуском создаем несколько новых сенсоров в примерно таком формате:

Как видно, в сенсоре будет также атрибут «пеня». Можно вывести суммарную задолженность — долг+пеня, можно вывести только основную — на выбор.
И вот после сайта СГК меня слегка «понесло» и сделал схожие скрипты для получения информации с сайтов ФНС, капремонта, энергосбыта и регистратора доменов. С ФНС было интересно — там сначала нужно пройти basic-авторизацию, получить токен безопасности, авторизоваться еще раз и слать его при каждом запросе данных. А дальше было уже намного легче — у ФНС существует API, которое они активно используют. Официальной документации по нему нет, но, покопавшись на сайте, можно легко получить все запросы. Для чего нужны эти данные? Например, чтобы отслеживать задолженность по налогам (в том числе и самозанятого), недвижимость и банковские счета. Сейчас такое время, что на тебя могут открыть какой-то счет в банке, сделать тебя «начальником» какой-то конторы, а ты даже будешь не в курсе. Но стоит отметить, что в налоговой отображаются только обычные, дебетовые счета, информации по кредитам там нет.

Достаточно давно появилось желание завести свой сервер одноразовых паролей. Искал, не особо торопливо, как обычно. Отчасти потому, что еще немногие серверы поддерживали такой механизм аутентификации. Да и данных, которые нужно защищать было немного. Позже появились сервисы типа госуслуг, в почте стало храниться больше «чувствительных» данных, стало необходимо ограничить доступ к некоторым функциям своего сервера... В общем, причин накопилось достаточно. Про сервер OTP (One Time Password) стал вспоминать всё чаще и вот на днях мне попалась один простой, но в тоже время достаточно функциональный сервер 2FAuth.
Как пишет автор, он создал его потому, что:

Я хотел, чтобы мои учетные записи 2FA хранились в отдельной базе данных и я мог легко создавать и восстанавливать ее резервные копии.
Я ненавижу доставать свой смартфон, чтобы получить OTP, когда пользуюсь настольным компьютером.
Я люблю программировать и люблю самостоятельные решения.

Какие есть «плюсы» данного решения:

• возможность регистрации новых пользователей. Кто-то отнесет ее к «минусам», я не вижу ничего плохого. Можно отключить в настройках.
• Восстановление пароля от своей учетной записи, используемой для входа. Не проверял.
• Возможность импорта и экспорта данных.
• Возможность загрузки QR-кода из файла.
• Возможность ручного ввода данных (сервис, учетная запись, секретный шифр).
• Поддержка TOTP, HOTP, Steam, WebAuthn.
• Загрузка логотипов. Мелочь, а приятно.
• Поддержка SQLite, MariaDB, MySQL, PostgreSQL и SQL Server (внезапно).
• Присутствует REST API (снова сюрприз).
• Есть темная тема.

Пройдемся по «минусам»:

• Отсутствует приложение для мобильных телефонов, только веб-страница.
• Нет поддержки кодов, генерируемых Яндексом. То есть у вас не получится запихать в сервис OTP от Яндекса. Ну тут «на любителя».
• На мой непрофессиональный взгляд слишком много файлов находится в папке.

Теперь немного скриншотов:

Добавление движения общественного транспорта в Home Assistant

Наконец-то у меня получилось. Как обычно, делал всё сильно неспешно при наличии свободного времени и желания. «Воды» не будет, поэтому поехали.
Сейчас не вспомню как, но как-то я вышел на адрес сайта, который отдает данные в формате JSON. Так как меня интересовал в первую очередь конкретный маршрут трамвая, то я получил вот такой вот адрес:

https://mu-kgt.ru/informing/wap/marsh/?m=6%F2%F0&action=getMarshData

Что здесь интересного?

• m=6%F2%F0 — номер маршрута и обозначение типа транспорта. В данном случае часть «%F2%F0» — это всего лишь русские буквы «тр», то есть трамвай. Для троллейбуса это будет просто «т» или «%F2», для автобуса это либо «а», либо вообще без буквы — если честно, не пробовал, да и лень было.
• action=getMarshData — вызывает одноименную функцию в скрипте.
  Переходим в Home Assistant. Здесь я создал новый сенсор в configuration.yaml такого вида:

sensor:
  - platform: rest
    resource: https://mu-kgt.ru/informing/wap/marsh/?m=6%F2%F0&action=getMarshData
    name: Трамвай 6 прибытие
    unique_id: tram6_arrival
    value_template: "{{ value_json.ts_line.A[-1].st_arrive }}"
    scan_interval: 120

Самое важное здесь — value_template, в котором содержится путь до нужной остановки, по которой получаем информацию о времени прибытия. Буквой «А» закодировано направление движения транспорта, которое вы видите в левой части экрана, а буквой «В» — в правой части экрана.

Такие же буквы присутствуют на самом сайте и в приложении.

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

Вид сенсоров в Home Assistant

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

Остановка: Детский кинотеатр «Мечта» (код 336)

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

И еще небольшое дополнение. Значения «0» и «-1», конечно, хороши для выбора конечных остановок при условии, что мы не знаем количество остановок на маршруте, который может измениться, например, из-за ремонта дороги или аварии. Следующий шаблон выбирает остановку с заданным кодом:

value_template: >-
  {% set stops = value_json.ts_line.A %}
  {% for stop in stops %}
    {% if stop.st_regnum == 1989 %} {{ stop.st_arrive }} {% endif %}
  {% endfor %}

Обновлено. Автобусы маркируются без буквы в URL, только номер маршрута.

Попробую сравнить эти две системы «умного дома».
На Domoticz я «просидел» несколько лет. Эта система была хороша тем, что имела низкий порог вхождения, не требовала особых ресурсов и имела достаточно много возможностей. Что я понял спустя некоторое время:

1. Интерфейс достаточно жестко закреплен. Вы не можете создавать свои вкладки (разделы), только заданные разработчиками.
2. Нельзя сгруппировать датчики одного устройства в группу. Один датчик — одна карточка. Которые могут быть разнесены по разным разделам. Например, данные из домашней метеостанции будут присутствовать в трех разделах, между которыми нужно переключаться, чтобы получить всю информацию от нее.
3. Есть темы оформления, но их мало и не все работают корректно. Некоторые предъявляют требования к именам устройств, чтобы была возможность объединить их в одну карточку.
4. Чтобы получить данные с сайта, из операционной системы или что-то еще, выходящее за рамки протокола MQTT — придется использовать python или lua. Тут, кстати, небольшой «плюс» — скрипты хранятся в базе данных. После запуска Domoticz они выгружаются во внешние файлы. Зачем? Ладно, пусть.
5. База данных имеет формат SQLite. Тут свои «плюсы» и «минусы».
6. Группа Domoticz в Telegram, в которой я состоял, «топит» за использование «домика» в связке c Node-Red. Я не любитель установки множества программ на сервер, поэтому от последнего отказался. Что, с одной стороны, сильно меня ограничило в изменении интерфейса системы, с другой... Да ну его нафиг! Там свои ограничения.
7. Несмотря за заявленную несколько лет назад возможность синхронизации данных между несколькими серверами Domoticz, она так и не была реализована. Судя по некоторым данным, разработчики просто «забили» на неё.
8. Мне так и не удалось подключить часть устройств, типа пылесоса Xiaomi, телевизора Samsung, чайника Redmond. И, уверен, в ближайшее время, этого не будет в «домике».
9. Система может просто не запуститься после обновления ОС или если вы допустили ошибку с своем скрипте. Может не понравиться версия glibc, python или его библиотеки. Проверка целостности отсутствует напрочь.
10. «Умные» колонки вы не подключите.

Скорее всего, было что-то еще, что меня не устраивало в этой системе, но я перечислил основное. К тому же на меня порой «находит» и я начинаю экспериментировать. Поэтому качаем образ Home Assistant для KVM и начинаем пробовать что он может.

1. У меня много «простых» устройств, работающих по протоколу MQTT. Их пришлось прописать ручками. Копипаста с небольшими правками сильно помогла. Это был начальный этап, я еще ничего не знал. НА может обнаруживать такие устройства сама.
2. Пылесос, телевизор, чайник «влетели» как родные, после установки нужных дополнений.
3. Базу данных в формате MySQL пришлось подключать ручками. Основной формат опять же был SQLite, но для большой истории показаний он не годится. Перенес данные из Domoticz в Home Assistant (есть скрипт в интернете).
4. Сделал нужные мне разделы (вкладки) в интерфейсе, занес в них нужные устройства с нужными параметрами. Разница с Domoticz просто огромная.
5. Оповещения в Jabber, Telegram, на почту подключаются достаточно просто.
6. Нашел несколько групп в Telegram по этой системе. Общение между участниками идет постоянно, поэтому пришлось отключить уведомления.
7. Парсинг данных с сайтов вообще порадовал — достаточно указать URL, с которого будешь забирать данные и тэг, который нужно искать. Ну и номер тэга иногда.
8. Есть проверка ошибок конфигурации перед перезапуском. Если найдет — выдаст предупреждение. Это вообще кайф :-)
9. По ресурсам, конечно, более требовательна, но оно того стоит.
10. Хотите подключить колонку яндекса или марусю — не вопрос!

Наверное, на этом закончу. Продолжу тему в другой заметке — там уже много чего описать.

Случай, когда ваш домен располагается на reg.ru

Можно, конечно, воспользоваться сторонними библиотеками, но я не любитель ставить что-то стороннее, если можно обойтись своими силами. Поэтому пришлось потратить время на написание и тестирование bash-скрипта с именем authenticator.sh:

#!/bin/bash

#Основные параметры
domain="kini24.ru"
username="graywolf"
password="********"
# Этот параметр менять не нужно
subdomain=""

# Корректно задаем судбдомен
# Если обрабатывается основной домен, то субдомен будет _acme-challenge
# Если обрабатывается субдомен, то строка будет вида _acme-challenge.subdomain
if [[ $CERTBOT_DOMAIN = $domain ]]
then
  subdomain="_acme-challenge"
else
  subdomain="_acme-challenge.${CERTBOT_DOMAIN%.$domain}"
fi

# Чисто для информации
/usr/bin/echo "Requesting $CERTBOT_DOMAIN"

# Запрос на удаления текущих записей
txt_delete="input_format=json&input_data={\"username\":\"$username\",\"password\":\"$password\",\"domains\":[{\"dname\":\"$domain\"}],\"subdomain\":\"$subdomain\",\"record_type\":\"TXT\",\"output_content_type\":\"plain\"}"

# Запрос на добавления записи
txt_add="input_format=json&input_data={\"username\":\"$username\",\"password\":\"$password\",\"domains\":[{\"dname\":\"$domain\"}],\"subdomain\":\"$subdomain\",\"text\":\"$CERTBOT_VALIDATION\",\"output_content_type\":\"plain\"}"

#Можно проверить при желении
#/usr/bin/echo "Certbot parameters:"
#/usr/bin/echo "Current domain: $CERTBOT_DOMAIN"
/usr/bin/echo "Validation string: $CERTBOT_VALIDATION"
#/usr/bin/echo "Delete request: $txt_delete"
#/usr/bin/echo "Add request: $txt_add"

# Запрос на удаление ВСЕХ TXT записей
if [[ $CERTBOT_DOMAIN != $domain ]]
then
 #/usr/bin/echo "Remove all TXT records"
  /usr/bin/curl --silent --data "$txt_delete" "https://api.reg.ru/api/regru2/zone/remove_record"
fi

# Запрос на создание TXT записи
#/usr/bin/echo "Add new TXT record"
/usr/bin/curl --silent --data "$txt_add" "https://api.reg.ru/api/regru2/zone/add_txt"

# Проверяем что нужная TXT запись появилась. Иначе ждем пока данные обновятся
#answer=""
#while [[ $answer != $CERTBOT_VALIDATION ]]
#do
#  /usr/bin/echo "Requesting DNS record"
#  answer=$(/usr/bin/dig @77.88.8.8 $CERTBOT_DOMAIN txt +short | /usr/bin/tr -d \" | /usr/bin/egrep $CERTBOT_VALIDATION)
#  /usr/bin/sleep 60
#done

if [[ $CERTBOT_REMAINING_CHALLENGES -eq 0 ]]
then
  sleep 15m
fi

# Выводим количество доменов, которые осталось обработать
/usr/bin/echo "Remaining challenges: $CERTBOT_REMAINING_CHALLENGES"

Логика скрипта следующая. В начале задаются основной домен, имя пользователя и пароль от личного кабинета reg.ru. Параметр subdomain менять не нужно, он «вычисляется» по ходу выполнения скрипта. Далее если обрабатывается основной домен, то поддомен становится равным _acme-challenge, иначе в конец еще добавляется поддомен. Формируется строка для удаления всех (!) текущих записей типа TXT, если обрабатыается поддомен. Записи для основного домена просто добавляются (тут да, небольшой косяк, нужно немного дописать скрипт).
Затем, после добавления DNS-записи скрипт должен был запрашивать все записи TXT и, после появлении нужной, продолжать выполнение, но тут скрипт уходил в бесконечный цикл, поэтому я его закомментировал полностью. Сможете исправить — буду благодарен.
На последнем шаге скрипт, если доменов для регистрации не осталось, ждет 15 минут (время обновления записей у reg.ru от 15 минут до 1 часа) и возвращает управление команде certbot.

Вызывается скрипт примерной такой командой:

certbot certonly --manual --agree-tos --manual-public-ip-logging-ok --email admin@kini24.ru --preferred-challenges dns --server https://acme-v02.api.letsencrypt.org/directory --domain *.jabber.kini24.ru --domain *.meet.kini24.ru --domain *.kini24.ru --domain kini24.ru --rsa-key-size 2048 --key-type ecdsa --elliptic-curve secp256r1 --redirect --uir --staple-ocsp --must-staple --hsts --manual-auth-hook /root/authenticator.sh

В этой команде следующие параметры:
certonly — только получение сертификата;
agree-tos — принимаем пользовательское соглашение;
manual-public-ip-logging-ok — соглашаемся на публикацию нашего IP-адреса;
email — указываем свою электронную почту для уведомлений;
preferred-challenges — выбираем тип проверки. Для wildcard-сертификатов это только DNS;
server — указываем сервер сертификации;
domain — перечисляем свои (суб-)домены;
rsa-key-size — указываем «размер» ключа. Значение 2048 по умолчанию, оставил на всякий случай;
key-type — тип ключа. Снова указано значение по умолчанию;
elliptic-curve — «кривые». Тут тоже значение по умолчанию;
redirect — перенаправлять с http на https$
uir — добавляет в ответ заголовок Content-Security-Policy со значением upgrade-insecure-requests;
staple-ocsp — «сшивание» сертификатов;
must-staple — обязательное «сшивание»;
hsts — принудительная активация защищенного режима, т. е. https;
manual-auth-hook — запуск своего скрипта.

Побывало у меня 2 «умных» чайника: Redmond RK-G211S и Fiesta DK-1G. Первый отработал около 3 лет, вторым пользуюсь и сейчас. И, внезапно, захотелось их сравнить, выделить «плюсы» и «минусы». Поехали.

Redmond RK-G211S
Вот наш первый герой (здесь и далее фото взяты из интернета):

Начну с «плюсов».

1. Мощный. Быстро кипятит воду.
2. Тихий. У меня маленький ребенок,поэтому любой шум будет излишним.
3. Удобное управление кнопками на ручке чайника и через приложение.
4. Поддержание заданной температуры.
5. Возможность задать время суток, когда чайник должен подогреть или вскипятить воду.
6. Можно использовать в качестве ночника в темное время суток.
7. Градуировка нанесена на внешнюю часть и хорошо видна.
8. Можно посмотреть общее потребление электроэнергии чайником.
9. Температура воды подсвечивается соответствующим цветом: красный, желтый, зеленый, синий.

К сожалению, «минусы» тоже присутствуют и для меня они оказались существенными.

1. Форма носика. За всё время использования я так и не привык тонкой струйкой наливать воды из него. Ну действительно, дизайнеры, поменяйте форму на более привычную. И данная просьба относится не только к этой модели. Очень раздражал этот момент.
2. Удаленное управление через bluetooth. Через две стены смартфон до чайника не «достает». Если хотите нормально управлять чайником — купите специальный шлюз по такой же цене (или уже дороже?), либо используйте смартфон (планшет) с установленным приложением-шлюзом. Сама компания-производитель говорит, что выбор в пользу bluetooth сделан для увеличения безопасности пользователя. В связи с нежеланием покупать что-то еще для управления чайником не получилось ввести его в систему «умного» дома.
3. Датчик температуры воды. Видели торчащую «пипку» из дна чайника? Это датчик температуры. Опять же, какой разум сделал его стеклянным и придумал так его расположить. К чему это ведет? Иногда нужно два-три раза подряд вскипятить воду. Иными словами, вскипятил один раз, слил воду, налил новую и еще раз включил чайник. Если вы нальете холодную воду сразу после кипячения, то велика вероятность того, что стеклянная крышка, закрывающая датчик, просто лопнет от перепада температур. Слышали когда-нибудь как трескается стекло при перепаде? Я слышал. Хорошо, что на работе это не сказалось. По крайней мере, я не заметил.
4. «Забывчивость». Как только вы снимете чайник с подставки он сразу забудет всё, чему вы его «учили». Придется выставлять все параметры заново. Для этого нужно, как минимум, чтобы смартфон с управляющим приложением были в зоне досягаемости чайника.
   В интернете можно найти способ добавления аккумулятора в чайник для предотвращения таких ситуаций, но... Мой опыт показал несостоятельность такого метода. Аккумулятора хватило примерно на полгода, после чего он просто вышел из строя.
5. Кнопки на ручке закрыты тонкой пленкой, которая быстро достаточно быстро стирается до дыр. Без комментариев.
6. Пластиковый корпус, можно обжечь руки.

Через 3 года использования чайник сломался — сгорел ТЭН. На замену ему пришел новый.

Fiesta DK-1G
Второй наш герой обзора:

«Плюсы»:

1. Удаленное управление через WiFi. Более удобно, быстро и, как мне кажется, надежно. В пределах дома нет ограничений на расстояние между смартфоном и чайником. Да и вообще нет ограничений, можно управлять из любой точки мира, где есть интернет.
2. В отличие от своего «соперника» этот чайник ничего не «забывает» после снятия с подставки. Или сразу подгружает данные из интернета — пока не уверен. В любом случае занимает это пару-тройку секунд, не больше — ровно столько длится подключение к домашней сети WiFi.
3. Корпус с двойными стенками. Сразу после кипячения корпус снаружи едва теплый.
4. Поддержание заданной температуры.
5. Возможность задать время суток, когда чайник должен подогреть или вскипятить воду.
6. Носик стандартной формы. Кружку можно налить за несколько секунд против примерно 30 секунд у Редмонда.

«Минусы»:

1. Градуировка нанесена на внутреннюю часть да еще и со стороны ручки. Наливать воду и одновременно контролировать ее уровень у вас не получится. Почти. Нижнее отверстие в корпусе перед носиком почти соответствует максимальному уровню воды, так что можно ориентироваться на него.
2. Более шумный, чем Редмонд. Хотя, казалось бы, должно быть наоборот.
3. Через некоторое время (не засекал, но навскидку примерно через час-полтора) гаснет экран, отображающий состояние чайника и температуру воды. Приходится снимать с подставки и возвращать его обратно.
4. При установке на подставку издает короткий писк. Зачем? Также при включении кипячения пищит два раза: первый — включение, второй раз — начало кипячения. Тоже не понимаю этот момент, ну да ладно.
5. Чтобы ввести его в систему «умного» дома пришлось проделать множество нестандартных действий. И речь сейчас не об Алисе от яндекса, а о таких системах как Home Assistant или Domoticz. С Алисой проблем вообще не возникло, подключил за пару минут.

И пара «спорных» для меня моментов.

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

В общем и целом, Fiesta DK-1G мне пока нравится больше, чем изделие от Редмонда. Я, наверное, даже рад, что моим первым опытом с такой техникой стал именно RK-G211S — он позволил мне точно определить чего я жду от «умного» чайника и с чем я точно не хочу сталкиваться каждый день.

Я несколько лет бился с запуском этой программы под разными версиями линукса: Alt Linux, Ubuntu, другие. И всё время натыкался на одну и ту же ошибку: «На найдена точка входа UserLogonExA в библиотеке ADVAPI32.DLL». Перепробовал множество способов, описанных в интернете. Ничего не помогало. Сравнительно недавно наткнулся на один, но из-за текущих дел опробовать не успел. А тут случилось неудачное обновление, база некорректно обновилась, пришлось откатываться и заодно решил попробовать — чем черт не шутит. Итак, алгоритм такой (предполагается, что wine уже установлен):

1. Монтируем сетевую папку на свой компьютер. Например, в /mnt/cons.
2. Запускаем winecfg, добавляем новый диск (пусть D:) и указываем смонтированную папку /mnt/cons.
3. Из консоли запустить файл cons.exe с параметрами пока не получилось, поэтому запускаем winefile и уже из него cons.exe.
4. При запуске соглашаемся с путями, которые нам предложила система (или изменяем на свои).
5. На рабочем столе появляется ярлык на cons.exe, но запустить система его не дает — выдает ошибку «Разрешите запуск». Галочка «Запускать как программу» установлена, но этого мало. Идем дальше.
6. Устанавливаем еще один пакет:

sudo apt install dbus-x11

7. Запускаем:

dbus-launch gio set '/home/kopytov/Рабочий стол/ConsultantPlus.desktop' "metadata::trusted" true

8. Обновляем рабочий стол и спокойно работаем с Консультантом.

Если нужен запуск системы с ключами, то добавляем их в desktop-файл.

«Генератор идей» в голове порой не дает нормально поспать. Вот зачем мне в голову уже за полночь пришла мысль попробовать подключить все устройства, которые есть в доме, к Алисе? Хорошо, что процесс не занял много времени и я успел более-менее нормально выспаться.
Первой «жертвой» стал телевизор Samsung. Первая попытка подключения была неуспешной — телевизор не был зарегистрирован в личном кабинете производителя. Пришлось установить программу SmartThings на телефон, войти в личный кабинет, добавить туда телевизор и уже после этого можно было добавить его в Алису. Немного побаловался голосовым управлением и пошел спать.
Утром сделал еще несколько попыток голосового управления и понял, что есть вещи, с которыми нужно будет разобраться:

1. Нельзя включить ТВ через Алису. Скорее всего, и не получится. В принципе, пока не критично. Но мысли как это обойти уже есть.
2. Нельзя переключать каналы, сказав, например: «Включи канал СТС на телевизоре». Но можно переключить канал, сказав его номер. Кто помнит какой телеканал под каким номером сохранен в вашем телевизоре? Вот и я не помню.
3. Нельзя переключить источник сигнала с HDMI на антенну, сказав пресловутую фразу «Включи канал СТС на телевизоре».
4. Запускать Алису на телефоне, чтобы управлять телевизором голосом — долго. Быстрее использовать кнопки в SmartThings или другом стороннем приложении.

Вторым устройством стал чайник Redmond. Им более-менее удобно было управлять с телефона через фирменное приложение. Из «минусов», которые меня раздражали, основным неудобством было то, что чайник подключался через bluetooth. Попробовал было подключить его через донгл к домашнему серверу, но «что-то пошло не так» и я забил.
Подключить чайник пока что не получилось. Возможно, сказалось то, что он был вне зоны действия bluetooth моего телефона. Возможно, для полноценного управления чайником нужен шлюз. Пока что непонятно, поэтому... Будем устанавливать android в виртуальную машину и пытаться настраивать его в качестве этого самого шлюза. Это пока что в процессе.
Следующим шагом стало подключение робота-пылесоса Xiaomi. Схема была такой же, как и с предыдущими двумя устройствами: авторизуемся в личном кабинете производителя, проверяем, что устройство там есть, заходим в приложение «Умный дом» от Яндекса и добавляем в него пылесос. Тут возник нюанс: пылесосов у меня добавлено два — один в моем доме, второй — у мамы. И приложение, ничуть не сомневаясь в своей правоте, успешно добавило оба в мой дом. Пришлось создавать второй дом и переносить туда мамин пылесос, чтобы случайно не запустить его убираться.