Здрасти приехали, пятница!

Частый вопрос который задают ребята с проекта Linux Factory:
ㅤ

Как в gitlab registry чистить докер имейджы, а то там такая пиздец блядь каша после экспериментов.

В gitlab есть встроенная херня, которая находится в Settings → Packages & Registries → Container Registry. Заранее не забудь выбрать нужный проект.

Там есть раздел: Cleanup Policies, в нём нажимаешь кнопку Set cleanup rules иии видишь еще кучу какого-то гавна.

Короче:

Run cleanup — выбираешь как часто запускать зачистку

Keep these tags — теги которые не нужно зачищать

Remove these tags — теги которые будем удалять

Remove tags older than — ну тут ежу понятно

В этих штуках работают регулярные выражения, примеры этих регулярок можешь глянуть тут.

Еще момент, если заполнить Keep these tags, то это даст протекцию тегам и даже если их прописать в Remove these tags имейджы не будут удалены.

Заполняешь, сохраняешь и оно автоматически будет тебе все подчищать.

✔ Дополнительные варианты зачистки:

- удаляешь мышкой в UI самого гитлаба
- удаляешь через API самого гитлаба (например баш скриптом)
- используешь утилиты типа regclient или docker-gc

Такие дела, надеюсь было полезно. Давай, хороших тебе предстоящих выходных и береги себя!

tags: #devops
—
🔔 ➡️

Еще раз привет. В последнее время многие столкнулись с проблемой при запуске пайплайнов в гитлабе.
ㅤ
Требуется какая-то ебучая Verify my account, квест который не так просто пройти. Но есть способ это обойти, спасибо за наводку Akhmed Gvashev.

Пиздуем в Settings → CI/CD → Runners → Instance runners и отключаем Enable instance runners for this project.

Всё, дело в шляпе. А дальше регистрируешь свои локальные раннеры и запускаешь пайплайны хоть до посинения.

Пользуйтесь!

tags: #devops
—
🔔 ➡️

Здрасти. Еще один частый вопрос с проекта Linux Factory:

Я собрал докер имейдж, а контейнер вечно в ребуте либо вообще не запускается, чо делать и как отлаживать?

Давай симулируем ситуацию и попробуем что-то с этим сделать.
ㅤ
Для начала соберем имейдж, это будет простой nginx + свой конфиг, который будет копироваться с локальной машины в имейдж.

Создаем на хостовой машине пару файлов:

Dockerfile:

FROM nginx:latest
WORKDIR /etc/nginx
COPY ./nginx.conf /etc/nginx/nginx.conf
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

nginx.conf

user  nginx;
worker_processes  1;

events {
    worker_connections  1024;
}

http {
    server {
        listen 80;
        server_name localhost;

        location / {
            return 200 'Hello, Docker!'
            add_header Content-Type text/plain;
        }
    }
}

Собираем имейдж:

docker build -t my-nginx .

Ждем, на экране бежит куча всякого непотребства. Это нормально. Ждем…

Проверяем:

docker images

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

REPOSITORY   TAG       IMAGE ID       CREATED          SIZE
my-nginx     latest    b844ef77daa3   33 seconds ago   188MB

Запускаем:

docker run -d -p 80:80 my-nginx

Проверяем:

docker ps

Хуй там плавал. Ничо не стартануло… ошибок нет, куда смотреть?

Если контейнер вообще не запускается, то для начала смотрим логи:

1. Узнаем состояние контейнера:

docker ps -a

Видим хуй с маслом: Exited (1) 4 minutes ago

2. Смотрим логи:

docker logs --follow <id or name>

В <id or name> подставляем айдишник либо имя контейнера:

В логах видим ошибку:

 invalid number of arguments in "return" directive in /etc/nginx/nginx.conf:15

Вот! С ней уже можно работать. Получается мы посмотрели логи, даже для незапущенного контейнера. Пиздуем в nginx конфиг и видим, что в 14й строке проебали точку с запятой.

Дополнительно можно посмотреть коды выхода:

docker inspect <id or name>

Например, если код выхода ExitCode = 137, значит не хватило ресурсов, подкинь памяти и все взлетит. Наверное…

Это основные моменты отладки.

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

docker exec -it <id or name> bash/sh

Подставляешь id/name контейнера и выбираешь шелл, частенько bash и коробки не установлен, поэтому как вариант запускаешь sh.

А для визуализации слоев используем утилиту dive

Установка dive:

DIVE_VERSION=$(curl -sL "https://api.github.com/repos/wagoodman/dive/releases/latest" | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/\1/')
curl -OL https://github.com/wagoodman/dive/releases/download/v${DIVE_VERSION}/dive_${DIVE_VERSION}_linux_amd64.deb
sudo apt install ./dive_${DIVE_VERSION}_linux_amd64.deb

Открываем имейдж на анализ:

dive <id or imagename>

Подставляем id или имя — ИМЕЙДЖА (не контейнера)

Смотрим, охуеваем, закрываем.

Еще можно глянуть конкретный файл в контейнере:

docker exec -it <id or name> cat /etc/nginx/nginx.conf

Либо скопировать его себе на локальную машину:

docker cp <id or name>:/etc/nginx/nginx.conf /tmp

Поправить и скопировать обратно в контейнер:

docker cp /tmp/nginx.conf <id or name>:/etc/nginx/nginx.conf

Перезапускаем контейнер с новым конфигом:

Прикол в том, что тебе не нужно билдить новый имейдж, ты делаешь правки прям в контейнере.

docker exec <id or name> nginx -s reload

Такие дела! Если знаешь еще хаки и способы отладки контейнеров/имеджей, пиши в комменты, будет полезно!

tags: #devops #debug #docker
—
➕ ➕

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

➡️ На примере облачного гитлаба:

Пиздуем в Проект → Settings → General → Visibility, project features, permissions → Project visibility
ㅤ
Выбираем из выпадающего списка: private, public, internal

Если у тебя облачный гитлаб с группами, читай дальше.

➡️ На примере Self-Hosted:

В отличии от облачного гитлаба, здесь недоступны варианты public, internal. Это многих смущает и вводит в ступор. Если коротко — сгорают жопы!

Открываем проект c репозиторием, вверху слева будет название группы, у меня оно linuxfactory и следом название проекта. Тыкаем на название группы, попадаем примерно на такой урл: https://git.bashdays.ru/linuxfactor

Нажимает три точки справа сверху появляется всплывашка, выбираем → Group Settings.

Находим: Visibility level и выставляем видимость группы public.

Пиздуем опять на страницу проекта с репозиторием → Settings → General → Visibility, project features, permissions → Project visibility

И о чудо! Активируются пункты public и internal.

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

Пользуйтесь!

tags: #devops
—
🔔 ➡️

Я тут решил поделиться впечатлениями. И хорошими и не очень. Вобщем, все в дом BashDays.

Недавно мне не дали премию за написание статей для BashDays. Сразу скажу, что на нее я не рассчитывал, поэтому охренел обрадовался и решил потратить ее на что-нибудь бесполезное, но приятно-интересное.
ㅤ
В общем, прикупил себе Безвентиляторный ПК Intel Celeron N2840 @ 2.16GHz 8Gb 128Gb 2 Lan 1Gb wi-fi Intel® Centrino® Advanced-N 6205. (далее писюк)

Проц выбрал именно такой из-за TDP 7W. На машине стояла Win10. Ну, я ее включил, залез на youtube. Измерил потребляемую мощность 12-15 Вт. Ну, короче, работать можно, если без претензий Корпус грелся, но я долго не работал. Снес.

Поставил pfsense. Установилась легко. Работает шустро. Но я не смог поднять точку доступа WI-FI. Интерфейс поднимается, но режим точки доступа не доступен. Немного погуглил, народ пишет, что pfsense и wi-fi AP не очень дружат, и рекомендуют просто купить дрочку доступа. Ой, как забавно опечатался. Даже исправлять не буду. Снес.

Поставил debian 12. Затем hostapd, dnsmasq, iptables. В общем, точка доступа поднялась с танцами и бубном, но, проверка скорости с помощью iperf3 показала, что ноут с этой точкой доступа работает на скорости около 35-37 Мбит/с.

Между тем, мой старичек keenetic 4G (KN-1210) RU выдает 80-90 Мбит/с. И это включая интернет канал до Нидерландов. В общем, полное разочарование. Да, это на 2.4 ГГц. На 5 мне попробовать было нечем. Снес.

После этого решил на пробу установить ipfire. Дистрибутив, специально заточен для периметрового маршрутизатора, но по функционалу, который можно доставить очень напоминает openwrt. (C самой openwrt я знаком чисто теоретически).

Про ipfire раньше никогда не слышал, прям сегодня почитал, и решил попробовать. Знаете, впечатление очень даже ничего. Ставится просто, web-интерфейс довольно удобный. (За исключением правил firewall. Но это я после pfsense такой привередливый:-)

Порадовала документация на сайте. Все очень простым английским языком. Да, один косяк. При установке, вначале указал язык русский и после перезагрузки в инсталляторе все тексты были квадратиками. Что-то парни со шрифтами намудрили.) Пришлось переставлять. Поставил, поднял точку доступа с пол-оборота, замерил скорость - 35-37Мбит/с. Грешу на wi-fi адаптер.

Заменить полноценно Keenetic не получилось. Да, из самого неприятного, писюк греется. Я пробовал поставить частоты по минимуму, производительности хватает, но все равно греется, хотя и значительно меньше.

Для проца температура совсем ерундовая, но для ссд и материнки условия не очень комфортные. Видимо придется колхозить вентилятор, тем более отверстия под 60мм есть.

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

tags: #рабочиебудни © by Tagd Tagd
—
🔔 ➡️

Хелоу мая диа френдз! Я повидал дохуя bash скриптов по зачистки старых бекапов, какие-то работают заебись, какие-то создают лишь видимость.
ㅤ
Заебись когда бекапы у тебя лежат на той же машине где ты их делаешь.

Запускаешь по крону команду rm и паре с find и зачищаешь ненужное гавно которое старше определенного времени.

А чо делать когда бекапы «правильно» заливаются в облако s3 по протоколу swift?

Там find с rm уже не прокатит. Можно конечно изгаляться, но я в рот ебал изобретать очередной велосипед.

Для этих целей отлично подходит rclone, кто бы блядь мог подумать.

Работает так:

/usr/bin/rclone --config ~/.config/rclone/rclone.conf \
--log-file /var/log/rclone-trasher.log \
-v delete selectel:backups/1c/ --min-age 3d --rmdirs

Показываем где лежит конфиг, конфиг представляет нечто такое:

[selectel]
type = swift
env_auth = false
user = bashdays
key = fuckyou
auth = https://auth.selcdn.ru/
endpoint_type = internal

Пишем непотребства в лог файл, чтобы потом посмотреть что там в кроне навыполнялось.

Указываем где чистим бекапы, задаем сколько бекапов нам оставить, в примере я оставляю за 3 последних дня. Бекапы у меня в каталогах по датам, добавляю ключик rmdirs.

Вешаем на крон и идем дальше работать пинать хуи.

По моему отличное решение, и даже думать не пришлось.

Пользуйтесь на здоровье!

tags: #devops
—
🔔 ➡️

Здрасти. К делу!

Гиту откровенно насрать на права доступа файлов. И после клонирования репы, эти права будут установлены по umask пользователя.
ㅤ
Ситуация не критичная, но иногда случаются моменты когда нужно все эти права сохранить и после клона восстановить.

На помощь приходит костыль, всё в лучших традициях!

#!/bin/bash

find . -type f -exec stat --format='%a %n' {} \; > permissions.txt
git add permissions.txt
git commit -m "на залупе лешего вертели"
git push

Пробегаемся по всем файлам и каталогам, записываем текущие права в файл permissions.txt, коммитим, пушим.

Ну и скрипт для восстановления прав:

#!/bin/bash

if [ -f permissions.txt ]; then
  while read perm file; do
    if [ -f "$file" ]; then
      chmod "$perm" "$file"
    fi
  done < permissions.txt
fi

Вот и вся наука. По желанию вешаешь это на Git Hook (post-checkout, post-merge) и автоматизируешь.

Как автоматизировать писал в этом посте, на примере можешь адаптировать.

А еще есть git-restore-mtime, для восстановления метаданных времени модификации файлов.

Такие дела, изучай…

tags: #linux #bash
—
🔔 ➡️

Богатствуйте!

И снова полезный пост! Тунеядцев прошу расслабить жопы и перейти к концу, там анекдот.
ㅤ
Меня часто спрашивают… Нет, всем похуй. Короче:

systemctl restart php-fpm

Unit php-fpm.service could not be found.

Хм, я точно знаю что php на сервере есть! Так какого чернослива?

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

В примере выше, php сервис называется: php8.2-fpm-fuck-you!

Ха! В жизни не догадаешься.

Первым делом пиздуем в:

history | grep php

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

Если не повезло делаем так:

systemctl | grep php

php8.2-fpm-fuck-you.service
phpsessionclean.timer

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

Можно конечно воспользоваться внешними утилитами, но не рекомендую. Потому что systemctl есть всегда, а внешних утилит - нет.

➡️ Сразу привыкай работать с инструментами из коробки и будет тебе счастье.

Все!

Ну и анекдот как обещал: еслиб у бабушки был бы хуй, она была бы дедушкой.

tags: #linux #debug
—
🔔 ➡️

«Группа Астра» проводит первую бесплатную практическую конференцию для разработчиков Astra DevConf 2024.

Разработчики ИТ-компаний раскроют секреты эффективной и безопасной разработки, а также поделятся практическими кейсами.

На конференции мы:
— расскажем как выстроить процесс разработки на базе Git-системы (конкретные примеры на различных языках и фреймворках);
— покажем, как легко и просто опубликовать ваше приложение в RuStore;
— поделимся лучшими практиками в построении DevOps-процессов для проектов, написанных на Spring Framework и Java/Kotlin;
— расскажем, как осуществить сборку из Dockerfile или Buildpack и развертывание образа на виртуальной машине (пока вы пьете кофе);
— и многое другое.

Для участников конференции будет доступен:
— личный кабинет разработчика, в котором можно бесплатно скачивать решения «Группа Астра» для целей изучения и разработки (в том числе ОС Astra Linux 1.8);
— портал с документацией, где опубликованы различные инструменты для разработки, примеры кода и готовые стенды д...

Аутентификация, авторизация. Навеяло.

Есть два вида запоминания паролей - хранение и связанная генерация. Это когда ты вводишь логин, а программа на основании его и модификатора (соли) вычисляет пароль.
ㅤ
Хранить лучше в программах типа keepass и аналогах. Сейчас затронем тему генерации.

Есть такая известная программа как pwgen. Просто чудесная. Столько всего умеет. В том числе и связывать логин и пароль. Проблема только в том, что при генерации командная строка может попасть в history.

И пароль может быть немного скомпрометирован. Я написал для нее небольшую обертку, которая, как мне кажется, решает эту проблему.

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

Модификатор - это что-то типа парольной фразы при использовании ключа.

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

Ключевой файл тоже желательно сохранять в нескольких местах, поскольку при утрате восстановить пароль будет невозможно.

Модификатор может набираться с клавиатуры видимом и скрытом режимах. Все зависит от агрессивности коллектива.

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

Да, совсем забыл, параметр PWGEN_OPT - дополнительные опции генерации пароля НЕЛЬЗЯ менять после начала эксплуатации программы.

Программа pwgen должна быть установлена.

Для debian sudo apt install pwgen

declare -r PWGEN_OPT='-1 --symbols --ambiguous --capitalize'
declare -r PASSLEN=15
declare -r PASSNUM=5
declare -r KEYFILE=${0%/*}/'1.jpg'
declare -l HIDDENMOD=0
declare -r PWGEN=$(which pwgen)
declare LOGIN
declare MOD MOD1

if [[ ! "$PWGEN" ]];then
  echo pwgen not installed
  exit 1
fi
if [[ ! -s "$KEYFILE" ]];then
  echo keyfile "$KEYFILE" not found
  exit 2
fi
read -p "Input login:" LOGIN
if [[ "1y" =~ "$HIDDENMOD" ]];then
  read -s -p "Input modificator:" MOD;echo
  read -s -p "Confirm modificator:" MOD1;echo
  if [[ "$MOD" != "$MOD1" ]];then
    echo "Modificator not confirmed"
    exit 3
  fi
else
  read -p "Input modificator:" MOD;echo
fi
echo pwgen options: $PWGEN_OPT
echo  "Login: $LOGIN" 
$PWGEN $PWGEN_OPT  -H"${KEYFILE}#${LOGIN}${MOD}" $PASSLEN $PASSNUM

сохраняем в файл passgen.sh

chmod +x passgen.sh
./passgen.sh

По умолчанию ввод модификатора отображаемый. Для параноиков - установить HIDDENMOD=1 результат работы примерно такой:

Input login:tagd.ru
Input modificator:BashDaysTheBest

pwgen options: -1 --symbols --ambiguous --capitalize
Login: tagd.ru
aig3ohkie.Wah4X
AiguW~u7vohphae
eiJa7ahxei.die!
FaeNa=phah9voh3
Kih]ahca3Hie7ke

Если повторить ввод тютелька в тютельку пароли будут те же самые, что и требовалось.

➡️ Тыкни сюда, чтобы посмотреть описание работы программы.

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

Почитать:

help declare read
man pwgen
https://cheatsheets.zip

tags: #bash #linux © by Tagd Tagd
—
🔔 ➡️

Порой бывает необходимо прям из bash-скрипта добавить/удалить какое-нибудь задание в cron.
ㅤ
Ниже пара функций, которые позволяют это сделать. И если с добавлением вообще проблем не возникает

{ crontab -l; echo '# echo BashDays >/tmp/BashDays.txt' ; }| crontab -

ИЛИ:

{ crontab -l; echo '#*/10 * * * 5 echo BashDays >>/tmp/BashDays.txt' ; }| crontab -

Можно конечно и так, но вдруг одинаковых заданий может быть несколько и их нужно будет как-то различать.

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

#!/bin/bash

function ADD_CRON_TASK(){
  local CRON_TASK=${1:-'#'}
  local COMMENT=${2:-$(date +%s)}
  COMMENT=${COMMENT// /_}
{ crontab -l 2>/dev/null; echo "$CRON_TASK #$COMMENT"; }| crontab -
}

function REMOVE_CRON_TASK(){
  if [[ $# -eq 0 ]];then
    echo No comment to remove cron task >&2
    return
  fi
  COMMENT=${1// /_}
  crontab -l 2>/dev/null|sed '/#'$COMMENT'$/d'|crontab -
}

CRON_TASK='# reboot'
COMMENT="My litle joke"
ADD_CRON_TASK "$CRON_TASK" "$COMMENT"

crontab -l|tail -3

echo '###################################################'
REMOVE_CRON_TASK "$COMMENT"
 
crontab -l |tail -3

Если запустить программу, увидите что-то типа:

# 
# m h  dom mon dow   command
#  reboot #My_litle_joke
#############################
# For more information see the 
# 
# m h  dom mon dow   command

Видно, что программа добавила задание, вывела последние три строки crontab'a, потом разделитель.

Затем задание было удалено. Это видно по последним трем строкам.

В комментариях задания пробелы заменяются на "_" для упрощения работы c sed.

Ну, и на всякий пожарный напомню, что для корректной работы с cron нужно задать переменную PATH либо в crontab, либо в скрипте.

tags: #bash #linux © by Tagd Tagd
—
🔔 ➡️

Привет. Почему-то я думал что сегодня пятница, мда…
ㅤ
Ладно, поехали. Ты всяко встречался с такой ебаной ошибкой при подключении к серверу по ssh:

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

Please contact your system administrator. Add correct host key in /home/your_user/.ssh/known_hosts to get rid of this message. Offending RSA key in /home/your_user/.ssh/known_hosts:xx

У меня коллеги обычно сразу прибегают и начинают подозревать неладное — ааа спасите, сервер взломали, не могу подключиться! Паникёры блядь…

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

Чо за ошибка и что нужно делать?

Файл ~/.ssh/known_hosts используется для хранения списка хостов, с которыми ты ранее взаимодействовал по ssh.

Когда ты впервые подключаешься к новому удалённому серверу по ssh, клиент ssh сохраняет его ключ в этот файл.

В дальнейшем, при каждом подключении к этому серверу, ssh-клиент сверяет ключ сервера с тем, что хранится в файле known_hosts.

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

Короче вся эта чача сделана для безопасности, чтобы избежать анальной атаки — «мужик посередине».

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

Открываем свой локальный /etc/ssh/ssh_config или ~/.ssh/config и херачим в него такое:

Host * 
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null

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

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

Ну а если лень править конфиги, можешь прям из командной строки передавать эти ключи:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user

Либо сделать алиас:

alias ssh = "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null"

А если всё делать по уму и остерегаться «мужика посередине»:

1. Наводим справки, что случилось с сервером у админов
2. Если все ок, делаем так: ssh-keygen -R <hostname_or_ip>

После этой команды, файл known_hosts подчиститься и ошибка отправится в пешее эротическое.

Чо тебе еще рассказать? Особо больше нечего по этой теме.

А если тебе есть что добавить — велком в комментарии.

Давай краба! Завтра надеюсь точно пятница…

tags: #linux
—
🔔 ➡️

У меня возникла проблема. Мне нужно переконфигурировать сеть на железном сервере, который находится в другом городе. И командировка туда займет пару дней.
ㅤ
Проблема усугубляется тем, что на сервере нет ipmi или аналогов, кроме того, в окружении нет админа. Поэтому конфигурировать сеть нужно по ssh.

Надеюсь никому здесь не нужно объяснять, чем это грозит. В общем, прикинул я хрен к заднице, что можно сделать и написал скрипт.

Скрипт поможет в случае чего восстановить конфигурацию, в случае моего косяка.

Алгоритм работы следующий:

0. Есть работающий сервер.

1. При запуске создается резервная копия защищаемого каталога конфигурации /etc

2. В crontab добавляется задание, которое через определенное время ПОСЛЕ ПЕРЕЗАГРУЗКИ восстановит каталог из копии.

3. Если вышеуказанное задание определит, что в систему по ssh вошел указанный пользователь, восстановление отменяется и задание из crontab убирается.

4.Если пользователь не смог войти в систему - сначала создается вторая резервная копия защищаемого каталога (на тот случай, если сконфигурировали все правильно, но забыли/не смогли войти из-за проблем на вашей стороне, ну и для анализа), после этого производится восстановление резервной копии из пункта 1, убирается задание из crontab и производится перезагрузка сервера. Сервер приведен к пункту 0.

Пользоваться этой цацой просто:

1. ПЕРЕД НАЧАЛОМ КОНФИГУРИРОВАНИЯ запускаем скрипт, Он запрашивает имя пользователя и время ожидания до восстановления ПОСЛЕ ПЕРЕЗАГРУЗКИ.

2. Конфигурируем сервак.

3. Отправляем сервак в перезагрузку. (Да, не лучший вариант, но по сравнению с командировкой фигня).

4. Пытаемся войти по ssh.

По ssh мы войдем в любом случае. Или быстро (если сервак сконфигурировали правильно) или по окончании времени ожидания и перезагрузки.

Обращаю внимание - если пользователь смог войти в систему - Сервер считается работоспособным, задание из cron убирается.

И если вы решите что-то снова поконфигурировать - нужно снова запускать скрипт и один-два раза перезагружать сервак. Лучше составьте план действий.

Скрипт тестировался на debian путем удаления каталога /etc/network

Используйте скрипт под свою ответственность. Гарантировать, что он заработает на вашей системе я не могу. Для начала попробуйте защить какой-нибудь каталог в домашней директории.

Скрипт не сможет восстановить конфигурацию, если машина не грузится совсем (ну, например грохнули fstab)

На Alpine точно не работает по двум причинам:

1. crontab не понимает опцию (проблема решаемая через /etc/inid.d)

2. по умолчанию не работают команды last, who, w. Поэтому несколько проблематично определить наличие пользователя в системе.

➡️ Скрипт в комментариях к этому посту, сюда не влез сука!

tags: #bash #linux © by Tagd Tagd
—
🔔 ➡️

Здрасти. Давай сегодня соберем свой «мета-пакет».

Что такое «мета-пакет»? Нууу…
ㅤ
Например, я хочу разом поставить htop, git, rclone, mc и прочее. И чтобы не вводить команду на установку:

apt install htop git rclone mc

Я могу поставить один «мета-пакет», который будет содержать в себе все эти утилиты. Что-то из оперы Zver DVD, где нужный софт ставился сразу пачкой.

Поехали тыкать палкой!

Ставим зависимости и готовим окружение:

sudo apt-get install -y build-essential devscripts dh-make

Создаем структуру для «мета-пакета»:

cd /tmp
mkdir bashdays-soft
cd bashdays-soft

Создайте контрольные файлы пакета:

dh_make --native --single --yes -p bashdays-soft_1.0

Ключи:

native — создаёт пакет без указания версии дистрибутива
single — создаёт минимальную структуру
-p my-metapackage_1.0 — имя пакета и версия (1.0)

В ответ получаем выхлоп:

Maintainer Name : root
Email-Address : root
Date : Sun, 29 Sep 2024 03:58:22 +0000
Package Name : bashdays-soft
Version : 1.0
License : gpl3
Package Type : single

Открываем файл на редактирование:

vim debian/control

И хуячим описание для «мета-пакета»:

Source: bashdays-soft
Section: misc
Priority: optional
Maintainer: Roman Shubin <hello.ru>
Standards-Version: 4.5.0
Build-Depends: debhelper-compat (= 11)

Package: bashdays-soft
Architecture: all
Depends: mc, htop, curl, git
Description: My own Installer

В секции Depends перечислены все пакеты, которые должны быть установлены вместе с мета-пакетом. У меня это mc, htop, curl, git.

Параметр Architecture: all указывает, что пакет не зависит от архитектуры.

Собираем «мета-пакет»:

debuild -us -uc

Ключи -us и -uc отключают подпись пакета.

Смотрим что получилось:

ls -la ..

И видим:

bashdays-soft_1.0.tar.xz
bashdays-soft_1.0_all.deb

Наш «мета-пакет готов». Давай теперь его установим и посмотрим что получилось:

sudo apt install -yf ../bashdays-soft_1.0_all.deb

Проверяем и видим что произошла установка всех пакетов которые я описал в секции Depends в файле debian/control. ЗБС!

Проверить можно так:

dpkg -l mc htop curl git

В ответ получишь красивую табличку и информацию о пакетах.

Теперь можешь приготовить свой собственный «мета-пакет» со всем необходимым и быстренько раскатывать его на новые сервера.

Темка достаточно интересная, поэтому рекомендую потыкать.

Пользуйтесь!

tags: #linux
—
🔔 ➡️

Принцесса для снятия стресса

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

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

<прилагательное><фамилия> и всегда написаны в нижнем регистре.

Например:

quirky_pare
agitated_turing
furious_heisenberg
romantic_curie

Окей. После некоторого ресёрча оказалось, что 90% докера написано на Golang. Вот это поворот!

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

➡️ Посмотреть можешь тут.
ㅤ
Мотаем этот код в самый низ и видим забавную хуйню:

if name == "boring_wozniak" /* Steve Wozniak is not boring */ {
    goto begin
  }

Этакая пасхалочка. Но зачем все эти имена?

Да чтобы удобнее было манипулировать контейнерами, вот и вся идея этой возни.

Ну и на закуску адаптируем полученные знания на bash, генератор может выглядеть так:

#!/bin/bash

adjectives=(
  "adoring" "agitated" "amazing" "angry" "awesome" "blissful" "bold"
  "boring" "brave" "clever" "cool" "compassionate" "competent" "crazy"
  "dazzling" "determined" "ecstatic" "elegant" "eloquent" "epic"
  "exciting" "fervent" "focused" "furious" "gallant" "gifted" "goofy"
  "gracious" "happy" "hardcore" "hopeful" "hungry" "infallible" "inspiring"
  "jolly" "jovial" "keen" "kind" "laughing" "loving" "magical"
  "mystifying" "naughty" "nervous" "nostalgic" "optimistic" "peaceful"
  "practical" "priceless" "quirky" "recursing" "relaxed" "reverent"
  "sad" "serene" "sharp" "silly" "sleepy" "stoic" "strange" "stupefied"
  "suspicious" "tender" "thirsty" "trusting" "unruffled" "vibrant"
  "vigilant" "wizardly" "wonderful" "youthful" "zealous" "zen"
)

scientists=(
  "albattani" "allen" "archimedes" "ardinghelli" "babbage" "bashdays" "banach"
  "banzai" "bardeen" "bartik" "bassi" "bell" "benz" "bhabha" "bhaskara"
  "blackwell" "bohr" "booth" "borg" "bose" "boyd" "brahmagupta" "brattain"
  "brown" "carson" "chandrasekhar" "colden" "cori" "cray" "curie"
  "darwin" "davinci" "dijkstra" "dubinsky" "easley" "einstein"
  "elion" "engelbart" "euclid" "euler" "fermat" "fermi" "feynman"
  "franklin" "galileo" "galois" "goldberg" "goodall" "hawking"
  "heisenberg" "hermann" "herschel" "hertz" "hodgkin" "hoover" "hopper"
  "hypatia" "joliot" "kalam" "keller" "kowalevski" "lalande" "leavitt"
  "lichterman" "liskov" "lovelace" "mayer" "mccarthy" "mcclintock"
  "mclean" "mcnulty" "meitner" "mendel" "mendeleev" "minsky" "mirzakhani"
  "moore" "napier" "newton" "nobel" "noether" "panini" "pare"
  "pasteur" "payne" "perlman" "pike" "poincare" "ptolemy" "raman"
  "ramanujan" "ride" "ritchie" "roentgen" "rosalind" "saha"
  "sammet" "shockley" "sinoussi" "stallman" "stonebraker" "swanson"
  "tesla" "thompson" "torvalds" "turing" "varahamihira" "visvesvaraya"
  "wilbur" "wiles" "williams" "wilson" "wing" "wozniak" "wright"
  "yonath"
)

generate_container_name() {
  local adjective="${adjectives[RANDOM % ${#adjectives[@]}]}"
  local scientist="${scientists[RANDOM % ${#scientists[@]}]}"
  echo "${adjective}_${scientist}"
}

count=${1:-10}
for ((i=1; i<=count; i++)); do
  generate_container_name
done

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

Теперь ты в праве заполнить массивы своими данными и генерировать уникальные имена, например: pizdatiy_huy или ohuennaya_pizda.

А потом использовать сразу в командах:

docker run --name $(bash script.sh) -d nginx

Есть еще такая штука:

alias dn='curl -s https://frightanic.com/goodies_content/docker-names.php'

Это выплюнет тебе подобное имя прям в консоли без скриптов и приседаний.

А еще есть библиотека на питоне — codenamize, которая проворачивает тоже самое.

Короче есть из чего выбрать. В общем пользуйся, прикручивай, изучай!

tags: #linux #bash #docker
—
🔔 ➡️

✊ С пятницей ребят!

Недавно пришло письмо от мейл.ру мол у вас SPF запись пиздец хуёвая.

SPF-запись домена https://bashdays.ru задана таким образом, что для ее проверки необходимо 36 DNS-запросов из 10 допустимых.

Я человек простой — вижу хуйню, прохожу мимо. Но тут пройти не смог, какой-то животный интерес возник. Что это еще за 10 допустимых запросов?

Проресерчив тему, нашел сервис SPF Surveyor который как раз анализирует текущую SPF запись и выводит результат.

➡️ Рекомендую добавить сервис в закладки, для дебага самое оно!

От результата я знатно прихуел, вот моя SPF:

v=spf1 mx a include:spf.gca.to include:_spf.google.com include:spf.smtp.bz include:mindbox.ru ~all

И результат: 36/10

И чо мне с этим делать? Для начала убрал mx и a, по итогу получил результат: 18/10. Уже лучше, поехали дальше оптимизировать!

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

Перегуглил… нииихуууя!

И как это дерьмище сокращать? Если каждый инклуд содержит в себе еще сабинклуды. Сука!

Короче пост не про решение проблемы, а про сервис SPF Surveyor.

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

Такие дела…

tags: #рабочиебудни
—
🔔 ➡️

Начало месяца - время делать бэкапы. О бэкапах уже столько сказано, что еще одна статья ничего нового не добавит, но тем не менее позволю себе поделиться своим опытом.
ㅤ
Сразу скажу, что не бывает правильных и неправильных схем архивирования. Бывают те, которые подходят для вашей задачи и не подходят.

Пока мой архив был меньше 10 Тб, я не понимал, нахрена нужны инкрементные копии? А у кого-то петабайты...

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

Инфраструктуру можно поднять - это вопрос времени, но есть данные, которые нарабатывались несколько лет, и именно их потеря может быть очень критичной.

И из этого следует, что СХД для архивов должна быть самым защищенным элементом инфраструктуры. Очень хорошо, если на эту машину нельзя попасть никаким способом, кроме физического доступа.

Кроме этого. СХД - тоже компьютер, поэтому тоже может выйти из строя. Поэтому необходимо хранить данные еще и отдельно на внешних дисках.

Причем дисков должно быть минимум два с чередованием (месячным, недельным, ежедневным не важно, но чередование должно быть). Кроме того, есть холивар, по поводу того, кто должен быть инициатором соединения при архивировании - СХД или рабочий сервер.

Просто подумайте, кто больше подвержен атаке клиент или сервер. Конечно сервер. Поэтому для обеспечения минимальной безопасности архивов инициировать соединение должна СХД.

Я для себе решил вопрос с помощью "перевалочной базы" - Машины, на которую сервера сваливают одну дневную копию, и с которой СХД забирает все архивы.

Т.е. и рабочие сервера и СХД в этой схеме являются клиентами. Дело в том, что хорошо защитить один перевалочный сервер проще, чем каждый рабочий сервер.

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

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

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

Ну, и остался вопрос именования архивов. Кто-то использует даты в имени и удаляет по устареванию. Я использую цифры и провожу ротацию по одному файлу за раз. Потому что в случае атаки на сервер времени дата-именованные архивы можно потерять за раз.

Для нумерованных архивов для атаки - дату нужно менять несколько раз.

Причем число раз будет зависеть от схемы.

В общем резюмирую:

1. Хороших и плохих схем архивирования не существует - есть такие, которые подходят вам и не подходят.
2. СХД - самая защищенная машина инфраструктуры. Без возможности управления по сети.
3. Есть внешние копии с чередованием, на случай выхода из строя СХД.
4. Архивные копии между СХД и сервером передаются через промежуточную машину.
5. Несколько дневных копий можно ДОПОЛНИТЕЛЬНО хранить на самом рабочем сервере.
6. Используем нумерованные архивы с ротацией.

Холивар в коммментах приветствуется.

tags: #рабочиебудни © by Tagd Tagd
—
🔔 ➡️

Не ssh, но близко — sftp.

Классная вещь, со своими достоинствами и недостатками. Гораздо круче, чем scp, поскольку кроме копирования позволяет управлять правами доступа.
ㅤ
По сравнению с ftp - возможность работы через один порт (легко пробрасывается) Протокол защищенный.

Из минусов - может создавать нагрузку на проц. В openssh включен из коробки. Поэтому если есть доступ по ssh - как правило, есть доступ и по sftp.

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

Вот, для этого есть решение — mysecureshell.

Для debian можно поставить:

sudo apt install mysecureshell

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

Возможностью ограничить пользователя только своим каталогом. И еще работа с виртуальными серверами. Рекомендую.

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

cat /etc/shells

А изменить, например так:

sudo usermod -s /usr/bin/mysecureshell username

Конфигурируется данное чудо путем редактирования файла /etc/ssh/sftp_config

Кстати, отлично сочетается с sshfs (монтирование через ssh (по факту через sftp)).

А вот с rsync, говорят не дружит, но я лично не проверял. Приводить примеры конфигурирования не стал, потому что там все очень понятно и прозрачно. Документация приличная, сам конфиг очень классно комментирован.

Репа Mysecureshell
Документация

tags: #linux #utilites © by Tagd Tagd
—
🔔 ➡️