Еще один частый затык с гитом — у тебя создана чистая репа в гитлабе и локально на машине лежит уже наработанный проект. Но проект еще не под гитом.
ㅤ
Как заебенить проект в репу в гитлабе?

Первый вариант

Самый беспроигрышный и лёгкий вариант — это склонировать себе эту чистую репу в какую-нибудь папку и затем просто перетащит в эту папку все файлы из твоего проекта.

Приватные репы клонируй через git@, а публичные можешь и через 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➡️ @gitgate

И снова здрасти, продолжаем больные темы.

А еще ребят пиздец напрягает каждый раз делать:

git 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➡️ @gitgate

Такс, по гиту немного прошлись (но еще вернемся), теперь по ssh ключам. Для многих как оказалось тоже большая проблема. Но это база, поэтому нужно с этим научиться жить. Принять и простить.

Задача — хочу с локальной машины подключиться к серверу по 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➡️ @gitgate

На прохождение Cyber Shadow я потратил 20 часов и сдох 727 раз. Что сказать, моя жопа давно так не горела, со времен Ninja Gaiden на Денди. Но своеобразное удовольствие я всё же получил.

Ладно, сегодня продолжаем серию постов #linuxfactory
ㅤ
SSH ключи мы с тобой сделали, на сервере их прописали, надеюсь хорошо разжевал и ты проникся.

Но это еще не всё, сервер не готов запускать тебя по ключам. Сейчас это исправим.

Пиздуем на сервер под рутом, на тот самый куда ты закинул публичную часть ключа и открываем на редактирование файл /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

Скинул мне как-то давненько NPC свой ssh ключ, чтобы я прописал его на сервере. Смотрю я на этот ключик и понять не могу — ты блядь через что это сделал?

ssh-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).

Хотя лабиринт с простым числом (RSA) кажется меньше, его можно быстро решить с помощью методов, использующих факторизацию больших чисел.

А вот лабиринт с эллиптической кривой (ED25519) будет гораздо более сложным для прохождения, даже если его размеры кажутся меньше, потому что для нахождения решения требуется гораздо больше вычислений. Хотя ED25519 ключ меньше по размеру (256 бит против 2048 бит в RSA), его решение гораздо сложнее из-за самой природы криптографии.

🅰️🅰️

Есть еще ключи в формате ppk, это те ключи которые можно сгенерить с помощью ебанутого PuTTYgen.

Порой мне такие тоже скидывают, чтобы я их прописал. Но такие персонажи сразу идут — нахуй!

Чтобы сконвертить такой ppk в нормальный ключ openssh, в самой морде PuTTYgen нужно сделать экспорт:

"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

Вот сделал ты все как написано тут и тут и тут, сгенерил ключи и подготовил сервера, но сука все равно что-то какая-то шляпа:

Искал медь, обосрал медведь…

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

Такс, теперь в тему как отлаживать ssh подключения к серверу. К примеру ты все прописал и сделал как тут #linuxfactory, а оно все равно тебя не пускает по ключам.
ㅤ
Тут хочешь не хочешь нужен доступ к логам сервера к которому подключаешься. Так что заранее об этом побеспокойся, прежде чем перезапускать sshd службу.

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

Маунтишь корневой раздел и откатываешь конфиги. Заходишь в конфиги (/etc/sshd/) руками и просто откатываешь, то что ты там закомментировал.

Ладно, предположим у тебя есть доступ к руту и ты зашел на сервер.

Запускай команду:

tail -f /var/log/auth.log

Теперь открывай другой терминал и пробуй подключиться по ключам. После того как ты это сделал, возвращайся в терминал где запускал tail и внимательно смотри что тебе пишут.

В 100% там будет ошибка, которая элементарно гуглится. Обычно это просто проблемы с правами на файл ~/.ssh/authorized_keys или папку ~/.ssh/.

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

Распространенные ошибки:

Invalid user
bad ownership or modes for /home/<username>/.ssh
Authentication failed
Connection closed by remote host
Permission denied
Too many authentication failures
Connection refused
PAM authentication errors
User not allowed
Host key verification failed
SSH protocol mismatch
Banner errors
Brute-force attempts
Timeout
Subsystem errors
Resource temporarily unavailable

Не ссым читать логи и находить нужное. А как только нашел что-то вменяемое — гуглим или скармливаем GPT (как ты любишь).

Кстати китайцы тут DeepSeek запустили, мол убийца GPT. Бесплатная и работает в РФ без приколов. Домашку ребенку решать милое дело.

tags: #git #devops #ssh #linuxfactory
—
🔔 @bashdays➡️ @gitgate

Еще немного про отладку ssh ключей, но уже в контексте интеграции со всякими гитлабами/гитхабами.
ㅤ
Чтобы работать с приватными репами ты добавляешь в настройки гитлаба/гитхаба свою публичную часть ключа.

Хорошо если такой ключ один, запутаться особо негде.

Но что если добавлено 20-100 ключей?

Порой возникает ситуация, когда какой-нибудь раннер отказывается клонировать репу и начинает орать на доступы.

Ты проверяешь, видишь в табличке «Заголовок» — gitlab-runner-1 и вроде всё хорошо, ключ прописан и в раннере его приватная часть есть. Чо за хуйня?

Тут нам и пригодится команда:

ssh-keygen -l -E md5 -f ~/.ssh/id_rsa

Выполняем ее для ключа с которым подключаемся (работает и для приватной и публичной части одинаково).

И по итогу видим фингерпринт, отпечаток:

2048 MD5:03:62:23:ca:ce:1b:8c:ad:60:1f:66:16:05:43:d8:a7 shuba@server (RSA)

Сравниваем этот отпечаток с тем что прописан в гитлабе/гитхабе и видим что он НЕ совпадает.

А это значит что твой раннер использует не тот приватный ключ для подключения.

Фиксим и радуемся. Как фиксить? Прописать актуальную публичную часть ключа в гитлаб/гитхаб. Дело закрыто.

tags: #git #devops #ssh #linuxfactory
—
🔔 @bashdays➡️ @gitgate

Заголовок для привлечения внимания
ㅤ
А сегодня мы с тобой будем проверять на bash существует ли git репозиторий и есть ли к нему доступ.

В основе лежит команда git ls-remote, которая получает список ссылок (references) из удалённого репозитория.

Она показывает ветки, теги и другие указатели (refs), которые есть в репозитории, без необходимости клонирования или загрузки самого репозитория.

Сразу к делу:

#!/bin/bash

# Проверяем, что указан репозиторий
if [ -z "$1" ]; then
  echo "Ошибка: Необходимо указать адрес репозитория."
  echo "Использование: $0 <адрес_репозитория>"
  exit 1
fi

REPO_URL="$1"

# Выполняем команду git ls-remote для проверки доступа
if git -q ls-remote "$REPO_URL" &> /dev/null; then
  echo "Репозиторий доступен: $REPO_URL"
else
  echo "Ошибка: Репозиторий не существует или нет доступа: $REPO_URL"
  exit 1
fi

Переменная окружения GIT_TERMINAL_PROMPT=0 отключает любые запросы ввода имени пользователя и пароля. То есть если репа запросит логин/пароль, то вернется ошибка (без ожидания ввода).

Чмодим на +x и запускаем:

./git-check.sh https://github.com/bashdays/only.git

Репозиторий доступен: https://github.com/bashdays/only.git

./git-check.sh https://github.com/bashdays/zalupka.git

Ошибка: Репозиторий не существует или нет доступа: https://github.com/bashdays/zalupka.git

Есть минусы, скрипт работает только с https ссылками (открытые репозитории), со ссылками вида git@ оно вернет ошибку если у тебя не будет добавлен в ssh ключ.

Обработать этот эксепшен можно как-то так:

#!/bin/bash

