Please open Telegram to view this post
VIEW IN TELEGRAM
Любишь унижения? Рекомендую!
Здрасти. В Linux есть возможность включить «оскорбительный режим», который работает из коробки без установки дополнительного шлака.
Суть этого режима: при использовании команды sudo, если ты ввел неправильный пароль, система унизит тебя.
Для включения, добавь в файл /etc/sudoers (либо в /etc/sudoers.d/fuck.conf) такую строчку:
А после этого попробуй выполнить от пользователя:
И введи неправильный пароль. Результаты бывают разные:
Все эти фразочки зашиты в библиотеке
Делается так:
Предварительно закомментируй Defaults insults. Можно конечно пересобрать
Уверен есть способ запустить такой Bash скрипт по триггеру:
Изучай!
tags: #bash #linux
—
@BASHDAYS
Здрасти. В Linux есть возможность включить «оскорбительный режим», который работает из коробки без установки дополнительного шлака.
Суть этого режима: при использовании команды sudo, если ты ввел неправильный пароль, система унизит тебя.
Для включения, добавь в файл /etc/sudoers (либо в /etc/sudoers.d/fuck.conf) такую строчку:
Defaults insults
А после этого попробуй выполнить от пользователя:
sudo apt update
И введи неправильный пароль. Результаты бывают разные:
Take a stress pill and think things over.
You fucking stupid shit!
My mind is going. I can feel it.
Realy? Are you on drugs?
Все эти фразочки зашиты в библиотеке
/usr/libexec/sudo/sudoers.so
. Но на английском не интересно. Поэтому можно выводить своё сообщение через такой хак: Делается так:
Defaults badpass_message="Еще одна попытка и я тебя выебу!"
Предварительно закомментируй Defaults insults. Можно конечно пересобрать
sudoers.so
со своими фразами, но геморно. Ну либо пропатчить прям этот файл через HEX редактор. Уверен есть способ запустить такой Bash скрипт по триггеру:
#!/bin/bash
messages=("Неверный блядь пароль! У тебя палец сломан?"
"Еще одна попытка и я тебя выебу"
"Может, тебе стоит попробовать свою девичью фамилию?")
echo "${messages[$RANDOM % ${#messages[@]}]}"
Изучай!
tags: #bash #linux
—
@BASHDAYS
Кто сеет ветер, тот пожнет бурю
А давай пожнем бурю! Как мы любим. Недавно я писал пост про readonly и переменные. Ну дак вот, заансетить переменную можно и другим способом.
Не спеши переключать канал, будет ОХУЕННО интересно.
Bash теперь не менее опасен чем perl.
ctypes - это не просто очередная скриптовая библиотека, это штука позволяет вызывать функции из shared библиотек на СИ, прямо из bash скриптов. Охуеть да?
Можно сказать это внештатный модуль для Bash с огромным функционалом. Где не справился Bash, справится Bash + ctypes.
Могу сравнить это с паскалем и вставками на ассемблере, ох любил я это дело в школе. Учительница по информатике плакала кровавыми слезами, когда читала мои исходники. А потом вообще просто начала ставить пятерки, чтобы не видеть моих брейнфаков.
Давай попрактикуемся. Собираем модуль ctypes.
По умолчанию вся эта байда ставится в папку /usr/local/bin и /usr/local/lib. Но при сборке путь можно изменить через параметр
Так собрали, установили. Чо дальше? А дальше пишем самую простую so библиотеку:
Компилируем:
На выходе получаем готовый файл
Команда nm покажет, все глобальные функции и переменные, которые доступны в библиотеке
Ок. Всё верно! Символ T перед названием функции, означает, что функция глобальная. А символ U (puts) = что эту функцию можно вызвать из вне.
Ну и теперь с помощью ctypes мы можем вызвать эту функцию из Bash скрипта.
Опа нихуя! На экран получаем результат выполнения СИ функции hello_bashdays. Собственно Hello, Bashdays!
И это всего лишь верхушка айсберга, если копнуть глубже…
Вот несколько отзывов на ctypes:
- Это отвратительно
- Это должно прекратиться
- Вы зашли слишком далеко
- Это шутка?
Вот такие интересные штуки существуют. Надеюсь тебе понравилось. Теперь ты знаешь как собирать shared so файлы и легко вызывать от туда функции.
Аа забыл, как заансетить переменную:
Вот и все. И никаких тебе танцев с gdb. Переменная VAR обнулена.
Примени это с умом, ведь на тёмную сторону перейти очень легко. Увы, но я уже там!
🌐 Страница проекта на github
tags: #bash #linux
—
@BASHDAYS
А давай пожнем бурю! Как мы любим. Недавно я писал пост про readonly и переменные. Ну дак вот, заансетить переменную можно и другим способом.
Не спеши переключать канал, будет ОХУЕННО интересно.
Bash теперь не менее опасен чем perl.
ctypes - это не просто очередная скриптовая библиотека, это штука позволяет вызывать функции из shared библиотек на СИ, прямо из bash скриптов. Охуеть да?
Можно сказать это внештатный модуль для Bash с огромным функционалом. Где не справился Bash, справится Bash + ctypes.
Могу сравнить это с паскалем и вставками на ассемблере, ох любил я это дело в школе. Учительница по информатике плакала кровавыми слезами, когда читала мои исходники. А потом вообще просто начала ставить пятерки, чтобы не видеть моих брейнфаков.
Давай попрактикуемся. Собираем модуль ctypes.
git clone https://github.com/taviso/ctypes.sh.git
cd ctypes.sh
./autogen.sh
./configure
make
sudo make install
По умолчанию вся эта байда ставится в папку /usr/local/bin и /usr/local/lib. Но при сборке путь можно изменить через параметр
PREFIX=$HOME make install
.Так собрали, установили. Чо дальше? А дальше пишем самую простую so библиотеку:
#include <stdio.h>
void hello_bashdays() {
printf("Hello, Bashdays!\n");
}
Компилируем:
gcc -shared -o /tmp/bashdays.so bashdays.c
На выходе получаем готовый файл
bashdays.so
с функцией hello_bashdays. Проверяем какие символы доступны в скомпилированной библиотеке:nm -g /tmp/bashdays.so
Команда nm покажет, все глобальные функции и переменные, которые доступны в библиотеке
bashdays.so
. Мне выдало такое:w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
w __cxa_finalize@GLIBC_2.2.5
w __gmon_start__
0000000000001119 T hello_bashdays
U puts@GLIBC_2.2.5
Ок. Всё верно! Символ T перед названием функции, означает, что функция глобальная. А символ U (puts) = что эту функцию можно вызвать из вне.
Ну и теперь с помощью ctypes мы можем вызвать эту функцию из Bash скрипта.
#!/bin/bash
source /usr/local/bin/ctypes.sh
dlopen "/tmp/bashdays.so"
dlcall "hello_bashdays"
Опа нихуя! На экран получаем результат выполнения СИ функции hello_bashdays. Собственно Hello, Bashdays!
И это всего лишь верхушка айсберга, если копнуть глубже…
Вот несколько отзывов на ctypes:
- Это отвратительно
- Это должно прекратиться
- Вы зашли слишком далеко
- Это шутка?
Вот такие интересные штуки существуют. Надеюсь тебе понравилось. Теперь ты знаешь как собирать shared so файлы и легко вызывать от туда функции.
Аа забыл, как заансетить переменную:
readonly VAR=123
source /usr/local/bin/ctypes.sh
dlcall unbind_variable string:VAR
Вот и все. И никаких тебе танцев с gdb. Переменная VAR обнулена.
Примени это с умом, ведь на тёмную сторону перейти очень легко. Увы, но я уже там!
tags: #bash #linux
—
@BASHDAYS
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Есть такие команды, они выведут справку по утилите printf:
НО. Каждая команда выведет свою версию справки (почти). То есть результат вывода будет отличаться в разных случаях. Не веришь? Попробуй сам.
В первом пункте с help printf всё понятно. Получишь некий огрызок, который трудно назвать страницей помощи. Да и во втором тоже самое.
В 1-2 вызывается именно встроенная утилита printf в оболочку Bash. А вот в третьем пункте, выведется достаточно внушительный хелп.
И этот внушительный хелп будет от схожей, внешней утилиты printf, которая располагается тут: /usr/bin/printf.
Посмотреть все варианты printf можно так:
На экран выведется список:
Ну и везде советуют пользоваться встроенной в Bash командой help, она нативнее и поддерживает почти весь синтаксис оболочки. Тут уже решать тебе.
Я очень редко читаю документацию таким способом, предпочитаю сразу загуглить. Ладно. Изучай.
tags: #bash
—
@BASHDAYS
1. help printf
2. printf --help
3. env printf --help
НО. Каждая команда выведет свою версию справки (почти). То есть результат вывода будет отличаться в разных случаях. Не веришь? Попробуй сам.
В первом пункте с help printf всё понятно. Получишь некий огрызок, который трудно назвать страницей помощи. Да и во втором тоже самое.
В 1-2 вызывается именно встроенная утилита printf в оболочку Bash. А вот в третьем пункте, выведется достаточно внушительный хелп.
И этот внушительный хелп будет от схожей, внешней утилиты printf, которая располагается тут: /usr/bin/printf.
Посмотреть все варианты printf можно так:
type -a printf
На экран выведется список:
printf is a shell builtin
printf is /usr/bin/printf
printf is /bin/printf
Ну и везде советуют пользоваться встроенной в Bash командой help, она нативнее и поддерживает почти весь синтаксис оболочки. Тут уже решать тебе.
Я очень редко читаю документацию таким способом, предпочитаю сразу загуглить. Ладно. Изучай.
tags: #bash
—
@BASHDAYS
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Если ты относишь себя к девопс-инженеру или что-то в этом духе — никогда не используй панельки ISPManager/VestaCP и т.п. для настройки серверов.
Привет. Короче сторис.
День первый.
100 лет назад я устроился в свою первую, местную веб-студию и велком таска на испытательном сроке была — подготовить сервер для клиентского проекта.
Нет, меня не закинули в озеро с крокодилами, мне дали инструкцию, как все это дело настроить. Но проблема была в том, что вся настройка сводилась к работе в чистой консоли.
В то время я уже был уверенный джун, но никогда не настраивал сервера таким способом, для меня это было — дичь ебаная!
На изучение мне понадобилась бы неделя, но обосраться с первой задачей я не мог. Но естественно обосрался.
Уже тогда, моя хитрожопость не знала границ. У меня был доступ в панель управления хостинга. И что я сделал? Правильно, пересоздал сервер с готовой Free ISPМ панелькой.
Ну а дальше по накатанной, мышкой натыкал за полчаса, домены прописал, пехапе и апачу (фу-фу) завел. Таску в done двинул. Сижу радуюсь, какой же я охуенный!
Потратил полчаса на таску, на которую мне выделили 8 часов. Естественно остальное время я пропинал хуи.
День второй.
На следующий день состоялся релиз клиентского проекта. Но… деплой не прошел, jenkins высрал еррор, мол — пермишен денаед.
И понеслась пизда по кочкам. Шеф вызвал на ковер и задал свой любимый вопрос — как такое произошло? Я долго что-то мямлил, ну и каким-то чудом всё вскрылось.
Как оказалось, инструкция по которой мне дали настраивать сервак, была отлажена годами и под эту настройку был заточен jenkins. Разработчик просто указывал IP адрес сервера куда выкатить вонючий битрикс и оно выкатывалось.
В моём случае, на серваке банально не были прописаны ssh ключи этого злоебучего jenkins’а. Нууу…. и не хватало структуры каталогов, заведенных пользователей, нехватало — ничего! Короче ЖОПА!
Ну я же не знал… Хотя мне потом все красиво объяснили, что я лось дырявый. И что нужно делать все по ТЗ, а не как мне оленю захочется. Процессы, все дела.
Короче пиздов отхватил знатно, а задачу вернули на доработку. С тех пор, я научился придерживаться условиям задачи. Ну и самое главное нехило так качнул свои знания в Linux. Правда на всё про всё ушла неделя.
Позже я накидал bash скрипт, который сам настраивал сервера по шаблону за несколько минут. Опыт дал о себе знать. Про этот скрипт я никому не говорил, хитрожопость.
Шеф был тот еще мудень, но его доёбки до любых мелочей выстроили в моей башке правильные нейронные связи.
Потом этот шеф написал на меня заяву, якобы я ему бекдоров насувал после увольнения. Но это были не бекдоры, а его дырявые битрикс. Короче разошлись мирно. Через несколько лет я узнал, что он много на кого бочку катил, обижался если от него уходили.
Сейчас, когда я умею с закрытыми глазами настраивать чёрта через консоль, я могу позволить себе панельки ISPM/VESTA, потому что понимаю что там под капотом и как это работает. Но в 99% предпочитаю консольку. Олдскулл.
Такие дела.
Всегда иди туда, где страшно. Чем страшнее, тем больше опыта получишь. А используя панельки, ты остаешься на уровне овоща, никакого развития. Понятно дело, оно проще, быстрее, но минус значительный — деградируешь.
У меня кореш активно пользуется панельками, но он не позиционирует себя как девопс, ему этот опыт нахер не нужен, ему нужно рабочее окружение под вордпресс и его пет-проекты.
Ладно, давай, хорошей тебе недели и не будь овощем!
tags: #рабочиебудни
@BASHDAYS
Привет. Короче сторис.
День первый.
100 лет назад я устроился в свою первую, местную веб-студию и велком таска на испытательном сроке была — подготовить сервер для клиентского проекта.
Нет, меня не закинули в озеро с крокодилами, мне дали инструкцию, как все это дело настроить. Но проблема была в том, что вся настройка сводилась к работе в чистой консоли.
В то время я уже был уверенный джун, но никогда не настраивал сервера таким способом, для меня это было — дичь ебаная!
На изучение мне понадобилась бы неделя, но обосраться с первой задачей я не мог. Но естественно обосрался.
Уже тогда, моя хитрожопость не знала границ. У меня был доступ в панель управления хостинга. И что я сделал? Правильно, пересоздал сервер с готовой Free ISPМ панелькой.
Ну а дальше по накатанной, мышкой натыкал за полчаса, домены прописал, пехапе и апачу (фу-фу) завел. Таску в done двинул. Сижу радуюсь, какой же я охуенный!
Потратил полчаса на таску, на которую мне выделили 8 часов. Естественно остальное время я пропинал хуи.
День второй.
На следующий день состоялся релиз клиентского проекта. Но… деплой не прошел, jenkins высрал еррор, мол — пермишен денаед.
И понеслась пизда по кочкам. Шеф вызвал на ковер и задал свой любимый вопрос — как такое произошло? Я долго что-то мямлил, ну и каким-то чудом всё вскрылось.
Как оказалось, инструкция по которой мне дали настраивать сервак, была отлажена годами и под эту настройку был заточен jenkins. Разработчик просто указывал IP адрес сервера куда выкатить вонючий битрикс и оно выкатывалось.
В моём случае, на серваке банально не были прописаны ssh ключи этого злоебучего jenkins’а. Нууу…. и не хватало структуры каталогов, заведенных пользователей, нехватало — ничего! Короче ЖОПА!
Ну я же не знал… Хотя мне потом все красиво объяснили, что я лось дырявый. И что нужно делать все по ТЗ, а не как мне оленю захочется. Процессы, все дела.
Короче пиздов отхватил знатно, а задачу вернули на доработку. С тех пор, я научился придерживаться условиям задачи. Ну и самое главное нехило так качнул свои знания в Linux. Правда на всё про всё ушла неделя.
Позже я накидал bash скрипт, который сам настраивал сервера по шаблону за несколько минут. Опыт дал о себе знать. Про этот скрипт я никому не говорил, хитрожопость.
Шеф был тот еще мудень, но его доёбки до любых мелочей выстроили в моей башке правильные нейронные связи.
Потом этот шеф написал на меня заяву, якобы я ему бекдоров насувал после увольнения. Но это были не бекдоры, а его дырявые битрикс. Короче разошлись мирно. Через несколько лет я узнал, что он много на кого бочку катил, обижался если от него уходили.
Сейчас, когда я умею с закрытыми глазами настраивать чёрта через консоль, я могу позволить себе панельки ISPM/VESTA, потому что понимаю что там под капотом и как это работает. Но в 99% предпочитаю консольку. Олдскулл.
Такие дела.
Всегда иди туда, где страшно. Чем страшнее, тем больше опыта получишь. А используя панельки, ты остаешься на уровне овоща, никакого развития. Понятно дело, оно проще, быстрее, но минус значительный — деградируешь.
У меня кореш активно пользуется панельками, но он не позиционирует себя как девопс, ему этот опыт нахер не нужен, ему нужно рабочее окружение под вордпресс и его пет-проекты.
Ладно, давай, хорошей тебе недели и не будь овощем!
tags: #рабочиебудни
@BASHDAYS
Please open Telegram to view this post
VIEW IN TELEGRAM
Мишки на сервере
Привет, привет, меня сегодня прям жёстко пранканули, сказали — тебе нужно написать 31 пост. Я конечно поржал, но потом заглянул в табличку маркетолога. Дела… придется затаскивать спринт длиной в апрель.
Так что постараюсь чтобы у тебя каждый день было интересное чтиво. Часто? Согласен! Но вы тёртые калачи и вас таким дерьмом не испугать!
А всем кто присоединился к нам недавно… Нет. По другому. У нас кароче есть пиздатый чатик, в нем порой жёстко, но ОЧЕНЬ познавательно. Преисполнишься.
Да чо рассказывать, иди да сам посмотри (там по заявкам, но потыкаю апрувы, хуль) 👇
✔️ https://t.me/bashday
Ну а я пошел пилить еще 29 постов, увидимся теперь точно завтра.
Привет, привет, меня сегодня прям жёстко пранканули, сказали — тебе нужно написать 31 пост. Я конечно поржал, но потом заглянул в табличку маркетолога. Дела… придется затаскивать спринт длиной в апрель.
Так что постараюсь чтобы у тебя каждый день было интересное чтиво. Часто? Согласен! Но вы тёртые калачи и вас таким дерьмом не испугать!
А всем кто присоединился к нам недавно… Нет. По другому. У нас кароче есть пиздатый чатик, в нем порой жёстко, но ОЧЕНЬ познавательно. Преисполнишься.
Да чо рассказывать, иди да сам посмотри (там по заявкам, но потыкаю апрувы, хуль) 👇
Ну а я пошел пилить еще 29 постов, увидимся теперь точно завтра.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
У самурая нет тестов, только прод
Здрасти. Есть куча способов как определить, в каком окружении запущен Bash скрипт. На хостовой машине или внутри docker контейнера. Я предпочитаю самый простой.
Банально проверяем наличие файла
И да файл
А если требуется высший пилотаж, прям УНИВЕРСАЛЬНО, прочекать docker и lxc, идем таким путём:
Тут суть такая, во всех хост-системах
Запускаем на хостовой машине:
Запускаем в контейнере:
✔️ Может зафакапить, так как не установлен пакет procps.
Да, кто не знал, как сохранять изменения в docker контейнерах, применяется commit. То есть ставишь софт в контейнере, настраиваешь его там под себя. А потом делаешь:
<ID> - ID того контейнера, в котором все ставил
<name> - да похуй, можешь указать тот же самый
После перезапуска контейнера все твои настройки сохранятся. Но лучше этим не частить, а собирать контейнеры сразу с нужной тебе хуйнёй.
Ладно, погнали дальше спасать этот прекрасный мир.
tags: #linux #bash
@BАSHDАYS | BАSHDАYS.CОM
Здрасти. Есть куча способов как определить, в каком окружении запущен Bash скрипт. На хостовой машине или внутри docker контейнера. Я предпочитаю самый простой.
if [ -f /.dockerenv ]; then
echo "I'm inside docker";
else
echo "I'm living in real world!";
fi
Банально проверяем наличие файла
.dockerenv
и всё! Да, так просто. Способ самый универсальный и используется разработчиками в 99% случаев.И да файл
.dockerenv
можно удалить и тогда скрипт сломается. Удобно, если хочешь помешать скриптам определять где они выполняются. НО после перезапуска контейнера файл .dockerenv
снова появится.А если требуется высший пилотаж, прям УНИВЕРСАЛЬНО, прочекать docker и lxc, идем таким путём:
if [ -n "$(grep 'kthreadd' /proc/2/status 2>/dev/null)" ]; then
echo "I'm living in real world!"
else
echo "I'm inside container";
fi
Тут суть такая, во всех хост-системах
PID(2) == kthreadd
. Запускаем на хостовой машине:
ps -p 2
PID TTY TIME CMD
2 ? 00:00:00 kthreadd
Запускаем в контейнере:
ps -p 2
PID TTY TIME CMD
хуй с маслом
Да, кто не знал, как сохранять изменения в docker контейнерах, применяется commit. То есть ставишь софт в контейнере, настраиваешь его там под себя. А потом делаешь:
docker commit <ID> <name>
<ID> - ID того контейнера, в котором все ставил
<name> - да похуй, можешь указать тот же самый
После перезапуска контейнера все твои настройки сохранятся. Но лучше этим не частить, а собирать контейнеры сразу с нужной тебе хуйнёй.
Ладно, погнали дальше спасать этот прекрасный мир.
tags: #linux #bash
@BАSHDАYS | BАSHDАYS.CОM
Please open Telegram to view this post
VIEW IN TELEGRAM