mureevms

Ваша проблема в том, то Вы абсолютно не понимаете как работает WSL. Давайте немного объясню.

Начиная с WSL2 подсистема Linux крутится в полноценной виртуальной машине. И винда кстати тоже. Это работает следующим образом: когда Вы запускаете свой компьютер первой загружается на самом деле не винда, а гипервизор HyperV. Для пользователя происходит все прозрачно, так как HyperV настроен сразу запускать 2 виртуальные машины - с виндой и с линем. В машину с виндой HyperV сразу прокидывает все Ваши устройства (видеокарту, USB и прочее). Так же HyperV поднимает виртуальную сеть между этими двумя виртуалками. В машине с линем еще не Ваша Ubuntu, там легковесная ОС состоящая только из ядра и оркестратора LXC контейнерами (с ней кстати можно по взаимодействовать по сети, как это делает Docker Desktop например, ну или утилита wsl.exe). Ваша Ubuntu запускается в контейнере, так попросту быстрее ее запускать и останавливать, ибо ядро всегда висит в памяти. Опционально в линь монтируются папки (диски) из винды, делается это посредством патча ядра Linux от Microsoft. Обратный доступ предоставляется из винды посредством сетевого ресурса wsl$.
Главное что тут стоит понять - винда и линь в WSL по сути работают на разных компах, пусть и виртуальных.

Теперь ответьте на вопрос, на каком из этих компов работает Ваш VSCode?
Правильный ответ на винде. А значит и взаимодействовать он будет с виндой. И искать ключи для подключения к ssh будет в домашней папке юзера в винде.

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

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

Реммина это лишь клиент позволяющий подключаться по разным протоколам у удаленному ПК. Например для подключения по RDP достаточно просто разрешить подобное подключение на удаленном ПК. ПОрты на маршрутизаторе в этом случае скорее всего пробрасывать не придеться (ну если только он не настроет на запрет всего что не разрешено явно)

В защиту уходит. Отсоединить БП, проверить на автономный запуск (скрепкой). Если стартует, вынуть мать из корпуса, положиить на непроводящую подставку (плотный картон, например крышка от большой коробки), подцепить БП, память, проц, монитор (видео, если нет интеграхи), замкнуть на матери пины включения. Если стартует - проверить крепление на корпусе - возможно где-то КЗ.
Если БП не стартует от скрепки - помер. Если БП стартует, но с матерью не заводится - попробовать другой БП, вынуть память (пищать должен). Если не пищит без памяти - проверить греется ли проц.

Так вот, подставляя заведомо исправные детали можно выяснить - если они конечно же есть в наличии.

Можно конечно наплодить нотификаторов для каждого задания... Но как мне кажется проще "врезать" нотификацию в сами задания шага test

ps. Успех/неуспех проще всего ловить взводя флаг в before_script/script и обрабатывать в after_script

Переехать в другую страну.

Я серьезно. Туркменистан - маленькая страна, в которой сейчас происходит строительство местного кванмена. Еще немного - и контур безопасности замкнется и недоступны будут 100% сайтов. Вы не можете противостоять богатой и технически подкованной местной СБ.

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

Обычная практика: на каждой стороне прописывается список поддерживаемых/разрешенных алгоритмов и их параметров. А в момент "снюхивания" сторон между собой (как раз фаза согласования) они и выбирают тот вариант в который обе умеют.
Тем самым если задать на клиентской стороне единственный вариант - он и будет использован.

fail2ban добавляет именно IP-адреса, но когда вы просматриваете цепочку правил фаервола, утилита iptables осуществляет обратный DNS-резолвинг IP-адресов (reverse DNS lookup) в цепочке и отображает их в виде доменов. Полагаю, что это было сделано из соображений удобочитаемости. Чтобы отключить такое поведение, передайте флаг -n, когда будете вызывать команду iptables.

Конечно, актуально.
Мало того, Asterisk - это база/фундамент для всех остальных (по крайней мере, львиной доли) существующих продуктов виртуальных АТС на рынке.
Будете знать Asterisk, значит сможете легко разобраться с любой его коммерческой/некоммерческой "надстройкой".
А будете знать только определенную надстройку, значит будете знать только её.

Bash/Python, затем Ansible.

Попробуйте использовать "--no-interaction" или "--force" в команде - проверьте по help что есть.
Почему не работает - возможно stdin попадает в docker-compose и не передается php? Надо почитать/проверить.

Адрес шлюза даётся провайдером, так же как IP и маска, если мы говорим про статичные настройки
Ответ - спросить у провайдера

Если речь про какой-то метод определения шлюза по IP или волшебную команду то - нет.
Теоретически, если Ваш IP адрес никому не присвоен и "стандартная" маска верна(/24?) - можно отсканировать сеть(например Nmap) на предмет кто в сети UP, выписать все найденные IP адреса и попытаться подобрать шлюз перебором. В маске /24 256 адресов - собственно это максимальное колличество возможных варинтов. Ну, а если логически подумать, то самый лучший и оптимальный вариант - обратиться к тому, кто выдал статику и попросить дать адрес :)

Если бы основной шлюз можно было бы вывести из IP-адреса, то его не требовалось бы указывать, логично? ОС бы всегда брала IP-адрес, определяла бы по нему основной шлюз автоматически...
Совершенно точно можно сказать, что в вашем случае адресом основного шлюза будет один из IP-адресов той подсети, из которой взят ваш статический IP-адрес, за исключением собственно самого этого адреса, а также двух граничных адресов: самого младшего в подсети (адрес сети) и самого старшего (широковещательный адрес).
Довольно часто адресом шлюза делают следующий адрес за адресом подсети (как, например, 192.168.1.1 в случае, если это подсеть 192.168.1.0/24), порой это самый последний перед широковещательным адресом (192.168.1.254), но в общем случае это может быть любой, удовлетворяющий требованиям, что описаны выше.
Если же адрес шлюза не известен, то он смотрится в конфигурации работающей системы (например, на соседней машине), либо получается по DHCP вмести с остальными настройками (если использование DHCP заявлено или подразумевается), либо узнаётся у провайдера, либо из договора или приложения к нему, либо у поддержки провайдера, либо у системного администратора предприятия...

ssh user@host 'rm -rf четотам'

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

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