# Проверяем, что указан репозиторий
if [ -z "$1" ]; then
  echo "Ошибка: Необходимо указать адрес репозитория."
  echo "Использование: $0 <адрес_репозитория>"
  exit 1
fi

REPO_URL="$1"

# Функция проверки доступа
check_repo_access() {
  local url="$1"
  
  # Проверяем репозиторий с помощью git ls-remote
  if git -q ls-remote "$url" &> /dev/null; then
    echo "Репозиторий доступен: $url"
    return 0
  else
    echo "Ошибка: Репозиторий не существует или нет доступа: $url"
    return 1
  fi
}

# Определяем, является ли URL SSH или HTTP/HTTPS
if [[ "$REPO_URL" == git@*:* ]]; then
  # Если SSH, проверяем доступ через SSH
  ssh_host=$(echo "$REPO_URL" | awk -F':' '{print $1}' | awk -F'@' '{print $2}')
  if ssh -T "$ssh_host" &> /dev/null; then
    check_repo_access "$REPO_URL"
  else
    echo "Ошибка: SSH-доступ к $ssh_host не настроен или нет прав."
    exit 1
  fi
else
  # Для HTTP/HTTPS проверяем репозиторий
  check_repo_access "$REPO_URL"
fi

Где применить решать тебе, можешь взять этот концепт за основу и что-то своё накидать.

У меня кое-где в пайплайнах есть такие проверки, перед тем как делается git clone. Ну и еще есть парсер репозиториев, загоняешь ему список и он по нему проходится, мертвые репы пишет в файл.

В общем обычная рутина. Я принес, показал, а ты уже сам решай надо оно тебе или нет.

tags: #bash #git
—
🔔 @bashdays➡️ @gitgate

GIT для девопс-инженера

Многих git пугает разнообразием команд, но 99% его функционала тебе никогда не пригодится. Это как MS Word или Excel, где ты используешь ну от силы 0000.1% всего задуманного в нём.
ㅤ
Да, разработчикам посложнее, надо разруливать мердж-конфликты, делать какие-то ебаные черепики и ребейзы. Но для программистов на yml, достаточно основной базы.

Стянул-закомитил-запушил. Не пушится? Похуй — push force!

Теорию по git опустим, ты и сам знаешь для чего оно всё нужно — для удобства.

Я к примеру в гите храню базу obsidian и совсем недавно это спасло все мои заметки. Я установил плагин для синка с seafile и оно мне нахуй всё стерло. У меня сука глаз выпал, овер 3к заметок проебало за секунду.

Но в гите у меня все это осталось, склонировал, восстановил. Бекап который однажды пригодился. Удобно.

К сути. Как я сказал выше, тебе достаточно базы:

git pull
git commit -m "ебал я вашу буравую, несите книжку трудовую"
git push

К этому можно еще добавить clone, checkout и init, но этим ты будешь пользоваться очень редко.

Как все работает в реальности

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

git clone git@git.bashdays.ru:shubin/obsidian.git

ВСЁ! Репа у тебя на руках.

Создаешь новую ветку от мастера:

git checkout -b 010825

И уже в нее говнокодишь. Когда говна достаточно, комитишь, делаешь пулл-реквест (мердж-реквест). После того как тимлид заапрувит твой реквест, правки вольются в мастер. А ветку 010825 можно закрывать.

Пункт с реквестами опять-же маловероятен, если компания не большая и ты там царь и бог девопса. Сразу хуяришь в мастер и никого не слушаешь. Отпадает необходимость создавать ветки и т.п. Ведь ты же всегда все делаешь идеально.

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

На этом можно и заканчивать, все элементарно. Не бойся гита, это хуйня не страшная. Если что-то пошло по пизде, удали, склонируй мастер и начни с чистого листа.

А как настроить ключи и т.п. я писал много постов, поищи по тегу #linuxfactory

А тут разбирали почему порой главная ветка называется main а не master.

🛠 #git #devops
—
✅ @bashdays ✅ @linuxfactory ✅ @blog