Bash Days | Linux | DevOps
Авторский блог от действующего девопса Самобытно про разработку, devops, linux, скрипты, сисадминство, техдирство и за айтишную жизу. Автор: Роман Шубин Реклама: @maxgrue MAX: https://max.ru/bashdays Курс: @tormozilla_bot Блог: https://bashdays.ru
Показати більше📈 Аналітичний огляд Telegram-каналу Bash Days | Linux | DevOps
Канал Bash Days | Linux | DevOps (@bashdays) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 23 797 підписників, посідаючи 5 708 місце в категорії Технології та додатки та 28 124 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 23 797 підписників.
За останніми даними від 16 червня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на -201, а за останні 24 години на -10, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 20.40%. Протягом перших 24 годин після публікації контент зазвичай збирає 11.53% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 4 855 переглядів. Протягом першої доби публікація в середньому набирає 2 744 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 17.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як bashdays, linux, bash, docker, скрипт.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Авторский блог от действующего девопса
Самобытно про разработку, devops, linux, скрипты, сисадминство, техдирство и за айтишную жизу.
Автор: Роман Шубин
Реклама: @maxgrue
MAX: https://max.ru/bashdays
Курс: @tormozilla_bot
Блог: https://bashdays.r...”
Завдяки високій частоті оновлень (останні дані отримано 17 червня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
ssh user@server
Permission denied (publickey).
Что я делаю не так?
Всё правильно, твой ssh клиент не знает, что ты пытаешься подключиться по ключам. Он идет на сервер по дефолту и ожидает что запросят пароль.
ㅤ
А вход по паролям-то мы отключили!
Особенно ребята испытывают страдания при запуске ансибла. И начинают грешить именно на ансибл и плейбуки, а дело тут опять же в этих ключах. Ансибл ходит на сервера по ssh, соответственно это агент и ему тоже нужно знать про ssh ключи.Не ссым, все уже придумали за нас. ➡️ Первый вариант:
ssh -i ~/.ssh/bashdays_rsa user@server
Через ключ -i указываем путь до своего ключа и со свистом залетаем на сервер.
Теперь твой клиент знает — ага, эта бестолочь догадалась указать ключ, ну ок, прогнусь.
Указывать каждый раз -i очень заёбисто, особенно если у тебя ssh ключей вагон и тележка, легко запутаться. Но тут тоже уже все придумано за нас.
➡️ Второй вариант:
Захуячиваем ssh-agent
sudo apt-get update
sudo apt-get install openssh-client
Запускаем агент в фоне:
eval "$(ssh-agent -s)"
И добавляем в него нужные ключи:
ssh-add ~/.ssh/id_rsa
ssh-add ~/.ssh/bashdays_rsa
ssh-add ~/.ssh/ed25519
Смотрим что у нас торчит в агенте:
ssh-add -L
Ага, все ключи добавлены. Теперь не нужно указывать ключ -i, агент сам подкинет нужный ключ. Ну и ансибл сразу засвистит-запердит как надо.
Прикол с агентом:
Если на ssh ключе у тебя установлен пароль, то достаточно один раз его ввести и все последующие разы он у тебя не запрашивается.
Не прикол с агентом:
Как только ты закроешь консоль, агент уедет на кладбище со всеми ключами.
Решение:
Хуярим в ~/.profile (или чо там у тебя) такую конструкцию:
if [ -z "$SSH_AUTH_SOCK" ]; then
eval $(ssh-agent -s) > ~/.ssh/ssh-agent
fi
ssh-add ~/.ssh/id_rsa
ssh-add ~/.ssh/bashdays_rsa
ssh-add ~/.ssh/ed25519
Теперь при открытии консоли, у тебя будет автоматически запускаться ssh-agent и добавляться нужные ключи.
Для zsh, в конфиге ~/.zshrc прописываем:
plugins=(git ssh-agent)
zstyle :omz:plugins:ssh-agent agent-forwarding on
zstyle :omz:plugins:ssh-agent identities id_rsa bashdays_rsa ed25519
zstyle :omz:plugins:ssh-agent lifetime
Включаем плагин ssh-agent и добавляем все нужные ключи. Теперь из коробки у тебя будет работать агент и в нем будут подгружены ключи.
➡️ Третий вариант:
Через конфиг ~/.ssh/config, открываем этот файл у себя на машине и пишем:
Host bashdays.ru
Hostname bashdays.ru
IdentityFile /home/user/.ssh/bashdays_rsa
Теперь когда ты будешь подключаться по ssh к серверу bashdays.ru, то автоматически подставится указанный файл с ключами.
Таким способом разруливают разные ключи для разных учеток в гитхабах/гитлабах.
Например, так:
Host github.com
Hostname github.com
IdentityFile ~/.ssh/id_ed25519
Host github.com-bashdays
Hostname github.com
IdentityFile ~/.ssh/bashdays_rsa
➡️ Четвертый вариант:
Сделать алиасы:
alias stage='ssh -i ~/.ssh/bashdays_rsa user@server'
alias prod='ssh -i ~/.ssh/id_ed25519 root@server'
И потом просто в консольке вбивать stage или prod, все автоматически подставится.
🅰️🅰️
Я использую все варианты, в зависимости от ситуации, но в предпочтениях у меня ssh-agent и алиасы.
Да, в ансибле можно тоже прописать хардкодом ssh ключ, чтобы не использовать агентов и т.п.
Через конфиг ansible.cfg:
[defaults]
private_key_file = ~/.ssh/bashdays_rsa
Через переменную окружения:
export ANSIBLE_PRIVATE_KEY_FILE=~/.ssh/bashdays_rsa
Есть еще 100500 способов как в ансибле это передать, я показал основные. Если хочешь узнать про все, велком в LF.
Если знаешь еще какие-то варианты и приколюхи с ключами, камон в комменты, соберем в кучу полезняхи.
С пятницей друзья!
tags: #git #devops #ssh #linuxfactory
—
🔔 @bashdays➡️ @gitgate➕ Видеокурс «Мониторинг в Grafana» в подарок до 31 января — для тех, кто хочет научиться работать со связкой Prometheus+Grafana, разбираться в работе системы и читать созданные графики. 🔥Старт потока 10 февраля Подробности и программа курса — на сайте 👈 Реклама ООО «Слёрм» ИНН 3652901451115 000 ₽80 000 ₽
sudo apt install dislocker
После установки создаем пару папок:
sudo mkdir -p /mnt/bitlocker
sudo mkdir -p /mnt/bitlockermount
Смотрим зашифрованные разделы fdisk -l ну или lsblk. Ну а дальше делаем финт ушами:
sudo dislocker <partition> -u<password> -- /mnt/bitlocker
Расшифровываем раздел, подставляем нужный partition и password. Partition берем тот что нашли через fdisk или lsblk. Что-то типа /dev/sdd1 /dev/sdc1.
Монтируем:
sudo mount -o loop /mnt/bitlocker/dislocker-file /mnt/bitlockermount
Чтобы подключить раздел только для чтения, добавь в обе команды ключ -r. Рекомендую все же подключать с этим ключом.
Если получил ошибку:
mount: /mnt/bitlockermount: wrong fs type, bad option, bad superblock on /dev/loop10, missing codepage or helper program, or other error.То укажи явно тип файловой системы: Для ntfs:
sudo mount -t ntfs-3g -o loop /mnt/bitlocker/dislocker-file /media/bitlockermount
Для exFat:
sudo mount -t exFAT-fuse -o loop /mnt/bitlocker/dislocker-file /media/bitlockermount
Еще момент, вместо пароля можно использовать пароль восстановления, файла BEK или открытого ключа с помощью которого производилось шифрование.
Для пароля восcтановления: -p<password>
Для открытого ключа: -c
Для BEK: -f <BEKFILE>
Заметь что после ключа -p нет пробела, это важно.Ну вот и всё. Теперь ты умеешь подключить диски с BitLocker. А что бы такой диск подключался автоматически, камон в fstab:
<partition> /mnt/bitlocker fuse.dislocker user-password=<password>,nofail 0 0
/mnt/bitlocker/dislocker-file /media/bitlockermount auto nofail 0 0
Подставляем свои значения и радуемся.
➡️ Репа dislocker тут, можешь глянуть что там у нее под капотом.
Кстати диски с битлокером отлично открываются в Fedora Silverblue из коробки (с помощью recovery password). По крайней мере в прошлом году точно открывались. Можешь ее на виртуалку поставить и развлекаться.
tags: #linux #windows #utilites
—
🔔 @bashdays➡️ @gitgatessh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAAAAAwA...
И был он гораздо короче тех к которым я привык. Всего 256 бит. А привык я естественно к RSA.
ㅤ
Хуйня! Чем короче тем уязвимее — подумал я и запросил нормальный, тот который ssh-rsa.
Ну а потом спустя какое-то время проресерчив тему, узнал что ed25519 это всего лишь один из видов ключей которые можно пропихать в ~/.ssh/authorized_keys. И всё будет работать!
Причем такой ключ гораздо надежнее чем легаси rsa. Короче не значит хуёвее.
Распространенные типы ключей:
rsa, ecdsa, ed25519, dsa (устаревший), может что-то еще существует, хуй знает, не интересовался.
ssh-rsa AAAAB3NzaC1yc2EAAAABIw... ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTI... ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICm8x... ssh-dss AAAAB3NzaC1kc3MAAACBAPnsfNOnD...Чтобы сгенерить такие ключи, нужно прописать их тип в параметр -t
ssh-keygen -t dsa -f ~/.ssh/bashdays_dsa
А дальше делаем всё как написано тут и тут и ходим на сервер по ключам.
Почему «короче» не значит хуёвее?
Давай сразу на примерах.
Представь, что у тебя есть два лабиринта:
- В одном лабиринтеХотя лабиринт с простым числом (RSA) кажется меньше, его можно быстро решить с помощью методов, использующих факторизацию больших чисел. А вот лабиринт с эллиптической кривой (ED25519) будет гораздо более сложным для прохождения, даже если его размеры кажутся меньше, потому что для нахождения решения требуется гораздо больше вычислений. Хотя ED25519 ключ меньше по размеру (256 бит против 2048 бит в RSA), его решение гораздо сложнее из-за самой природы криптографии. 🅰️🅰️ Есть еще ключи в формате ppk, это те ключи которые можно сгенерить с помощью ебанутого PuTTYgen. Порой мне такие тоже скидывают, чтобы я их прописал. Но такие персонажи сразу идут — нахуй! Чтобы сконвертить такой ppk в нормальный ключ openssh, в самой морде PuTTYgen нужно сделать экспорт:(пики точеные)тебе нужно просто найти правильное число, которое делится на два других (RSA). - В другом лабиринте(хуи дроченые)тебе нужно найти точку на сложной кривой, которая соответствует определенному числу (ED25519).
"Conversions" → "Export OpenSSH Key"Либо через командную строку:
sudo apt update
sudo apt install putty-tools
puttygen bashdays.ppk -O private-openssh -o id_ed25519
ssh-keygen -y -f id_ed25519 > id_ed25519.pub
Устанавливаем нужный софт, конвертируем, высекаем публичный ключ.
🅰️🅰️
Для меня ed25519 всё равно чуждый, привык что-ли я к rsa, поэтому предпочитаю именно его. Ну а ты сразу привыкай к хорошему.
ED25519 кстати нормально поддерживается в gitlab/github/gitea и отлично подходит для высоконагруженных систем и аутентификации.
tags: #git #devops #linuxfactory
—
🔔 @bashdays➡️ @gitgate➕ Видеокурс «Мониторинг в Grafana» в подарок до 31 января — для тех, кто хочет научиться работать со связкой Prometheus+Grafana, разбираться в работе системы и читать созданные графики. 🔥Подробности и программа курса — на сайте 👈 За 7 недель вы научитесь: 🔸переносить продукт на платформу k8s 🔸разворачивать отказоустойчивые кластеры 🔸ускорять траблшуттинг 🔸повышать отказоустойчивость продукта 🔸разворачивать и обслуживать кластер с автоматической ротацией сертификатов, автодеплоем и правильным хранением секретов Еще раз ссылка на сайт 👈 Реклама ООО «Слёрм» ИНН 3652901451145 000 ₽110 000 ₽
/etc/ssh/sshd_config.
Активируем эти строчки:
PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keysПотом делаем так:
ChallengeResponseAuthentication no PasswordAuthentication no PermitEmptyPasswords no PermitRootLogin no UsePAM noОтключаем пароли, запрещаем вход под рутом, ну и так по мелочи. Мелочи расписал в комментах. Тут есть нюанс, при
PermitRootLogin no ты иногда все равно сможешь зайти под рутом. Тут все дело в невинном файле который порой пихают из коробки.
/etc/ssh/sshd_config.d/50-cloud-init.confЭтот файл содержит реврайт, в нем будет
PermitRootLogin yes.
Так что, если ты отключил это в основном конфиге, проверь, а нет ли где-то еще реврайтов. На эти грабли очень часто наступают и тратят пол дня на дебаг.После того как ты сделал все изменения, нужно выполнить:
sshd -t
systemctl reload sshd
Если первая команда отработала без ошибок, то запускаем reload.
➡️ Важно! Терминал в котором ты всё это настраиваешь — закрывать не стоит, сессия будет жить даже если накосячил.
Сначала открой второй терминал и проверь что ты можешь снова войти на сервер по ключам или как минимум по паролю если сервер его запросил.
Бывают неприятные моменты, когда ты отключил вход по паролю и ssh ключи не завелись. Пизда рулю. Позже покажу как и это решать малой кровью.В некоторых современных дистрибутивах, перезагрузка sshd поставлена на поток, ты меняешь конфиг и если с ним все ок, конфиг автоматически перечитывается службой. Носи это у себя в голове. Ну и еще про конфиги ssh, на сервере есть пару похожих конфигов, их часто путают и делают хуйню.
/etc/ssh/ssh_config
/etc/ssh/sshd_config
Первый это настройки поведения клиента. То есть если ты с этого сервера решишь куда-то подключиться по ssh, то применятся настройки из этого файла.
А второй соответственно это серверные настройки. Твоя локальная машина это клиент, подключается к серверу, сервер берет настройки из /etc/ssh/sshd_config.
Вот и всё. Если читал внимательно, у тебя в голове должен был сложиться правильный пазл. Ну и доступ по ключам тоже заработает.
Тыкай, проверяй, задавай вопросы в комментах и пиши свои дополнения. Я человек пожилой, мог чего-то нахуевертить и упустить.
Увидимся, это еще далеко не всё.
tags: #git #devops #linuxfactory
—
🔔 @bashdays➡️ @gitgateЗадача — хочу с локальной машины подключиться к серверу по ssh используя ключ.Смысл тут такой: у тебя есть 2 ключа, один приватный, второй публичный. Приватный ключ ты хранишь как свою жопу и задом к лесу не поворачиваешься. Публичный ключ прописываешь на удаленных серверах, к которым тебе нужно подключиться.
В момент подключения к серверу публичная часть ключа «сравнивается» с приватной частью и если все хорошо, то включается зеленый свет.А если всё хуева… то отправляемся дебажить, как эффектевно дебажить расскажу попозже. ㅤ Давай тыкать. Генерим RSA ключ на своей машине. Про форматы ключей rsa/dsa напишу также отдельно, пока делаем rsa.
ssh-keygen -t rsa -b 4096 -N "" -f ~/.ssh/bashdays_rsa
Эта команда сгенерит без лишних вопросов новый ключ и положит его в ~/.ssh/.
Параметр -N указывает что на ключе не будет парольной фразы. Если по безопасности упарываешь, то можешь поставить пароль и ебстись с ним в будущем.
Остальные параметры думаю для тебя очевидны. Тип ключа, битность, куда положить.
Теперь у тебя в папке ~/.ssh/ два ключа bashdays и bashdays.pub.
Соответственно первый это приватный (храним его как свою жопу), второй это публичный (шлюха ключ).
Если попал в ситуацию, что публичный ключ проебался, можешь его сделать на основе приватного ключа, делается так:
ssh-keygen -y -f ~/.ssh/bashdays_rsa > ~/.ssh/bashdays.pub
Дело в шляпе. Тут самое главное не въебать приватный ключ. Ну а если въебал, сочувствую.
А дальше… а дальше нужно публичную часть ключа прописать на сервер, к которому ты хочешь подключиться.
Делается так:
ssh-copy-id -i ~/.ssh/bashdays.pub root@server
Если у тебя свежий сервак, то по умолчанию включен вход по паролю, на эту команду оно запросит пароль. Введи разок и ключик залетит на сервер.
➡️ Важно! Этой командой мы добавили на удаленный сервер ключ для пользователя root.
То есть подключиться по ключам на сервер ты сможешь только под пользователем root. Если у тебя на удаленном сервере какой-то есть юзер, например: suchka, то и команда будет такой:
ssh-copy-id -i ~/.ssh/bashdays.pub suchka@server
Тут мы поменяли root на suchka.
Теперь получается я могу используя приватный ключ bashdays_rsa, подключиться к удаленному серверу так:
ssh -i ~/.ssh/bashdays_rsa root@server
ssh -i ~/.ssh/bashdays_rsa suchka@server
То есть под рутом и под сучком. Аналогично добавляешь ключи для других юзеров.
Вообще под рутом не рекомендую ключи какие-то прописывать, делай сразу для юзера и через sudoers наруливай ему права.
Я обычно не пользуюсь ssh-copy-id, а сразу ручусь на сервер под паролем, руками создаю файл /home/user/.ssh/authorized_keys и в него просто копирую содержимое публичного ключа bashdays.pub.
Но тут есть ряд нюансов. У файла authorized_keys должны быть права 600 или 644. Иначе на сервер не пустят. У меня всегда 600.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
А еще могут возникнуть проблемы с копипастой, не всегда удается скопировать ключик верно. Поэтому рекомендую сразу привыкать к хорошему и пользоваться ssh-copy-id.
Ну и однострочник на баше для копирования ключа:
cat ~/.ssh/bashdays_rsa.pub | ssh username@server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"
Вечерком продолжим. Пока мотай на ус.
tags: #git #devops #linuxfactory
—
🔔 @bashdays➡️ @gitgategit add .
git commit -m "ебальник убивальник"
git push
Если что-то напрягает, это что-то нужно оптимизировать. Тут всё как обычно банально. Делаем алиас и избавляемся от рутины.
ㅤ
Умеешь алиасы делать? Ладно, раз тут разжевываем, покажу.
Открываешь ~/.bashrc или чо там у тебя ~/.zshrc и пиздяришь:
alias gg="git add . && git commit -m \"$(date +'%d-%m-%Y %H:%M:%S')\" && git push"
Не забываем сделать source ~/.bashrc && ~/.zshrc. Теперь когда нужно что-то закомитить и отправить. Просто пишем «gg» и дело в шляпе.
В описание коммита попадет текущая дата и время. В продуктовой команде тебе конечно пизды дадут за это, но если что-то пилишь для себя то вполне допустимо.
Ну или если работаешь в VSCode или т.п. там плагины для гита есть, мышкой можешь в один клик отправлять все свои изменения в репу, без всяких алиасов.
А можно еще прям в конфиге гита сделать алиас
[alias]
cm = "commit -m"
либо командой:
git config --global alias.cm "commit -m"
Тогда команда для коммита будет такая:
git cm "initial commit"
Пример файла с нативными алиасами:
тыкни на блок и он раскроется (это спойлер):
[alias] a = add aa = add . c = commit cm = commit -m s = status pl = pull pu = push df = diff b = branch bl = branch --all bd = branch --delete bD = branch -D bren = branch -m bdr = push origin --delete fa = fetch --all fp = fetch -p t = tag tf = fetch --tags tpu = push origin --tags tpuacq = push acquia --tags td = tag -d tpur = push origin --delete tpuacq = push acquia --delete co = checkout cob = checkout -b resh = reset --hard lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --graph clear = clean -f -d clearw = checkout -- .Нихуя сложного, правда же? А вообще девопс должен знать всего две основных команды:
git push и git pull
Всё остальное лежит на плечах разработчиков. Пусть они ебуться с мерджами, конфликтами и т.п. У девопса другие задачи.
Если уж нужно что-то смержить, смержить можно мышкой через морду или просто забить хуй.
Вот так и живем! Пользуйся!
tags: #git #devops #linuxfactory
—
🔔 @bashdays➡️ @gitgategit@, а публичные можешь и через https.
Если попробуешь склонировать приватную репу через https, оно запросит у тебя логин и пароль от учетки гитлаба/гитхаба. Но такие вещи обычно делают на ssh ключах, без хуйни и паролей.
git clone git@gitlab.com:linuxfactory/infra.git
Есть еще хороший хак, если в к конце этой команды добавить символ точки «.» через пробел, то репка склонируется в текущую папку (не будет создана папка infra) НО при условии что папка на локальной машине у тебя пустая, иначе получишь git add .
git commit -m "initial commit"
git push
Не забываем что однажды получишь сообщение: Author identity unknown, про этот случай я рассказывал вчера.
Всё. Никаких ебучих конфликтов, тонны комманд и т.п. все прозрачно и просто. На первых этапах прям рекомендую использовать этот способ. Меньше говна хлебнешь.
Второй вариант
cd /path/to/project
git init
git add .
git commit -m "initial commit"
git remote add origin https://gitlab.com/username/reponame.git
git push -u origin master
Как видишь тут уже дерьма побольше, сложновато запомнить неокрепшему уму. К тому же можешь словить ряд ошибок:
fatal: repository not found remote: HTTP Basic: Access denied remote origin already exists Updates were rejected because the tip of your current branch is behind error: failed to push some refsПридется гуглить, делать
rebase или вообще конфликты решать. А решать конфликты это то еще удовольствие.
Теперь даже если что-то локально нахуевертил в гите, просто ёбни папку .git в проекте. Сделай все по первому способу и всё починится. Это намного быстрее чем разгребать и дебажить неочевидные ошибки.
tags: #git #devops #linuxfactory
—
🔔 @bashdays➡️ @gitgateAuthor identity unknown
*** Please tell me who you are.
Run
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
to set your account's default identity.
Omit --global to set the identity only in this repository.
fatal: empty ident name (for <user@dev.>) not allowed
Не устану повторять — читай то, что тебе пишут!
Эта штука появляется в момент команды git commit.
В ошибке говорится — я хуй знает кто ты такой, давай уже определись и тогда все заработает.
То есть гит не знает от чьего имени оправлять коммит в репозиторий.
Как решать?
Ну оно тебе явно уже написало какие команды нужно забить. А забить надо пару строк:
git config --global user.email "hello@devopsina.ru"
git config --global user.name "Roman Shubin"
Всё, теперь коммит подпишется и ошибка уйдет. Глобальные настройки обычно лежат в файле ~/.gitconfig
Ну дак оно же глобально прописалось для всех реп??
Конечно, но это можно изменять в конфиге самой репы. То есть допустим у меня есть 2 репы:
1. BashDays 2. LinuxFactoryВ первом случае я хочу подписывать и отправлять коммиты как Roman Shubin, а во втором как Harbor Whore. Сейчас на глобальном уровне в обоих случаях будет Roman Shubin. Чтобы это пофиксить. Открываем нужную нам гит репу на своей машине, пиздуем в папку
.git и открываем на редактирование файл config.
Ну и в него добавляем секцию user.
[user]
name = Roman Shubin
email = hello@devopsina.ru
Соответственно для второй репы делаем тоже самое, только меняем мыло и имя на нужное тебе.
Если руками в падлу писать, выполняем команды:
git config user.email "hello@devopsina.ru"
git config user.name "Roman Shubin"
Тут отсутствует ключик --global.
Ну и чтобы посмотреть кем подпишется коммит, есть команда:
git config --list --show-origin
Находясь в папке с репой, она выведет всю необходимую информацию. Порой очень полезно предварительно проверить, перед пушем в репу.
Ну и скучная, но важная теория:
- Если вы используете GitHub, GitLab или другую платформу, и хотите, чтобы ваши коммиты были связаны с вашим аккаунтом, то email, указанный в Git, должен совпадать с email, привязанным к вашему аккаунту на этой платформе. Это нужно для того, чтобы платформа могла корректно отображать ваши коммиты в вашем профиле. - Если email не совпадает, коммиты все равно будут отправлены, но они не будут автоматически связаны с вашим аккаунтом на платформе.Такие дела. Видишь, не все так сложно как ты думаешь. Завтра рассмотрим еще очень важные вещи, от которых жопа обычно горит на начальных этапах. tags: #git #devops #linuxfactory — 🔔 @bashdays➡️ @gitgate
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576 GIT LFS. Дословно — Large File Storage (дохуя большое файловой хранилище).
У LFS уже свои лимиты в отличие от нативного git репозитория. И это LFS включен из коробки в гитлабах/гитхаба/битбакетах. Там уже размер файла может быть 1 гигабайт или что-то вроде того.
В gitea тоже можно LFS через конфиг включить:
[server]
LFS_START_SERVER = true
LFS_ALLOW_PURE_SSH = true
[lfs]
PATH = /home/gitea/data/lfs
Как этим пользоваться?
Ставим к себе на машину:
apt-get install git-lfs
brew install git-lfs
Переходим в свой гит репозиторий и инициализируем:
cd /home/user/linuxfactory/infra
git lfs install
В папке /infra/roles/node_exporter/files у меня лежит бинарник node_exporter который весит 100 мегабайт
На самом деле я хуй знает сколько он весит, это для примера.
Помечаем его:
cd /infra/roles/node_exporter/files
git lfs track "node_exporter"
После этого в папке files появится файл .gitattributes. Это правила для этого файла, которые указывают чтобы node_exporter улетал в LFS.
Внутри этот файл выглядит так:
node_exporter filter=lfs diff=lfs merge=lfs -text
И по итогу бинарник в репе станет ссылкой на настоящий бинарник в LFS.
А еще можно вайлдкардами трекать:
git lfs track "*.jpg"
Ну а дальше, как обычно:
git add .
git commit -m "add lfs for node_exporter"
git push
Всё! Теперь твой большой файл аккуратно лежит в LFS, а в самом гит репозитории осталась лишь ссылка которая на этот файл ссылается.
Мне тут пришлось партнерских постов на эту неделю понабрать, реинвестируем в развитие @gitgate, так что рекомендую включить баннерную слепоту и сильно не триггериться. Спасибо за понимание!
Чтиво: про LFS можешь глянуть еще тут и тут.
tags: #git #devops
—
🔔 @bashdays➡️ @gitgate1. Bombardier 2. StressПервая (Bombardier) отлично подходит для генерации паразитного http трафика.
bombardier -c 125 -n 10000000 http://localhost:8080
Вторая (Stress) можно нагрузить ядра процессора и позырить чо будет. Ну или над жестким диском надругаться или памятью.
stress --cpu 4
stress --hdd 100
stress --cpu 4 --vm 2 --io 1 --timeout 20
Ну а чтобы протестировать no space left on device просто генерим большой файлик удобным тебе способом.
Установка элементарная:
apt install bombardier stress
Эти утилиты отлично подходят для тестирования разнообразных алертилок, к примеру alertmanager. Нагнал синтетических данных, получил соплю в графане, алертилка тригернулась и накричала в чатик. Отладил, задеплоил.
Красота и удобно! Для этих дел есть еще всякие wrk, ab, hey и т.п. но с ними как-то у меня не сложилось.
Такие дела, бери на вооружение, мож сгодится в хозяйстве.
tags: #utilites #highload #qa
—
🔔 @bashdays➡️ @gitgate
Вже доступно! Дослідження Telegram за 2025 — головні інсайти року 
