Дмитрий

По поводу этого лучше всего начать с LARTC HOWTO.

Если кратко, маршрутищация в iproute2 устроена так. Есть несколько таблиц маршрутизации, из которых 3 есть всегда (local, main, default), но можно создать ещё. По правилам (команда ip rule) перебираются таблицы, подходящие под условия, в соответствии с приоритетами (preference, первое число в выводе команды). И в каждой таблице есть свои маршруты. Таблицу local изменять нельзя и перед ней ничего маршрутизировать нельзя (это можно обойти через nat в PREROUTING, но это уже другой вопрос).

Самый простой вариант - это source routing. Впервые мне это понадобилось, когда я подключил дома второго провайдера с внешним IP, и мне потребовалось отвечать с обоих внешних адресов со всего интернета. Делается так:

1. В /etc/iproute/rt_tables описываем псевдонимы для новых таблиц (необязательно - можно использовать числовые идентификаторы - но так удобнее). Например, 10 - isp1, 20 - isp2.

2. Задаём правила, которые приведут к выбору таблицы в зависимости от source address:

ip rule add pref 10 from IP1 lookup isp1
ip rule add pref 20 from IP2 lookup isp2

3. В каждую таблицу добавим маршрут default через нужного оператора:

ip route add default via GATEWAY1 table isp1
ip route add default via GATEWAY2 table isp2

4. В таблице main (которая используется по умолчанию, если не указать таблицу в команде явно) описываем маршрут "по умолчанию" - через того оператора, через которого будет идти исходящий трафик (не ответный на входящий), в данном случае пусть будет isp1:

ip route add default via GATEWAY1

Всё это иногда можно в той или иной степени засунуть в конфиги сети (зависит от дистрибутива Linux весьма существенно), а иногда приходится делать скриптами, в том числе, возможно, вызываемыми через hook системы инициализации сети (я, например, обновлял маршрутизацию через postup-хук dhcp-клиента и из скрипта, который поднимал pptp-vpn).

В дальнейшем всё это обросло кучей других особенностей, например, ip rule fwmark по меткам, которые ставилилсиь в iptables по connmark и иногда другим условиям, но это уже следующий уровень сложности и более специфичне задачи. И LARTC HOWTO почитать всё равно рекомендую, ибо там основа основ и все гуру по нему учились.

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

Потому что оба оверлоада неразличимы - они ОБА показывают один аргумент типа bool.
И да, а если аргумент не указан, что вернёт функция? Из твоего кода это неясно вообще, так как у тебя два противоречащих варианта.
Тебе надо что-то типа...

@overload
@classmethod
def get_mac_address(cls, with_gateway: typing.Literal[False] = False) -> str:
    ...
@overload
@classmethod
def get_mac_address(cls, with_gateway: typing.Literal[True]) -> tuple[str, str]:
    ...
@classmethod
def get_mac_address(cls, with_gateway: bool = False) -> typing.Union[str, tuple[str, str]]:
    ...

Запустите mailq и посмотрите, что за письма и от кого у вас в очереди. Далее смотрите заголовки в самих файлах писем, в них будет IP-адрес источника.

Если источник 127.0.0.1, то могу предположить, что у вас на этом сервере установлен некий прокси (HTTP/SOCKS), разрешающий доступ в локальную сеть, и письма отправляют через прокси, а postfix считает их локальными и не требует аутентификации — это довольно типичная мисконфигурация.

Если прокси нет, быть может, у вас включена маршрутизация общая, маршрутизация в localhost (net.ipv4.conf.*.route_localnet), в таком случае соседи по датацентру также могут маршрутизировать вам трафик в 127.0.0.1 (это нетипичная и редкая конфигурация, но иногда такое может встречаться [1], [2]).

Стандартный ввод - это файл, и его технически можно "прочитать до конца". Пример:

import sys
for line in sys.stdin:
    print('Got', repr(line))
print('Done')

Запусти как обычно, введи несколько строк, а потом в терминале (если под виндой) нажми Ctrl-Z, затем Enter.
Это пошлёт сигнал "конец файла", и дальнейшие попытки ввода через input() будут не успешными.

Также можешь записать строки в текстовик, и запустить файл с перенаправлением ввода:
python3 main.py < data.txt
Тогда скрипт тоже получит сигнал о конце ввода, когда файл закончится.

Поле depends_on определяет только последовательность запуска и удаления сервисов, к остановке отношения не имеет.
Искомое вами поведение задаётся через healthcheck проверки доступности базы в backend и бэкенда во frontend... или простой docker compose -f путь/до/docker-compose.yaml stop, т.е. просто остановить все сервисы.

пакет struct метод unpack

data=b'\xc8'
struct.unpack('b', data)[0]

data типа bytes, можно считывать из файла, открывая как бинарный файл, флаги 'rb'

RTFM - MongoDB Manual / Installation / Community Edition / Install on Windows: https://www.mongodb.com/docs/manual/tutorial/insta...

Ты задал уровень WARNING для самого логгера (не для хэндлеров), поэтому он INFO отбрасывает сходу. До хэндлеров ничего не доходит просто.
Я бы использовал эту либу немного по-другому (пример с её гитхаба)

t_handler = tg_logger.TgLoggerHandler(users=[...], token=TELEGRAM_TOKEN)
t_handler.setLevel(logging.WARNING)
logger.addHandler(t_handler)

Так куда более похоже на обычные лог-хэндлеры, проще управлять и читать даже если с либой мало знаком.
Ну или если очень хочется setup(), то так:

t_handler = tg_logger.setup(logger, token=token, users=users, tg_format="<b><u>%(name)s</u> : %(levelname)s</b>\n\n<code>%(message)s</code>")
t_handler.setLevel(logging.WARNING)

Так что логгеру задай уровень подетальнее, INFO или даже DEBUG, а тонкую настройку делай на уровне хэндлеров.