Многие догадываются, а некоторые точно знают на каких онлайн-сервисах можно посмотреть принадлежность домена или IP организации. Я для этого использую программу whois.

apt install whois
whois 164.92.216.105

Использовать whois в скриптах не рекомендую, потому что для этого, во-первых, есть специальные базы, а во вторых - забанят.
ㅤ
Поверьте, я знаю о чем говорю. И иногда бывает так, настроение утром испорчено, и какой-то хостер тебя ну совсем задолбал и хочется просто взять и забанить его целиком, смотрим вывод:

NetRange:164.92.64.0 - 164.92.255.255
CIDR:164.92.128.0/17, 164.92.64.0/18

Во, здесь повезло заполнено поле CIDR. Можно забанить 164.92.128.0/17 и 164.92.64.0/18 и все будет хорошо, но так бывает не всегда.

whois 114.199.33.115
inetnum: 114.199.0.0 - 114.199.63.255

Поле CIDR отсутствует, есть только inetnum: И то хлеб. Как преобразовать NetRange или inetnum в формат CIDR, ведь iptables не понимает диапазоны ip адресов. Ему подсети подавай (CIDR).

Для этого воспользуемся калькулятором ipcalc. Вообще-то я предпочитаю sipcalc, потому что он бинарный и работает быстрее, но функции разбивки диапазона ip адресов у него нет. Что-то я отвлекся.

apt install ipcalc
ipcalc -r 164.92.64.0 - 164.92.255.255

#вывод
deaggregate 164.92.64.0 - 164.92.255.255
164.92.64.0/18
164.92.128.0/17

ipcalc -r 114.199.0.0 - 114.199.63.255

# вывод
deaggregate 114.199.0.0 - 114.199.63.255
114.199.0.0/18

Итого: с помощью ipcalc -r можно разбить любой непрерывный, даже самый безумный, диапазон ip адресов на подсети в формате CIDR, и количество этих подсетей будет не более 32.

В качестве поиграться предлагаю разбить диапазоны 127.0.0.1-192.168.1.1 или 0.0.0.1-255.255.255.254 Вот только банить их не нужно. А вот разбивать диапазон 0.0.0.0 255.255.255.255 не рекомендую, а почему не скажу. Кто еще какими сетевыми калькуляторами пользуется?

man whois
man ipcalc

tags: #networks © by Tagd Tagd
—
🔔 @bashdays➡️ @gitgate

Всем привет. Опять в чате заговорили про СХД и кое-то вспомнилось.

Когда-то я занимался вопросом выбора дисков для серверов и мне стало интересно, почему диски для корпоративных систем стоят так дорого?
ㅤ
Начал читать статьи и сравнивать характеристики. Нашел старую статью, где говорилось, что один инфогигант в рейдах использует диски wd-blue, мол так дешевле получается.

Да, дешевле. Но при этом нужно отдавать себе отчет, что ты делаешь, как и к чему это может привести.

Для начала сравним ОДИН параметр нескольких ssd и hdd дисков: Конкретно Неисправимых ошибок чтения/прочитанных бит.

sata hdd wd-blue 1Tb (WD10EZEX)=1 ошибка на 1E14 бит
sata hdd wd-gold 1 Tb(WD1005FBYZ)=1 ошибка на 1E15 бит
sas hdd Toshiba 900 Гб (AL15SEB090N) 10 ошибок на 1E17 бит
sata ssd Micron 960 Гб (MTFDDAK960TDS-1AW1ZABYY)1 ошибка на 1E17бит

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

Короче, вероятность считать битый шифрованный архив с WD-GOLD в 10 раз меньше, чем с WD-BLUE и в 100 раз c Toshiba, и в 1000 раз меньше с ssd Micron.

Хочу так же обратить внимание на Проникновение долбанных маркетологов Toshiba в тех. описание. 10 ошибок на 1E17 бит РАВНО 1 ошибок на 1E16 бит.

А еще, приличные производители sas-дисков честно говорят о зафиксированных ошибках. Информацию можно глянуть командой из пакета smartmontools

sudo smartctl -a /dev/sdXX

#смотреть после Error

Конечно, для хранения можно использовать и wd-blue, но только с применением специальных файловых систем с контрольными суммами, или применением форматов хранения файлов с избыточностью (типа платный rar).

Кстати, не все рейды справятся с такой ошибкой. Большинство рейдов (0,1,5,10) защищают от поломки диска, но не от неправильного чтения.

6 - вроде бы считает контрольные суммы для каждой записи и корректирует, если что (поправьте если не прав).

Ну, и рейдовые zfs решают проблемы, поскольку содержат контрольные суммы файлов.

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

tags: #hardware © by Tagd Tagd
—
🔔 @bashdays➡️ @gitgate

Если взглянуть на картинку выше, то в этом списке ты не найдешь сигналов с номером 32 и 33. Список сформирован командой kill -l.

