Bash Days | Linux | DevOps

Вчера на фоне поста про даунгрейд, прилетело довольно дофига вопросов. Сделал что-то вроде мини ФАКю, чтобы поменьше неопределенности было.
ㅤ
Вы помогаете написать резюме?

Да, но как только сдашь 20 домашек и мы с тобой поймем в какую сторону двигаться. Ты скидываешь мне своё резюме и мы с тобой его подробно разбираем и усовершенствуем. Прокачиваем до состояния — ИИ (Applicant Tracking System) пропускает, HRы обращают на него внимание.

Помогаете с трудоустройством?

Готовую вакансию не дам, но помогу найти людей, которые захотят тебя забрать к себе в команду. Работает это так: я пишу пост сюда, о том какой ты замечательный и что умеешь. Но напишу только правду, если слаб на передок, то это отразим. Чтобы для работодателя было все прозрачно и без сюрпризов. Тема рабочая, порой ты видел такие посты здесь например такой, много кто оторвал себе хороший и жирный оффер.

Будут созвоны 1x1?

Нет, текстовый формат. Мне тебе проще текстом всё ёмко объяснить, чем вешать лапшу на уши в реальном времени. К созвонам отношусь скептически и стараюсь их избегать, потому что в 99% мы будем общаться про всякую хуйню, а не по делу. Текст всё же держит в рамках и помогает сосредоточиться на главном.

А я устроюсь на работу если мне 40 лет?

Да, ты «баба ягодка», все хотят чтобы ты их выебал. И лишь ты выбираешь с кем будешь работать. Не они тебе нужны, а ты им. Главное взять себя в руки на пару недель и немного повоевать со своей ленью. Один раз инвестировал в себя и на десяток лет ты в малине.

А как вписаться?

Как обычно, через бота @tormozilla_bot, а если остались вопросы, можешь позадавать их мне тут @linuxfactorybot

🛠 #workflow #рабочиебудни
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Зарплатный даунгрейд

Короче, пришел ко мне в феврале человек на Linux Factory, подтянуть и освежить свои знания. Мол скучно ему стало, захотелось мяса. Трудится сеньором-помидором в крупной зеленой компании. Стандартная ситуация.
ㅤ
Ииии, как-то речь зашла про его ЗП и что он ей вообще не доволен. Но что-то менять страшно, ипотека, дети, да и возраст уже не тот, чтобы дрыгаться. Звоночек. С этим можно интересно поработать и доказать неочевидную гипотезу.

Гипотеза — все эти разделения на джун-писюн, мидл-хуидл и т.п. грейды никак не коррелируются с зарплатными вилками. Всё зависит от компании и их жадности. Богаче, не значит — лояльнее к сотрудникам.

Проводим пару внеурочных текстовых сеансов, набираемся мотивации, перелопачиваем вакансии (важно — ищем вакансии на Мидла), составляем продающее резюме, ходим по собеседованиям.

Ииии…. через неделю получаем оффер, причем очень жирный оффер, почти x2.5 от текущий ЗП. При условии, что график полностью удалёнка (не гибрид), нет кубера, стек из 40-50 виртуальных серверов, докер, гитлаб, даже ансибла нет.

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

Вот и думай. Шаг назад прям хороший. Гипотеза доказана.

Компании которые ворочают миллиардами, нанимают сотрудников на позицию Сеньоров за миску супа. А какие-то обычные Интернет магазины, готовы платить за Мидла 100500 мильонов в секунду.

Так что, нет ничего стыдного в даунгрейде, ведь любая работа прежде всего делается ради денег.

Отзыв этого человека как-нибудь размещу на сайте, а то там контекста много лишнего, надо отредачить.

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

Вот такие пироги. Не ссы и двигайся вперед, а то так и просидишь до старости пропёрдывая кресло.

🛠 #workflow #рабочиебудни
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Сегодня будем устанавливать в свой периметр крутую штуку. И называется она — Termix. Выбрал я её по причине — решил все 100500 серверов свести в одно место, возможно станет поудобнее. Да и поддержка VNC из коробки, а мне как раз надо кластер из mac mini m4 для ИИ админить. Ну и корпоративные винды всякие по RDP. В общем пока звучит очень вкусно.

Termix — это платформа для управления серверами с открытым исходным кодом, полностью бесплатная. Она предоставляет единое кроссплатформенное решение для управления серверами и инфраструктурой через один удобный интерфейс. Termix является альтернативой Termius и доступен на всех популярных платформах.

