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

Всё было хорошо, пока я не повзрослел и не познал джаззз установил себе Windows. Ну и естественно запихал туда официальный гуёвый клиент от wg. А что могло пойти не так? А всё!

Клиент в рандомный момент показывал средний палец и работал через хуй копыто.

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

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

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

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

Называется эта штука TunnlTo. Работает в коллаборации с WireSock. По бенчмаркам обгоняет даже официальный WG клиент. На странице проекта там все подробно описано, можешь самостоятельно ознакомиться.

Чо понравилось:

1. Не глючит, шустрый, не виснет
2. Поддержка импорта тоннелей из официального wg клиента
3. При загрузки ОС можно автоматом подключать/не подключать VPN
4. Разделение приложений, кто идет через VPN, а кто нет
5. Ну и конечно другие фичи, какие хз, мне 4х хватает

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

💻 Страница проекта на github

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

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

tags: #utils #windows #networks
—
💩 @bashdays

Доброе утро! Все выходные разгребал бухгалтерию, да готовил рекламную кампанию на завтра. Даже баг мимолётом поправил у клиента. После подключения ddos-guard, мониторинг сильно засопливил. Ну тут очевидно, docker контейнеры с экспортерами снимают показатели по домену, а домен-то теперь за ddos-guard, пришлось прокинуть hosts файл и ходить напрямую за метриками.

Ладно. Сегодня на повестке дня: Зачем добавлять ./ перед исполняемым файлом или скриптом.

Когда я только начал изучение linux, я столкнулся с проблемой, что не могу выполнить bash скрипт. Вроде и атрибут +x указан, но после запуска получал идинахуй:

script.sh: command not found

Интернета тогда не было, максимум на что я мог рассчитывать это Фидонет. Но он мне не понадобился, методом тыка я самостоятельно смог решить задачу с запуском. Наверное знания MSDOS как-то натолкнули поставить перед скриптом символы ./

Но почему так? Это же не логично! Нет, всё логично. Это сделано для безопасности и от кривых рук. Например:

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

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

Вот поэтому если запускать какую-то дичь или скрипт БЕЗ ./ то оболочка будет искать эту дичь/скрипт в указанных каталогах. Которые определены в PATH. Соответственно если домашний каталог пользователя не определен в PATH, то и возникает ошибка command not found.

А вот когда указываешь ./script.sh ты говоришь оболочке - Эй бля! Игнорируй PATH и запускай мне эту пепяку! Да, вот прям отсюда!

Аналогично можно запускать указывая полный путь к программе/скрипту:

cd ~
./script.sh

# или

/home/user/script.sh

Здесь так же PATH будет игнорироваться. Но вопрос остается: Как это может быть мерой безопасности, если эта мера обходится банальным ./ ?

Нууу… это больше для предотвращения несчастных случаев. Указав явно ./ ты говоришь оболочке - запусти конкретно этот файл из текущего каталога, а не тот который может лежать в PATH.

Как вариант, можешь добавить точку в PATH и тогда можешь запускать скрипты без ./ например:

export PATH=$PATH:.
script.sh

Добавляем текущий каталог в PATH. Теперь script.sh выполнится, без указания этого хитрого ./ Но так делать не рекомендуется, наступишь на грабли или даже на граблища!

Так, теперь про cron. Если хочешь чтобы твои скрипты гарантировано запускались в cron, всегда указывай полные пути до программ/утилит. Так как cron может смотреть в какой-то свой PATH или вообще через sh запускаться. Встречал/встречаю я такие случаи. Поэтому рекомендуется писать скрипты в таком духе:

CAT=$(which cat)
$CAT script.sh

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

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


tags: #bash #linux
—
💩 @bashdays

О чо на почту сегодня прилетело. Вчера в чатике видел, ссылка уже пролетала от Константина, но чет значения не придал. А после этого письма придал.

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

Короче под капотом Debian 12 или Windows Server 2016 (14393.6709) Длительность онлайн сессии 15 минут.

С докой по сервакам, можешь ознакомиться здесь, там с картинками и всеми подробностями.

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

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

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

Выжимка из доки:

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

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

tags: #services
—
💩 @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 обнулена.

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

🌐 Страница проекта на github


tags: #bash #linux
—
@BASHDAYS