И куда же блядь эти сигналы делись?

А всё просто, сигналы с номерами 32 и 33 в современных линукс дистрибутивах зарезервированы для использования библиотекой glibc. И используются для реализации механизма потоков (threads).

Исходник glibc где он резервирует эти сигналы. Можешь увидеть что они будут не обязательно 32 и 33.

22 static int current_rtmin = __SIGRTMIN + 2;
23 static int current_rtmax = __SIGRTMAX;

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

Сигналы же начинающиеся с номера 34 называются — сигналами реального времени. Более подробно про сигналы реального времени можешь почитать тут.

Если попытаться отправить сигнал 32 или 33 вручную процессу, то получишь хуй с маслом. Ядро эти сигналы обрабатывать не будет.

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

kill -32 10929

Unknown signal 32

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

#include <stdio.h>
#include <signal.h>

int main() {
    printf("SIGRTMIN: %d\n", SIGRTMIN);
    printf("SIGRTMAX: %d\n", SIGRTMAX);
    return 0;
}

Скомпилировать и запустить:

gcc -o signals signals.c
./signals

В ответ ты получишь что-то подобное:

SIGRTMIN: 34
SIGRTMAX: 64

Test Passed! Сигналы реального времени начинаются с 34. Но опять же не факт, что в твоём дистрибутиве будет так же. Мож ты всё еще на Slackware сидишь.

А нахуя нужны сигналы реального времени?

Давай лучше завтра, сегодня мы разбирались куда делись сигналы 32 и 33. Не хочу раздувать этот пост и пугать тебя раньше времени СИськастым кодом.

Увидимся!

про сигналы писал ранее тут и тут и тут

tags: #linux
—
🔔 @bashdays➡️ @gitgate

Не одевай 3.14зду в лапти, она и так смешная
ㅤ
Такс, давай покончим с сигналами реального времени (СРВ) и выйдем на новый уровень написания Bash скриптов, мыж с тобой уже взрослые.

Вчера мы выяснили СРВ имеют условный индекс 34-64 (в разных дистрибутивах может быть по-разному, проверяй)

Где их применять?

Давай глянем на примере. СИшкой задрачивать не буду, перепишем на Bash.

Задача: у меня есть серверный процесс, который должен получить уведомление от клиента с некоторыми данными (например, номер задачи).

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

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

Пишем сервер signal_listener.sh

#!/bin/bash

handle_signal() {
    echo "Получен сигнал $1"
    echo "Переданные данные: $2"
}

trap 'handle_signal SIGRTMIN+0 "Task 1 выполнена"' RTMIN+0
trap 'handle_signal SIGRTMIN+1 "Task 2 выполнена"' RTMIN+1

echo "Слушатель запущен. PID: $$"
echo "Ожидаем сигналы..."

while true; do
    sleep 1
done

Пишем клиент signal_sender.sh

#!/bin/bash

if [ $# -ne 2 ]; then
    echo "Использование: $0 <PID> <TASK>"
    echo "TASK может быть 1 или 2"
    exit 1
fi

PID=$1
TASK=$2

if [ "$TASK" -eq 1 ]; then
    kill -RTMIN+0 $PID
    echo "Отправлен сигнал SIGRTMIN+0 (Task 1) процессу с PID $PID"
elif [ "$TASK" -eq 2 ]; then
    kill -RTMIN+1 $PID
    echo "Отправлен сигнал SIGRTMIN+1 (Task 2) процессу с PID $PID"
else
    echo "Ошибка: TASK должен быть 1 или 2"
    exit 1
fi

trap = перехватываем сигналы, для СРВ пишем: RTMIN+0 и RTMIN+1

kill -RTMIN+N = отправляет СРВ. Номер сигнала (например, RTMIN+0) задаёт, какой именно сигнал будет обработан.

chmod +x signal_listener.sh signal_sender.sh

Запускаем первый скрипт, видим его PID:

Слушатель запущен. PID: 20821

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

./signal_sender.sh 20821 1

Отправлен сигнал SIGRTMIN+0 (Task 1) процессу с PID 20821

Не забываем подставить PID, который выдал первый скрипт.

После отправки СРВ, в терминале где запускали первый скрипт видим:

Получен сигнал SIGRTMIN+0
Переданные данные: Task 1 выполнена

Вот это нихуя се! То есть signal_sender подключился к процессу 20821 и передал в него данные.

В нашем случае данные это 1 или 2. А скрипт signal_listener успешно это схавал и переварил исходя из логики.

Использование СРВ открывает ОГРОМНЫЕ возможности, чтобы несколько скриптов или приложений взаимодействовали друг с другом на низких уровнях не использую велосипеды и прокладки.

А когда какой сигнал использовать?

Хе… 34-64… Если у тебя не сложная логика, можешь использовать любой индекс в этом диапазоне. Но если логика совсем ебанутая, то логичнее использовать СРВ с разными индексами для передачи данных.

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

Типа такого:

SIGRTMIN+0 (34): "Начать обработку данных"
SIGRTMIN+1 (35): "Обновить конфигурацию"
SIGRTMIN+2 (36): "Выебать медведя в жопу"
SIGRTMIN+3 (37): "Остановить обработку данных"

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

А можно обрабатывать в порядке приоритета. СРВ обрабатываются в порядке их номеров (от SIGRTMIN к SIGRTMAX). Это заебись если у тебя задачи с разным приоритетом.

SIGRTMIN+0: Высший приоритет (аварийная задача)
SIGRTMIN+1: Средний приоритет (регулярные уведомления)
SIGRTMIN+2: Низший приоритет (обновление статистики)

Если сигналы поступают одновременно, сначала обработается SIGRTMIN+0, потом SIGRTMIN+1 и т.д.

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

Если что-то еще вспомню, накидаю отдельным постом.

Удачи тебе и береги себя!

про сигналы писал ранее тут и тут и тут и тут

tags: #linux
—
🔔 @bashdays➡️ @gitgate

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

Устанавливается так: apt install vlock

Vlock блокирует виртуальную консоль/ли и требует ввода пароля.

Короче сидишь ты такой, на ascii картинки рукоблудишь в терминале, заходит мамка и ты такой — vlock бля!

Консоль моментально превращается в сообщение — This TTY is now locked. Please press [ENTER] to unlock.

Вот и всё! Это типа WIN+L или как там на маках CMD+CTRL+Q, но только для консоли. Локскрин! На случай если у тебя иксов нет, или ты в серверной живешь.

А чем отличается консоль от терминала я писал в этом посте и да, это не одно и тоже!

Чо там этот vlock умеет?

Основное:

-c lock only this virtual console, allowing user to switch to other virtual consoles.

-a lock all virtual consoles by preventing other users from switching virtual consoles.

-n allocate a new virtual console before locking,implies --all.

-s disable SysRq while consoles are locked to prevent killing vlock with SAK

-t run screen saver plugins after the given amount of time.

🅰️🅰️
Из сочного тут -s отключает сочетания клавиш SysRq, лично не проверял, но будем верить что если на заборе написано — хуй, значит он там есть.
🅰️🅰️

Про Magic SysRq писал тут, обязательно почитай, тема довольно пиздата.

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

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

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

Короче я показал, ты почитал. На этом и закончим. Мож где-то пригодится. Давай краба!

tags: #utilites #linux
—
🔔 @bashdays➡️ @gitgate

А давай я научу тебя девопсу. За 5 дней. Результат до/после гарантирую.

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

Только тебя палкой не били, а я буду.

🙃 Короче кто не успел запрыгнуть в августе в последний вагон Linux Factory, сейчас самое время, по летнему движу 5000р 2500р

Внутри почти 2 сезона:

1. Ansible
2. Gitlab CI/CD YML + Docker + Hashi Vault
3. Traefik
4. Prometheus + Consul + VM + Grafana
5. Terraform (Selectel/Yandex)
6. и многое другое…

будут кубы, охуенные циркули и база без воды

После интенсива ты охуеешь от бест-практик и научишься делать ха-ра-шо.

Киллер фича — ты со мной на связи, решаем вопросы 1x1.

Более подробно про интенсив можешь почитать тут и тут.

➡️ Залетай и жми кнопочки: @tormozilla_bot

В номере заказа ничего писать не нужно.

По всем вопросам можешь писать сюда: @linuxfactorybot

Прочитал статью про сигналы Медведя и захотелось немного разобраться в теме. Немного переписал проги, чтобы можно было от клиента к серверу передавать любые сообщения в виде текста.
ㅤ
Алгоритм простой. Используем 10 сигналов (SIGRTMIN+0 - SIGRTMIN+7 для передачи битов, SIGRTMIN+8 - признак окончания символа, SIGRTMIN+9 признак окончания сообщения).

Передаются только "единичные биты". SEND_CHAR - "разбирает символ по битам и передает" SEND_MESSAGE - разбирает сообщение по символам и отдает SEND_CHAR.

Сохраняем скрипты, chmod +x serv.sh cli.sh

В одном терминале ./serv.sh (он выдаст что-то вроде Listener process 340527).

В другом терминале ./cli.sh 340527 (нужно подставить ваш номер процесса).

При старте клиент сразу передает серверу сообщение "BashBays" А потом можете передать привет медведю. Пустое сообщение завершает клиента. Сервер останавливается через CTRL-C.

#/bin/bash

#serv.sh

declare -i ASC=0
declare MSG=
declare DELAY=0.01
handle_signal() {
  case "$1" in
    W) MSG=${MSG}$(printf "\x$(printf %x $ASC)") 
       ASC=0 ;;
    M) echo $MSG;MSG=;;
    *) ((ASC+=$1));;
  esac
}
#RTMIN=34
trap 'handle_signal 1' RTMIN+0
trap 'handle_signal 2' RTMIN+1
trap 'handle_signal 4' RTMIN+2
trap 'handle_signal 8' RTMIN+3
trap 'handle_signal 16' RTMIN+4
trap 'handle_signal 32' RTMIN+5
trap 'handle_signal 64' RTMIN+6
trap 'handle_signal 128' RTMIN+7
trap 'handle_signal W' RTMIN+8
trap 'handle_signal M' RTMIN+9
echo Listener process $$
while :;do
  sleep $DELAY
done

#!/bin/bash

#cli.sh

if [[ -z $1 ]];then
  echo Need server PID
  exit
fi
declare -ir SERV_PID=$1
declare MESSAGE=BashBays
declare -ir RTM=34

function DELAY(){ sleep 0.02;}

function SEND_CHAR(){
  local -i i ASC
  CUR_CHAR=${1:-" "}
  printf -v ASC "%d" "'$CUR_CHAR"
  for i in {0..7};do
    if [[  $(($ASC%2)) -eq 1 ]];then
#     echo kill '-'$(($i+$RTM)) $SERV_PID
      kill '-'$(($i+$RTM)) $SERV_PID
      DELAY
    fi
    ((ASC/=2))
  done
# echo kill '-'$((8+$RTM)) $SERV_PID
  kill '-'$((8+$RTM)) $SERV_PID
  DELAY
}
function SEND_MESSAGE(){
  local CUR_CHAR
  local MESSAGE=${1:-BashDays}
  local i
  echo  Send message \"$MESSAGE\" to  Server PID=$SERV_PID
  for ((i = 0 ; i < ${#MESSAGE} ; i++));do
    SEND_CHAR ${MESSAGE:$i:1}
  done
# echo kill '-'$((9+$RTM)) $SERV_PID
  kill '-'$((9+$RTM)) $SERV_PID
  DELAY
}

while [[ $MESSAGE ]];do
  SEND_MESSAGE "$MESSAGE"
  read  -p "Input new message:" MESSAGE
done

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

1. Обработка сигналов (по крайней мере SIGRTMIN не прерывает выполнение команд bash). Т.е если выполняется sleep 10m. То обработки можно ждать долго.

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

tags: #linux © by Tagd Tagd
—
🔔 @bashdays➡️ @gitgate

В рот мне логи! suqo
ㅤ
Здрасти короче.

Все знают команду cat, но не все знают про tac.

Так, так, так… Чо это?

Этот тот же cat только из Австралии наоборот. Оно выводит содержимое файла или стандартного ввода — в обратном порядке по строкам.

Команда tac входит в состав пакета GNU coreutils, и, как правило, она предустановлена на большинстве Linux-дистрибутивов.

Ща покажу. Есть у нас злой файл:

ножка на ножку и залупа в ладошку
eбутся утки вторые сутки
хуй сосали на вокзале

Запускаем:

tac file.txt

хуй сосали на вокзале
eбутся утки вторые сутки
ножка на ножку и залупа в ладошку

Поняли? Ну либо так:

echo -e "строка 1\nстрока 2\nстрока 3" | tac

строка 3
строка 2
строка 1

А можно прям разделитель указать:

echo "слово1:слово2" | tac -s ":"

слово2
слово1

Где применить?

Да где хочешь, можешь логи смотреть, можешь в bash скрипты пихать, можешь из csv бигдату собирать и т.п.

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

tags: #utilites #linux
—
🔔 @bashdays➡️ @gitgate

Привет, давай напишем очередной велосипед на Bash.

А напишем мы своё подобие команды cat, но с потоками.
ㅤ
Конечно можно воспользоваться дополнительной утилитой parallel, но мы лёгких путей не ищем. Глаза боятся, да руки веселятся.

Вот что у меня получилось:

#!/bin/bash

file=$1

threads=4

process_line() {
    line="$1"
    echo $line
}

export -f process_line

fifo="/tmp/fifo"
mkfifo "$fifo"
exec 3<>"$fifo"
rm "$fifo"

for ((i = 0; i < threads; i++)); do
    echo >&3
done

while IFS= read -r line; do
    read -u 3
    {
        process_line "$line"
        echo >&3
    } &
done < "$file"

wait
exec 3>&-

Не забываем chmod +x pcat

Запускать так: ./pcat.sh input.txt

➡️ Теперь разбираемся:

threads указываем количество потоков для чтения текстового файла.

process_line = функция, которая будет обрабатывать строку, у меня это простое echo, но можно накручивать любую логику.

export -f = экспортируем функцию, чтобы функция была доступна в subprocess (этот момент ранее в постах мы с тобой уже разбирали, ссылку не дам, по поиску найдешь если интересно).

fifo = задействуем FIFO для контроля потоков (чуть ниже объясню что это такое за хуйня).

mkfifo = создаём именованный канал /tmp/fifo для контроля количества одновременно запущенных потоков.

for ((i = 0; = заполняем каналы «семафора» чтобы ограничить потоки.

while IFS = читаем файл построчно и обрабатываем строки.

read -u 3 = ждем свободный слот «семафора», каждый поток блокируется до тех пор, пока не освободится место в «семафоре».

wait exec 3>&- = ждем завершение всех потоков

Что такое FIFO?

FIFO = «первым пришёл — первым ушёл».

Представляем ебейшую очередь в магазине:

1. Бабки встают в очередь
2. Первым обслуживают ту бабку, что пришла первой
3. Никто не может сказать — мне только спросить и пройти первым

Ну или на примере стопки книг:

Если ты складываешь книги в стопку и потом начинаешь снимать их, то ты будешь использовать LIFO (Last In, First Out).

Но если ты встал в очередь к кассе — это FIFO.

Думаю ты ты понял, тут все просто.

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

строка4
строка1
строка2
строка3
строка5
строка6

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

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

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

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

Добрый вечер, здрасти. За чо купил, за то и продаю.

На повестке — direnv.

Эт полезная хуёвина для расширения оболочки. И она достаточно известна среди населения в загнивающем западе.
ㅤ
Позволяет загружать и выгружать переменные среды в зависимости от каталога.

Грубо говоря — позволяет не засирать .profile всяким дерьмом.

Работает так: перед каждым запуском оно проверяет наличие файла (.envrc или .env) в текущем или родительском каталоге.

Если такой файл существует, то он загружается в подоболочку bash. И все экспортируемые переменные становятся доступны для текущей оболочки.

Работает с большой четверкой: bash, zsh, fish, tcsh

Суть — используем переменные среды для конкретного проекта, не трогая при этом ~/.profile.

Что интересно, direnv это бинарник на golang, что уже подразумевает скорость и все плюхи связанные с этим.

Для убунты ставится так: apt install direnv

Как воткнуть это в другое место, подробно написано тут ну или спроси у медведя.

Подключаем так, добавляем в ~/.bashrc:

eval "$(direnv hook bash)"

Для других шелов смотрим тут.

Не забываем перечитать файл ~/.bashrc чтобы изменения вступили в силу.

Так, поставили, молодцы! Проверяем чо получилось:

cd /tmp
mkdir my-project

echo ${FOO-bashdays}

На экран выдалось: bashdays

Переменная среды FOO не вывелась, логично, дальше:

echo export FOO=foo > .envrc

Ёпта, ошибка — direnv: error /tmp/my-project/.envrc is blocked. Run `direnv allow` to approve its content.

Сработала защита от дурака, которая запретила нам использовать .envrc. Хе, ща пофиксим!

direnv allow .

Во! Лепота!

direnv: loading /tmp/my-project/.envrc
direnv: export +FOO

Повторяем первую команду:

echo ${FOO-bashdays}

Хуяк и получаем: foo

Что и требовалось доказать, direnv отлично справилась с поставленной задачей.

Теперь выходим из проекта и смотрим:

cd ..

direnv: unloading

echo ${FOO-bashdays}

Ииии барабанная дробь, у нас вывелось — bashdays!

Какая же красота и любовь с первого взгляда!

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

➡️ Проект на гитхабе: https://github.com/direnv/direnv

⭐️ Star 12.6k

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

Как-то мы с тобой познакомились с etckeeper, ну дак вот, есть еще такая штука — ChezMoi.
ㅤ
Это херня для управления dotfiles (конфигурационными файлами, которые обычно начинаются с точки, например, .bashrc, .vimrc, .gitconfig) на нескольких устройствах.

Я сейчас такие файлы просто в гит руками херачу. Из основного у меня это конфиг для вима и zshrc со всякими алиасами и настройками.

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

На убунту ставится так: snap install chezmoi --classic

Для других операционок мануальчик здесь.

Ну поставили и чо дальше? А дальше запускаем:

chezmoi init

Добавляем например .bashrc

chezmoi add ~/.bashrc

Эта команда скопирует bashrc в ~/.local/share/chezmoi/dot_bashrc

Теперь отредактируй файл:

chezmoi edit ~/.bashrc

И посмотрим изменения:

chezmoi diff

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

Запускаем:

chezmoi -v apply

Нажимаешь к пример «o» = overwrite.

Хоба! И bashrc успешно восстанавливается. Прекрасно!

Теперь как с гитом работать:

chezmoi cd
git add .
git commit -m "Initial commit"

git remote add origin git@github.com:$GITHUB_USERNAME/dotfiles.git
git branch -M main
git push -u origin main

В принципе стандартная практика, первой командой переходим в каталог ~/.local/share/chezmoi ну а дальше база гита.

Затем на другой машине делаем:

chezmoi init https://github.com/$GITHUB_USERNAME/dotfiles.git

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

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

Сайт проекта: https://www.chezmoi.io/
На гитхабе: https://github.com/twpayne/chezmoi

tags: #utilites #linux
—
🔔 @bashdays➡️ @gitgate

🔥 Мой первый секс за деньги

Давно у нас про игрульки ничо не было. Пару штук принёс.

Картинки не стал добавлять, сам сходишь по ссылкам, посмотришь если интересно.
ㅤ
Нашел на просторах SysAdmin Odyssey: Back to the office, официально еще не вышла, но есть бесплатная демка.

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

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

Что понравилось — можно спиздить оперативку из системника.

➡️ Потыкай, затягивает: лежит тут

🅰️🅰️

Вторая: hack_me

Тут примеряешь чёрную шляпу и хуячишь сервера крупных компаний. Всё как по настоящему, sql инъекции, эксплоиты, логи и т.п. Игра вдохновлена сериалом «Мистер Робот»

Написал русскоговорящий чел, по отзывам прям конфета. Лично не тыкал, но коллеги порекомендовали взамен Animal Crossing. Единственный минус, игра жадная, но не дорогая, регулярно под скидками.

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

➡️ Забираем тут

tags: #games
—
🔔 @bashdays➡️ @gitgate

🤩 Пятница — это продакшн, который уже не твоя проблема.

Частенько для установки какого-то софта в линукс, предлагают использовать какой-то snap.

snap install chezmoi

Когда snap появился я как-то скептически к нему отнесся. Мол, чо за хуйня, есть же apt и еже подобные коробочные варианты. Больше наверное меня беспокоило что засрётся система какой-то неведомой шляпой.
ㅤ
Время шло и snap появился в коробке. Всё больше вкусных репок стало инсталиться именно через эту штуковину. Пришлось лезть в нору и знакомиться.

Короче snap это пакетный менеджер, кто бы мог подумать.

Фишка snap — пакеты работают на любом дистрибутиве Ubuntu, Fedora, Arch, Debian и др. без необходимости адаптации под конкретный дистрибутив.

То есть создается один пакет с софтиной и он подходит под все дистрибутивы. Красота!

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

А еще такой софт запускается в песочнице. Тут безопасники сразу ставят плюсик.

А еще установленные пакеты автоматически обновляются в фоне и они всегда актуальны.

А еще snap пакет содержит все зависимости и библиотеки, которые требуются для запуска софтины.

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

Ну ты понял… а когда применять apt, а когда snap?

➡️ snap хорошо подходит для:

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

➡️ apt предпочтительнее для:

— системных компонентов и пакетов, тесно интегрированных с операционной системой.
— софта, требующего максимальной производительности.

Вот и всё! Не такой snap и страшный. Вечерком еще покажу кое-что интересное (не письку).

tags: #linux
—
🔔 @bashdays➡️ @gitgate

Бас мазафака фактор! Ща жопы сгорят...

Где бы я ни работал, я стараюсь завязать какой-то кусок именно на себя. В идеале полностью подмять и пустить корни во все процессы связанные с той деятельностью, которой я занимаюсь.
ㅤ
Если на пальцах, к примеру в компании изначально доминирует terraform и golden image через packer. Я прихожу, вижу этот пиздец. Почему пиздец? Да потому, что это пиздец. Но совладать с процессами на начальном этапе я не могу, потому, что я новенький и не мне диктовать условия. К моим предложениям перейти на ansible и сделать динамические inventory для теры, относятся скептически. Хули? Смириться? Нет уж.

Я запиливаю в свое свободное время всю эту связку, делаю пайплайны, кнопку, тесты, короче делаю универсальное решение, которое работает. А не то, что существует у них сейчас. Презентую его CTO в личной беседе. В 99.9999% CTO дает мне зеленый свет на внедрение. А старье с golden image выбрасываем на парашу.

Продавил. Молодец. Но остается хуита, когда коллеги из отдела просто в недоумении, типа хуй с горы пришел, чото новое интегрировал, CTO поддержал, да как так-то? Мы тут сидели баблишко, получали, а теперь надо чему-то новому учиться. Да блядь, ребята! Придется играть по моим правилам, либо идите на хуй!

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

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

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

Сидеть в говне я не люблю, по этому, всегда, ВСЕГДА выпиливаю гавно и ввожу новые процессы. Хоть это новая робота, хоть старая. Да я уверен, что продавил бы даже яндекс с гуглом, хотя у них надеюсь и без меня все заебись.

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

Сейчас со мной работает человек и он действительно вникает в то, что я внедрил. Я спокойно сходил в отпуск на месяц и нихуя не уебалось. Он умеет управлять моим заводом. Я отдал ему поле под цех, он построил себе небольшой заводик и успешно им владеет. Я в него не лезу, он создал свой бас фактор и завязал его на себя. Молодец. А не лезу я, потому, что мне неинтересно. А то что мне неинтересно идет нахуй.

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

Короче хуй пойми, бизнес не любит бас фактора, а мы любим бас фактор.

Любим по причине — этим можно манипулировать и выбивать себе хорошие должности и ЗП.

А как ты считаешь?

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

👀 Один рубит - семеро в хуй трýбят!

Попросил сегодня на собесе кандидата зачистить nginx логи. Кандидат на роль девопс (мидл) на вилку 200-250к.

Зачистил — rm /var/log/nginx/access.log

Мде блядь… это будет интересно!
ㅤ
Задаю следующий вопрос — Серёжа, а почему файл access.log пропал и больше не появляется? Nginx то в данный момент работает, запросы на него идут.

Где карта Билли? Нам нужна карта!

Внятного ответа не получил, что-то на уровне — он появится спустя сутки, когда logrotate отработает. Дада… будем сутки без логов сидеть. А если нет logrotate?

Короче, если хочешь зачистить файл, есть несколько безопасных способов.

Первый способ:

sudo > /var/log/nginx/access.log

Тут мы перезаписываем лог-файл с помощью оператора редиректа «>».

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

Ключевая фраза — дескриптор не изменится. А когда ты этот файл через rm ёбнул само собой дескриптор потерялся и nginx охуевает.

Второй способ:

sudo truncate -s 0 /var/log/nginx/access.log

-s 0 = обрезать файл до нулевого размера. В этом случае дескриптор также не будет потерян и nginx продолжит писать непотребности.

Третий способ:

Некоторые сервисы, например, apache или nginx, позволяют отправить сигнал процессу для того, чтобы он закрыл текущий лог-файл и открыл новый (сигнал USR1). В этом случае процесс продолжит работать, но логи будут записываться в новый файл.

sudo kill -USR1 <pid>

Где <pid> = PID процесса. После выполнения этой команды файл с логов превратится в access.log.1 и откроется новый access.log.

Четвертый вариант — тот самый logrotate, но его рассматривать не будем.

Я пользуюсь первым вариантом с символом перенаправления «>». Стильно, модно, молодежно!

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

А какие способы обнуления знаешь ты? Про алкашку не пишите, этот способ знают все.

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

Привет, друзья, вопрос из зала от коллеги. Кто что думает? Велком в комменты!
ㅤ
Вопрос:

Сейчас занимаюсь задачей по миграции/синхронизации файлового сервера предприятия.

Суть проблемы в следующем: Вся информация сейчас распределена по разным серверам, которые начинают выходить из строя.

Используется Windows Server с DFS, права настроены через Active Directory.

Новый файловый сервер нужно реализовать на базе РЕД ОС.

На этапе планирования столкнулся с рядом вопросов — как лучше организовать процесс миграции, чтобы структура и права доступа остались удобными и управляемыми?

Если у вас будут предложения или потребуется дополнительная информация, с радостью предоставлю! Заранее спасибо за помощь!

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

Как я изучал кубер или хуёвой пизде — хуёво везде.

Короче взбрело как-то нашему техдиру засунуть бложек компании в кубер. Бложек на вордпрессе, вся хуйня.
ㅤ
На вопрос — чтобы что? Он же и так нормально крутится, не падает, работает и не трогай!

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

В общем владелец компании где-то с корешами посидел за чаркой сакэ и они ему в уши нассали.

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

Кубера у нас как ты понял не было. И мне предстояло его внедрять.

О кубере естественно я знал словом — нихуя! Но задача есть, надо делать, ипотека сама себя не оплатит.

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

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

Старым добрым методом «тыка» всё поднял, написал пайплайны, собрал контейнеры, задеплоил. Базу кстати тоже в кубер перетащил, просили же всё туда перенести.

Вся эта поделка была похожа на какой-то обдристанный шалаш подпертый рыхложопными костылями, но всё работало.

Задачу в done, все довольны. Я молодец. Теперь я знаю кубер!

А спустя сутки начались качели. Пользователи начали регулярно получать 500ки, иногда ПОД с базой ПОДъебывал и каким-то образом просто выпадал в осадок. Ну и еще вагон и тележка факапов.

Фиксилось это естественно гуглежом. За неделю более менее все было отлажено, базу по итогу пришлось вытащить из этого комбайна и поселить на отдельном серваке. Опыт!

Но раз в неделю стабильно что-то вылазило новое. Блядь… меня трясти уже начинало когда там что-то ломалось. А еще за каждый инцидент жестко ебали, как медведя. Одним словом — айти.

Любят люди всё усложнять, ну работало оно раньше, нахуй было это трогать. Тем более тащить вордпресс в кубер.

Чуть позже я увидел битрикс в кубе, это отдельный пиздец.

💬💬💬

Эт я к чему. Изучив базово технологию по ютубу, я добавил себе в резюме строчку — знания k8s, покидал отклики на ХХру и через пару дней получил оффер. А через 2 недели забыл про этот вордпресс как страшный сон.

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

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

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

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

А если на собесе что-то спросили, а ты не знаешь, так и скажи — я хуй знает, слышал, но не тыкал, разберусь короче, не проблема!

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

Сразу ходи с настроением — Не они тебе нужны, а ты им.

Ну и про кубер. Не нужно его поднимать где только можно, он используется точечно, для проектов которые в нём нуждаются. А не потому что это — модно блядь!

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

Но это справедливо для всех технологий.

Если нет желания — хуй ты чему научишься.

Такие дела, мотай на ус и не ссы, всё у тебя получится!

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

Сегодня 1с начала ругаться на нехватку лицензий. Дело не мое, но начали проверять, и увидели подключение с IP, которого нет в нормативных документах.

🔥 Инцидент. Я немного офигел. Что, откуда? Нужно искать, кто тут такой умный.

Начинаем исследование:

на сервере 1c

ss|grep ip - Видно, машина работает с 1с.
ping ip - машина не пингуется.
nmap -Pn ip - все порты < 1000 закрыты.

Ага, скорее всего windows 10 после обновления переключила сеть в "общедоступные".

arp ip - показывает mac

По mac определили, что это ASUS. Но может ноут, может комп или wi-fi роутер вредители воткнули в сеть.

sudo arping -I enp3s4 ip - машина пингуется.

Но как ее найти? Сетка не большая, меньше 100 ip, но не будешь же каждый комп и каждое устройство проверять...

Короче, на серваке 1с:

sudo iptables -I INPUT -s ip -j REJECT

Через 5 минут пользователь звонит, "у меня 1с не работает".

Проверил - точно. Ip не правильно задали. Восстановил, перевел сеть в режим "Частные".

А проблему нехватки лицензий так и не решили. Конец года, вся бухгалтерия пашет. Вот лицензий на всех и не хватает.

Народ, а вы сталкивались с появлением в сети незарегистрированных ip? Как решали проблему?

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

Верной дорогой идёте товарищи...

идея в стадии разработки и применение в проде пока нежелательно

ㅤ
Уровень статьи средне-сложный. Я не буду объяснять, как завести пользователя, как прописать ему оболочку, как настроить аутентификацию по ключам. Информации об этом валом.

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

Заинтриговал? Мозг немного взорвался? Короче, делаем ssh-прокси.

⁉️ Для чего это нужно?

Это можно использовать для раздачи доступа сторонним пользователям для управления ресурсами внутри сети, для студентов, работающих на удалёнке. (студенты IT - самые агрессивные пользователи).

Короче для минимизации рисков информационной безопасности. Скажу сразу, это не панацея. Инфу/файлы можно таскать через буффер обмена. Но много информации так не передашь.

Поехали!

Понадобится 2 машины: Бастионная (Jump-сервер, ssh-прокси) - машина, которая торчит открытым портом ssh в интернет.

И Тупиковая - машина (возможно виртуалка), с открытым в локалку портом ssh, на которой будет работать пользователь. И у которой нет доступа в инет (закрыт на периметровом маршрутизаторе. Или не прописаны шлюзы.

Основное условие у пользователя не должно быть root, а то сменит IP/MAC, пропишет шлюзы...). (допустим ее локальный ip 10.10.10.10).

С Бастионной машины должен быть доступ к Тупиковой по ssh, внутри локалки.

НА БАСТИОННОЙ МАШИНЕ. (аутентификация по ключам уже настроена, ssh защищена от быстрого перебора, для этой группы пользователей запрещен проброс портов)

1. Заводим пользователя, например, Tagd83j6 с паролем >=20 символов (не пригодится)

2. Добавляем публичный ключ Пользователя. (Он обычно с парольной фразой) в ~/.ssh/authorized_keys

3. Генерим ключ без пароля для доступа к Тупиковой машине. (лучше ed25519).

4. Домашней папке Tagd83j6 создаем файл типа shell10.sh (555 root:root)

#!/bin/bash
set -o errexit
set -o nounset
set -o pipefail
ssh $USER@10.10.10.10  2>/dev/null

sudo usermod -s /home/Tagd83j6/shell10.sh Tagd83j6

НА ТУПИКОВОЙ МАШИНЕ (аутентификация по ключам уже настроена)

1. Заводим пользователя Tagd83j6 с паролем >=20 символов (не пригодится)

2. добавляем публичный ключ(с Бастионной машины. п3) в ~/.ssh/authorized_keys

Все. Теперь, если на Бастионной машине от root набрать

su Tagd83j6

Сразу должны попасть на Тупиковую машину.

Собственно все.

Аутентификация пользователя производится на Бастионной машине!!!

При подключении к Бастионной машине нас сразу перебрасывает на Тупиковую. На ней есть локалка, но нет интернета.

Вопросы, критика, плюсики приветствуется.

tags: #networks #linux © by Tagd Tagd
—
🔔 @bashdays➡️ @gitgate