Termix предлагает:

- доступ к терминалу по SSH;
- управление удалённым рабочим столом (RDP, VNC, Telnet);
- создание SSH-туннелей;
- удалённое управление файлами;
- и множество других инструментов.

Короче эта штука позволяет подключаться по SSH и т.п. к серверам, прям из браузера. Довольно удобно собрать всё в кучу и забыть про ручную рутину. Хотя ручная рутина порой приятнее, чем все эти «новогодние ёлки» и клики мышкой.

Читать продолжение: https://two.su/ckebu

🛠 #devops #selfhosted
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Управление Docker контейнерами без Portainer и Dockge
ㅤ
Долгое время я сидел на Dockge, оно хостится у меня на малинке. А на самой малинке я гоняю: jellifyn, qbittorrent, grafana, prometheus, uptime kuma, watchyourlan, technitium dns.

Для таких целей Portainer крайне избыточен, мне в хер не уперся космический корабль, да и многое в Portainer сделано через жопу, хрен чё найдешь.

Поэтому Dockge покрывает все мои хотелки. Но рано или поздно хочется нового.

И новое это — DockHand. Причем этот проект не просто пилит какой-то энтузиаст, проект с закосом на интерпрайз. Но полностью opensource.

Люблю opensource, за то, что если есть закос на интерпрайз, то можно посмотреть исходники и реверснуть лицензию. С DocHand я пока особо глубоко не ковырялся, но чуть позже обязательно пропатчу, как собственно провернул это с mattermost, gitlab и т.п.

Да, по функционалу DockHand ничем не уступает Portainer и даже превосходит его. Для меня важно, чтобы всё было очевидно и понятно, без - хуй чё найдешь. И тут с этим всё прекрасно.

Ладно, чем бы дитя не тешилось. Вкорячиваем...

Читать продолжение: https://two.su/2517q

🛠 #devops #selfhosted
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Всем привет. Сегодня хочу поговорить о культуре написания условий bash. Точнее, об использовании отрицаний (НЕ).

🔤🔤🔤🔤🔤🔤🔤

Поводом послужила конструкция, которую я нашел при изучении одного скрипта:

if [[ ! -f "$file" || ! -r "$file" || ! -w "$file" ]];then
  echo "Ошибка: Файл отсутствует или нет прав на чтение/запись"
#  exit 1
fi

ㅤ
Расшифруем:

! -f "$file" - НЕ регулярный файл (возможно каталог, устройство, или вообще ничего).
! -r "$file" - у файла НЕт прав на чтение.
! -w "$file" - у файла НЕт прав на запись.

Условия объединены по ИЛИ, значит если выполнится какое-либо - будет ошибка.

С точки зрения логики - все правильно, но у меня лично в глазах рябит от количества палок.

👆На мой взгляд, отрицания сильно осложняют понимание.

Вспоминаем, что:

! A || ! B эквивалентно ! [ A && B ]
! A && ! B эквивалентно ! [ A || B ]

👆И помним, что пробелы в условиях bash критически важны.

Таким образом, конструкцию можно переписать, с сохранением функциональности:

if ! [[ -f "$file" && -r "$file" && -w "$file" ]];then
  echo "Ошибка: Файл отсутствует или нет прав на чтение/запись"
#  exit 1
fi

Расшифруем:

НЕ (файл регулярный И есть права на чтение И есть на запись). В этой конструкции тоже есть отрицание, но оно уже одно! Конструкцию можно привести к еще более человеческому виду:

if [[ -f "$file" && -r "$file" && -w "$file" ]];then
  :
else
  echo "Ошибка: Файл отсутствует или нет прав на чтение/запись"
#  exit 1
fi

Здесь отрицание заменено переносом тела if в тело оператора else.

