
Комментарии 27
Мне не нравится, что просто перегнали диалог с ИИ и вот вам статья. У нас тоже есть интернет и порой даже доступы до LLM. Нужна какая-то собственная рефлексия. Если бы развили идею про Infrastructure as Code, было бы любопытнее.
В качестве своего примера расскажу, что я тоже подсел на "вайбо-администрирование", сначала пользовался Ansible+OpenTofu для Hetzner, потом купил себе Beelink N150 и освоил для себя NixOS и вот "тут мне карта поперла". Суть NixOS в том, что ты настраиваешь свой Linux декларативно и там в систему заложено использование git (откажется запускаться, если какой-то конфиг не в git), легко можно возвратиться к любой версии изменения, а также поднять с нуля до актуальной версии одной командой `sudo nixos-rebuild switch --flake .#desktop` и LLM (по крайней мере крупные) отлично крафтит конфиги для этой системы. Очень классная штука, планирую некоторые свои сервера на NixOS теперь перевести.
Вообще сколько-то рефликсии тут присутствует. Если вы реально прочитали все, а не просто промотали мимо. И речь не про перегон диалога с ИИ. А про то, как можно достигнуть результата. Интернет у всех имеется. А вот понимание, как применить нейронки в своих реальных делах, есть пока что очень мало у кого.
А вот понимание, как применить нейронки в своих реальных делах, есть пока что очень мало у кого.
Да ладно!
Ну вот я не умею, пока быстрее документацию прочитать чем пробиться, через галлюцинации нейронки. И да скорее всего я неправильно пишу запросы.
Совершенно точно могу это сказать. Причем использовать их зачастую не умеют именно те, кому они могут дать наибольшие преимущества в реальной работе. Профессионалы, которые не верят во все эти вайбы.
Есть опыт "втягивания в пучину" нескольких сениор разрарабов. Это получается сделать только показав им реальные работающие кейсы.
От сотен нейроджунов на рынке толку сильно меньше, чем от нескольких опытных разрабов, взявших эту технологию на вооружение.
Ну NixOS перепридумал концепцию GitOps, получается
Не знаю в чем перепредумывание. Как по мне, это просто реализация той же концепции. Обычно используют что-то типа Ansible, но система NixOS мне видится более правильной, ибо она все изменения применяет "транзакционно" и если какой-то конфиг не применился, то NixOS не переключится на него. А если переключился и "поломался", вы легко можете возвратиться к любым предыдущим версиям.
Т.е. Вы загнали весь /etc, включая приватные ключи, пароли в конфигах и т.п., на сторонний сервер без шифрования?..
И, кстати, что там с правами доступа к файлам в /etc будет, если их из gitlab'а восстановить?
Это отдельный экспериментальный сервер, который не жалко. Чуть позже все чувствительное будет засунуто в .gitignore. И перегенерировано.
Есть такая софтина: etckeeper с хуками под apt, dnf, dnf5(DNF5 plugin for etckeeper support), pacman и др.
"store /etc in git, mercurial, brz or darcs"
Имхо в статье надо дописывать дисклеймер: "это плохая практика", в противном случае - будем учить плохому.
Это тоже так себе путь.
Если только исключать чувствительное - Вы всё равно будете закидывать на GitLab кучу типовых конфигов, которые Вы не меняли и менять не будете, но которые вполне себе меняются при апгрейде/установке пакетов. При восстановлении на сервер с другой версией ОС, набором софта или даже с другой датой последнего обновления проблем не избежать. Ну и LLMке контекст засорять незачем.
Плюс не всегда же у Вас будет один-единственный сервер, а как только их становится несколько - содержимое /etc на них начинает различаться, но в то же время остаются большие блоки изменений, которые надо бы применять ко всем или части серверов в зависимости от их роли, местоположения, софта...
...И, внезапно, мы понимаем, что это что-то очень знакомое, что тоже можно прекрасно "вайбкодить", но опираясь на проверенный инструмент. Делаем репозиторий со своими плейбуками Ansible (не забывая использовать ansible_crypt для секретов) и натравливаем LLMку на него - красота, все перечисленные выше проблемы отпадают, масштабируется до любых разумных размеров и нюансов.
После вашего предыдущего комментария полез убирать все из гита и благополучно убил коннект к серверу )). Не проверив внимательно рекомендацию нейронки.
В итоге вчера развернул сервер заново и использовал другой подход уже. В репе лежит отдельная папка только с теми конфигами, которые я правлю сам. Файлы с ними подключены в /etc на замену оригинальным конфигам. Такая схема более рабочей выглядит вроде бы. Эксперимент продолжается.
Сервер переразвернул довольно быстро. В следующий раз (но надеюсь его не будет ))) получится еще быстрее..
Топовый диалог с ИИ на эту тему, поржать чутка. Отдельные статьи видимо тут делать более не буду, раз не заходит.


Проверенный инструмент мне пока что не интересен. Не люблю многоуровневое нагромождение технологий. Для pet-проектов это излишне. Профессиональным девопсам я ни в коем случае не рекомендую собой наделанное.
Вижу слово вайб в заголовке - сразу понимаю, что статьи для прочтения нет, очередная ИИ генерация
Проблема: Mac передаёт LC_CTYPE="UTF-8" вместо правильного LC_CTYPE="en_US.UTF-8"
Специально проверил. На Mac и Debian 13.2 LC_CTYPE="ru_RU.UTF-8". Нет проблем по ssh

ИМХО. За правку системного sshd_config хочется уже руки отрывать. Есть отдельный каталог sshd_config.d для своих настроек.
Перед самым новым годом дважды пришлось спасать использующих эту старую пагубную практику.
Для "спокойствия" за безопасность на долгих новогодних праздниках они сделали обновления серверов. С которыми прилетели "обновленные" sshd_config. И они потеряли удаленный доступ к системам.
Спасибо за совет. Скорректирую репу.
Это что за интересный способ обновления, при котором, если пользователь ранее вручную изменил конфиг, он молча без подтверждения перезаписывается новым? apt, вроде, спрашивает, а в unattended режиме по умолчанию сохраняет пользовательский (что, впрочем, тоже может привести к любопытным последствиям, если в новой версии софта что-то deprecate'нули или поменяли дефолты :)
Админим Linux-сервер через Cursor AI