Добавлю, что в достаточно новых версиях ssh ещё и хост открытым текстом не пишет - чтобы нельзя было, украв known_hosts, узнать куда ходил этот пользователь и куда направить последующие атаки, особенно если пароль пользователя уже скомпроментирован.
Роман Безруков, одно другому не мешает, у нас юзеров создают из ansible, который запускается в jenkins...
Правда, я обычно всё равно гоняю ansible напрямую, потому что при каждой попытке использовать у меня что-то идёт не так: то повиснет на умершем хосте, то --limit неправильно прочитался и потому проигнорировался (привет прогон по всем серверам), то хочешь отменить и он час висит не отменяется...
CeMgnom, подписаться на телеграммические каналы zatelecom, usher2 итд итп где регулярно пишут если подобное начинается.
openvpn и тем более wireguard слишком легко детектится и потому ломается даже без бана IP. Для обхода этого tls-crypt в openvpn может помочь (а может не помочь), лучше же начать использовать протоколы, которые пока не блокируются (shadowsocks, amnesia, vless, xtls-reality и другие подобные слова). Самый лёгкий способ из всего этого на текущий момент - outline. Себе ставишь менеджер, который настраиваешь на конфигурирование хоста по инструкции, где в докере будет запущен shadowsocks, клиентам даёшь ключи, сделанные кнопкой в этом менеджере. Работает на компе и мобилке очень легко и понятно.
Скорее всего, используется не кликер, а прямые запросы к API.
Ну а вообще это не дело, и лучше бы начальство озаботилось этой проблемой. Хотя если все лиды будут забираться одним человеком, оно и так может заподозрить неладное...
asmelnik, так иногда делают, чтобы поднимающийся VPN или роут из динамической маршрутизации не перетирал имеющийся default route, что в случае чего спасёт от полной потери сети.
upd: хотя тут скорее наоборот, чтобы родной роут не трогать, поверх два в VPN.
У проекта/продукта в любом случае должен быть Project Manager и/или Product Owner, который и должен заниматься формированием требований, установкой приоритетов, написанием ТЗ, роудмапов, оценкой ресурсов, контролем исполнения итд итп. Да, он может консультироваться с разработчиками (и вообще не обязан сам уметь программировать), но важные решения по жизненному циклу разработки принимает он самостоятельно.
И у разработчиков в любом случае должен быть Team Lead, который должен принимать фундаментальные решения и иметь последнее слово в случае неопределённых ситуаций.
Если кучка равноправных разработчиков получае задание в форме "сделать хорошо" от директора Департамента Тысяч Очешуительных Решений в Области Импортозамещения, а дальше как-то вынуждена договариваться (или, наоборот, рвёт друг другу волосы в невозможности достичь консенсуса), то это к слову agile не имеет никакого отношения.
holy_paster, понятно, что из нейросети можно что-то выжать. Но тут такая плёвая задача, что если даже её не получается без нейросеток, то это уже о человеке очень много говорит.
Тем более что нейросеть может сморозить полную чушь вообще легко.
Что мешает сделать копию docker-compose.yml и отредактировать в нём что угодно? А затем поднять с ним сервис (-f имя_файла.yml). Оригинальный файл не пострадает.
Нужна не выжимка, нужно отличать красные строчки от чёрных. С учётом того, как "офисные пакеты" умеют гадить в форматирование, это может оказаться даже сложнее, чем кажется. Я не уверен даже, что ChatGPT поймёт вопрос правильно - не то что сделает пригодный результат.
Мода на нейросети по любому самому плёвому вопросу - это ужасно.
Иван Гришов, если так важно числовые ключи в конец, то можно им добавить текстовый префикс, чтобы они не считались числами... Ну или поместить их в отдельное дочернее поле:
47911, нет, дело в местном провайдере или каких-то магистральных по дороге (скорее всего, тоже местных национальных). В LE проблем нет, если специально не накорячиться в настройках (а я слабо верю, что это сделано в продаваемых в ОАЭ iPhone), то всё будет работать повсеместно.
historydev, полезно даже не бэкапить виртуалки, а практиковать автоматизацию их разворачивания. Например, писать плейбуки для ansible, с помощью которых свежеустановленная система получает нужный софт с нужными базовыми настройками (nginx/php/docker/юзеры/права/настройки/итд/итп). Сайты, которые в сырцах (например, на php или python) разворачивать из git, но параметры конфигурации (например, реквизиты базы) не хранить в git. Обычная практика: в git лежит config_example.php с демонстрационным набором параметров, а для прода делают копию файла и меняют значения на реальные. Это рекомендация по личному развитию, если освоить подобный подход, то можно существенно улучшить поддержание текущих и поднятие новыхп роектов.
От паролей ssh лучше отказываться. Пароль должен или не использоваться совсем, или быть крайним вариантом на чёрный день и быть у каждого сервера разным автогенерированным и храниться где-нибудь там, где его легко не найдут!
Вместо пароля использовать ключи. Причём в хорошем варианте ключи хранятся только на локальной машине, а на удалённую (откуда практикуется ssh на какие-то ещё другие хосты) прокидываются через ssh-agent. Но для начала хотя бы просто начать использовать ключи. Можно вплоть до того, чтобы каждому серверу свой ключ, чтобы при утечке какого-то одного ключа не пострадало вообще всё.
Спам тэгами запрещён. В этом вопросе достаточно тега discord и даже лучше тэг discord.js, остальное - это мусор.