":" необходимо, потому что между if и else должен быть хотя бы один оператор (в данном случае ":" эквивалент оператора true или nop.

Можно записать и:

if [[ -f "$file" && -r "$file" && -w "$file" ]];then :
else
  echo "Ошибка: Файл отсутствует или нет прав на чтение/запись"
#  exit 1
fi

👆 Обратите внимание на ":" после then

Но на мой взгляд, в данном случае, читаемость несколько ухудшится.

Хотя первая конструкции и остальные конструкции эквивалентны, но отличие все же есть - скорость работы (Особенно, если в качестве операндов будут использованы функции) И зависит эта скорость будет от сценария работы.

Если при объединении по ИЛИ первый операнд ИСТИНА, то остальные даже проверяться не будут.

При объединении по И все наоборот: остальные проверяться не будут - если первый операнд ЛОЖЬ.

Всем работы без багов.

🛠 #bash #linux
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Si vis pacem, para bellum

Все вокруг ноют, что у нас какой-то кризис в айти, рынок перегрет, вакансии схлопываются, а на одно место претендуют сотни кандидатов.

Да, так и есть. Искали мы тут QA специалиста, за неделю скинули более 2000 резюме. Это пиздец. Как будто нейронка по вакансии прошлась и нагенерила нам вайтишников.

С QA всё понятно, это самый простой вход в наш «цирк абсурда», но вот с другими вакансиями аналогичная ситуация. Причем кандидаты гнут пальцы и не хотят делать тестовые задания, даже за деньги.

Разленились падлы, подавай им сразу оффер и оклад 100500 мильонов за нехуй делать с обязательной удаленкой. Да идите вы нахуй!

Ладно, я немного про другое хотел тебе написать. Тема довольна избитая — стоит ли сейчас увольняться и прыгать на другую работу, если ты уже официально трудоустроен?

Однозначно стоит, если предлагают x3-x4 к текущей ЗП. Но возникает парадокс. Казалось бы, сиди тихо, цени текущее место и не дергайся. Но всегда есть НО.
ㅤ
Зона комфорта vs Испытательный срок

На текущем месте работы, ты знаешь как всё устроено, где что лежит, можешь с закрытыми глазами ориентироваться, в общем царь и бог. Работаешь от силы 2-3 часа в день в комфортном для себя режиме, ездишь по делам и пинаешь хуи.

На новом месте работы — баланс придется выстраивать с нуля, неизвестность, снова DODы испытательного срока, новые технологии, коллеги-токсики. И опять же уровень компетенции. Если на предыдущем месте ты уверенный мидл-сеньор, то на новом месте, грейды оцениваются иначе.

Коллега сеньор-фронтендер сходил в яндекс на технический собес ииии, барабанная дробь — его скилы оценили как джуновские, соответственно предложили ЗП намного меньше чем он рассчитывал. А всё, потому, что технологии шагнули вперед, а он всё еще на втором ангуляре кнопочки двигает.

Ежу понятно, что ключевой фактор это деньги. То есть здесь интересен не столько вопрос «правильно ли я поступаю», сколько вопрос «что именно я продаю и что покупаю».

Если смотреть со стороны:

Вместе с новой зарплатой получаем новый набор рисков:

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

Для кого-то лишние 200–300 тысяч рублей в месяц полностью стоят стресса и переработок. Для кого-то возможность спокойно жить, заниматься своими проектами, семьей или просто не выгорать ценнее любой прибавки к зарплате.

Есть еще один интересный момент. Если человек годами работает в режиме «пару часов в день», он постепенно теряет понимание своей реальной рыночной стоимости. Внутри компании может казаться, что всё хорошо. Но настоящий уровень всегда показывает только рынок.

Переходы позволяют проверить себя об этот рынок. И ты либо разъебёшься об камни реальности, либо выплывешь, всё будет зависеть от твоих скилов и компетенций.

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

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

Если это действительно x3, а не +20–30%, то я скорее понимаю такие решения. Зарплата в три раза выше способна за 1–2 года создать финансовую подушку, закрыть ипотеку, накопить капитал. Потерять комфорт неприятно, но комфорт — это тоже риск. Особенно в ИТ, где человек может годами находиться в тепличных условиях и не замечать, как рынок уходит вперед.

Короче хуй знает. Пишите в комменты свои мысли. Ни к чему не призываю, так, трёп…

А ты бы согласились поменять спокойную работу на зарплату в 3-4 раза выше, если бы знал, что работать придется действительно дохуя, да еще и проходить испытательный?

Моя стратегия сюда уже не влезла, опубликовал её в блоге 👇

Читать продолжение: https://two.su/nrzhw

🛠 #workflow
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Всем привет. Недавно прилетела неожиданная задача: Организовать скриптом sftp-обмен по со старых версий винды с аутентификацией по ключам.

🔤🔤🔤🔤🔤🔤🔤

С 10+ все понятно. Там и ssh и sftp из коробки есть настройка от linux вообще не отличается. А вот со старыми - проблема.
ㅤ
Почему до сих пор используются старые версии? Да потому что работают. А выставлять их наружу никто не собирается. Так что пока работает будет работать. Ну, я отвлекся.

Итак sftp. Я нашел две программы psftp (из комплекта putty) и winscp.

Попробовал обе и psftp пришлось забраковать. Оказалось, она не хочет работать, если не видит файлов в каталоге. (права xw (3)). А winscp.com (не сайт, программа для работы в скриптах из комплекта winscp) работает.

Вот ее и будем настраивать.

1. Генерим ключ без парольной фразы с помощью puttygen (из комплекта putty). Желательно выбрать EdDSA(Ed25519(255 bits). Он маленький, и с ним удобно работать. Сохраняем публичный ключ в формате *.ppk .

2. Для того, чтобы публичный ключ нормально читался его нужно привести к однострочному виду:

ssh-ed25519 AAAAC3....8cJiPqx0VAOmEI+yy user@host

Я редактировал прямо в vim.

3. После этоого вставляем ключ в authorized_keys на серваке.

4. Запускаем winscp.exe и в настройках → хранилище меняем реестр на ini файл. Это нужно сделать, чтобы скрипт работал и от другого пользователя.

5. В WinSCP.exe создать подключение например «servername» указав ключ. В подключении можно и начальный каталог указать сразу.

6. Обязательно протестировать соединение приняв fingerprint.

7. Создать скрипт обмена script.sftp типа:

   open servername
   put filename
   get filename1
   bye

8. Запуск скрипта обмена:

C:\prog\WinSCP\winscp.com /ini=C:\prog\WinSCP\WinSCP.ini /logsize=2*100K /script=C:\prog\WinSCP\script.sftp /log="C:\prog\WinSCP\script.sftp.log" /console

9. Иногда, Скрипт, при запуске из какой-нибудь программы типа 1c не срабатывает. Тогда строку пункта 8 проще записать в какой-нибудь servername.bat и выполнять его из программы через cmd:

c:\windows\...\cmd.exe /c C:\prog\WinSCP\servername.bat

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

Всем работы без багов.

🛠 #devops #windows
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Когда начинаешь вкатываться в Ansible, кажется что loop нужен вот прям всегда и везде. Но это не так.
ㅤ
Многие пишут:

- name: install packages
  ansible.builtin.apt:
    name: "{{ item }}"
    state: present
    update_cache: yes
    loop: "{{ packages }}"

А переменная packages содержит список пакетов на установку.

И вроде тут всё ок, НО apt вызывается для каждого пакета отдельно, а update_cache может дёргаться несколько раз. Это избыточно и ломает заложенные паттерны.

Поэтому правильнее будет сделать так:

- name: install packages
  ansible.builtin.apt:
    name: "{{ packages }}"
    state: present
    update_cache: yes

Здесь apt получает сразу список пакетов, кеш обновляется один раз, установка идёт одной транзакцией. Получается меньше оверхеда, всё происходит быстрее и логичнее.

В первом случае это «хак», ты делаешь loop из одного элемента, внутри которого уже лежит список.

Главная мысль тут — если модуль умеет принимать список — loop нахуй не нужен.

Loop нужен там, где логика на каждый элемент отдельная:

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

Короче не заLOOPайся и будет тебе счастье.

Ну а если хочешь стать гуру, я всегда жду тебя здесь.

🛠 #devops #linuxfactory #ansible
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Docker кеш без боли
ㅤ
Давай поговорим про docker и кеширование, тема вроде поверхностная, но как оказалось многие в ней плавают и особо не понимают почему их сборка каждый раз занимает 100500 минут.

А занимает она столько минут, по одной причине — копировать исходники нужно в последнем слое. Механизм тут простой, если какой-то слой изменился, то следующие слои будут пересобраны. Логично, что если ты копируешь исходники так:

FROM node:22
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
CMD ["node", "dist/index.js"]

Тебе пезда! Всё будет пересобираться каждый раз с нуля, никаким кешированием тут и не пахнет. Так делают многие, ведь оно работает и пофигу что долго.

В примере выше, команда COPY копирует весь проект. Представь, что ты изменил одну букву в конфиге и приехали. Кеш инвалидировался, сборка пошла по новой и RUN npm install доставит много удовольствия.

Ключевой момент тут исходники, которые меняются.

Получаем:

- заново устанавливает npm зависимости
- заново качает пакеты
- заново rebuild native modules
- тратит минуты в CI

Хотя зависимости вообще не менялись. Мрак! Фиксим:

FROM node:22

WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build
CMD ["node", "dist/index.js"]

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

COPY . .  
RUN npm run build

А RUN npm ci возьмется из кеша. Аналогично и в питончике и гошке:

COPY . .  
RUN pip install -r requirements.txt

COPY . .
RUN go mod download

Бест-практика простая: От самого стабильного → к самому изменяемому.

- base image
- системные пакеты
- lock-файлы зависимостей
- install dependencies
- исходники
- build
- startup

Короче думай паттерном, а не жопой — «Какие файлы меняются редко?» и выносить их максимально вверх Dockerfile.

Каждый RUN, COPY, ADD это новый слой. Docker пытается переиспользовать уже существующие слои из кеша. Если инструкция и все предыдущие слои не изменились — слой не пересобирается. Docker сбрасывает кеш начиная с измененного слоя.

Вот и вся наука.

🛠 #devops #docker
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Less и секретный режим мониторинга
ㅤ
Очередные консольные приколы о которых ты не знаешь. Есть такая красота:

tail -f /var/log/nginx/access.log

Эта команда будет в реальном времени выводить строчки из файла по мере их добавления. То есть ты можешь наблюдать за лог файлами как с авто-суфлёра.

НО есть аналог:

less +F /var/log/nginx/access.log

А если кто не знал, то в less можно пользоваться клавишами vim. Например, навигация hjkl.

Сразу видно, что утилиты затачивали под одну экосистему и unixway. Ну а теперь вкуснятина.

После выполнения команды less +F нажимаем CTRL+C и теперь можно передвигаться по выводу как раз теме же клавишами hjkl, что-то поискать /127.0.0.1, g/G, n/N.

На минуточку, в tail ты так быстро ничего не поищешь. Надо тормозить процесс, выгружать в файл, грепать-хуепать.

Ну а чтобы вернуться в режим наблюдения, нажимаем SHIFT+F и less возвращает режим мониторинга, строчки с логами продолжают бежать в реальном времени.

Так что less это не просто про пагинацию, а немного больше.

🛠 #bash #linux
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Тайна вызова Less в Linux утилитах

Привет ребят. Ща покопаемся в неочевидных вещах, залезем так сказать под капот.
ㅤ
Знаешь же такую команду:

git log

Тут всё просто, она выводит историю коммитов. И что примечательно, в конце будет пагинация (pager). Смотри картинку 1.

А теперь пойдем неочевидной дорожкой и выполним:

sudo mv /usr/bin/less /usr/bin/less.bak 

Ну и снова запустим git log: Смотри картинку 2.

Хуяк и нет больше пагинации. Сразу вывалилась простыня. О чем это говорит? А говорит это о том, что git использует внешнюю утилиту less при выводе истории коммитов, причем делает это по умолчанию.

Но если less накрылся пиздой, git сразу вывалит простыню без пагинации. Забавно! Давай подключим strace и подтвердим этот факт, запускаем:

strace -f -e execve git log

И видим картину маслом: Смотри картинку 3

Ага, запускается less, а теперь снова перемещаем less и смотрим выхлоп strace: Смотри картинку 4

Вот и прекрасно, словили ошибку error: cannot run less: No such file or directory. Но ожидаемый результат все равно получили.

Если выполнить команду echo $PAGER, то увидим, какая утилита будет использоваться для пагинации. По умолчанию less, но раз есть переменная, её можно переопределить. Давай попробуем это сделать.

apt install lolcat
export PAGER="lolcat"
git log

Иииии ебать копать: Смотри картинку 5.

Кстати не только git завязан на переменную $PAGER, такое же поведение ты можешь увидеть у утилит: man, systemctl, journalctl и т.п. Всё что работает с пагинацией, использует переменную $PAGER.

Ну и на закуску:

export PAGER="vim -"
man ls

Команда man ls будет выполнена в vim. То есть получается что любая программа, доверяющая $PAGER, фактически запускает произвольную команду пользователя.

А это уже еще один вектор атаки из арсенала пентестеров, о котором никто не рассказывает. Так что бери на вооружение, глядишь сгодится при прохождении очередного HackBox’а.

🛠 #security #linux
—
💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog