Если у вас стоит задача собрать небольшое количество текстовых логов в одном месте, то городить современные решения типа Loki, ELK, Graylog избыточно. Это и долго, и разбираться надо, если не умеешь, и по ресурсам затратно. Предлагаю старую, простую и проверенную временем альтернативу - syslog-ng. Я этот софт давно знаю и использую по мере необходимости.
Покажу пример простой настройки, которую можно взять за основу и расширить при необходимости. Устанавливаем:
Если на машине уже был установлен rsyslog, то он будет удалён. Вместе они не работают, так как выполняют одну и ту же задачу в том числе по ведению локальных системных логов.
Открываем конфигурацию
Можно выбрать любой IP адрес сервера, порт и протокол. Я указал стандартный порт UDP 514 для протокола syslog. Никто не мешает использовать что-то другое. Например TCP 1000:
Переходим в папку
Файл назвал
Я создал объект d_mikrotik, который указывает на хранение логов в файле
С таким подходом удобно настраивать что, куда и по каким условиям писать. Можно несколько source указать с разными интерфейсами, протоколами и портами. Если у вас устройства разнесены по разным подсетям, то можно описать приём в два разных лог-файла логи от Mikrotik и от Linux систем:
По умолчанию syslog-ng работает от root, что не очень разумно и в данной задаче не нужно. Запустим его от пользователя syslog. Если вас это не беспокоит, то можно запускать и под root.
Добавляем в
В файле
на
Идём на конечное устройство настраивать отправку логов. В Mikrotik это делается в System ⇨ Logging ⇨ Actions. В remote указываете IP адрес сервера с syslog-ng.
В системах Linux с rsyslog достаточно в
и перезапустить его.
Получилось очень простое решение по централизованному сбору логов без аналитики, которое настраивается за 10 минут и не требует практически никаких особых ресурсов. На чём можно запустить Debian, там и будет работать.
Для просмотра логов через браузер можно использовать tailon, logdy, cockpit, webmin.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#logs #syslog
Покажу пример простой настройки, которую можно взять за основу и расширить при необходимости. Устанавливаем:
# apt install syslog-ngЕсли на машине уже был установлен rsyslog, то он будет удалён. Вместе они не работают, так как выполняют одну и ту же задачу в том числе по ведению локальных системных логов.
Открываем конфигурацию
/etc/syslog-ng/syslog-ng.conf и добавляем один параметр, который позволит принимать логи по сети от других устройств и систем:source s_net { udp(ip(0.0.0.0) port(514)); };Можно выбрать любой IP адрес сервера, порт и протокол. Я указал стандартный порт UDP 514 для протокола syslog. Никто не мешает использовать что-то другое. Например TCP 1000:
source s_net { TCP(ip(0.0.0.0) port(1000)); };Переходим в папку
/etc/syslog-ng/conf.d и создаём там конфиг для приёма логов, например, с Mikrotik:destination d_mikrotik { file("/var/log/_remote/mikrotik.log"); };filter f_mikrotik { netmask("10.20.1.20/255.255.255.255"); };log { source(s_net); filter(f_mikrotik); destination(d_mikrotik); };Файл назвал
mikrotik.conf. В syslog-ng объектный принцип описания конфигурации. Этот как раз то, почему я предпочитаю для таких задач использовать именно его, а не rsyslog. У последнего не такой удобный формат конфигурации.Я создал объект d_mikrotik, который указывает на хранение логов в файле
/var/log/_remote/mikrotik.log. Далее я сделал фильтр f_mikrotik, где указал в качестве условия IP адрес роутера. Можно и всю подсеть добавить. И в завершении указал, как именно будем логировать. Берём источник s_net, то есть всё, что приходит на UDP 514, проверяем по фильтру f_mikrotik и пишем в d_mikrotik, то есть в указанный лог-файл. С таким подходом удобно настраивать что, куда и по каким условиям писать. Можно несколько source указать с разными интерфейсами, протоколами и портами. Если у вас устройства разнесены по разным подсетям, то можно описать приём в два разных лог-файла логи от Mikrotik и от Linux систем:
destination d_mikrotik { file("/var/log/_remote/mikrotik.log"); };filter f_mikrotik { netmask("10.20.1.0/255.255.255.0"); };log { source(s_net); filter(f_mikrotik); destination(d_mikrotik); };destination d_linux { file("/var/log/_remote/linux.log"); };filter f_linux { netmask("10.30.1.0/255.255.255.0"); };log { source(s_net); filter(f_linux); destination(d_linux); };По умолчанию syslog-ng работает от root, что не очень разумно и в данной задаче не нужно. Запустим его от пользователя syslog. Если вас это не беспокоит, то можно запускать и под root.
# useradd syslog -s /usr/sbin/nologin# chown syslog /var/lib/syslog-ng /var/log/_remoteДобавляем в
/etc/default/syslog-ng:SYSLOGNG_OPTS="-u syslog -g syslog"if [ ! -e /var/lib/syslog-ng.pid ] then touch /var/lib/syslog-ng.pidfichown syslog /var/lib/syslog-ng.pidchmod 0664 /var/lib/syslog-ng.pidВ файле
/etc/syslog-ng/syslog-ng.conf меняем пользователя в параметрах:owner("root"); group("adm")на
owner("syslog"); group("syslog")Идём на конечное устройство настраивать отправку логов. В Mikrotik это делается в System ⇨ Logging ⇨ Actions. В remote указываете IP адрес сервера с syslog-ng.
В системах Linux с rsyslog достаточно в
/etc/rsyslog.conf добавить параметр:*.* @10.20.1.5и перезапустить его.
Получилось очень простое решение по централизованному сбору логов без аналитики, которое настраивается за 10 минут и не требует практически никаких особых ресурсов. На чём можно запустить Debian, там и будет работать.
Для просмотра логов через браузер можно использовать tailon, logdy, cockpit, webmin.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#logs #syslog
4👍151👎4
Расскажу об одной банальной вещи. Возможно кому-то она поможет, если в голову не приходило такое решение.
Ночь - время для обслуживания и бэкапов. Хорошо, когда ты за ночное окно успеваешь всё сделать и перекинуть данные на бэкап сервера. Но рано или поздно ночного окна начинает не хватать, особенно если бэкапы льются через интернет. Решать вопрос лучше всего комплексно, уменьшая объём передаваемых данных и двигая сервер с бэкапами ближе к источнику.
Если перечисленное выше не приводит к желаемому результату, то я настраиваю ограничение трафика. Вопрос этот непростой, если подразумевать полноценную приоритизацию на основе типов данных. Если ты не занимаешься этим вопросом постоянно, то довольно муторно вникать во все нюансы. Но конкретно в этой задаче не придётся сильно погружаться, так как я предлагаю просто ограничить в определённое время полосу пропускания на основе IP адреса сервера с бэкапами. А это самый простой случай.
В Mikrotik такое ограничение можно настроить с помощью Simple Queue. В шлюзах на базе Linux с помощью tc из пакета iproute2. В других шлюзах и роутерах этот как-то по-другому может решаться.
Для нормальной настройки шейпирования, чтобы не мешать привычной дневной работе, нужно обязательно иметь мониторинг полосы пропускания. Тот же Zabbix или Prometheus без особых проблем решают в типовых ситуациях эти вопросы. Надо знать среднюю загрузку канала и разрешить бэкапам литься с такой скоростью, чтобы днём не было полной утилизации полосы пропускания.
Я обычно делаю отдельные дашборды в мониторинге с загрузкой канала, чтобы во-первых, быстро оценить среднюю дневную загрузку, во-вторых, чтобы потом удобно контролировать загрузку, если бэкапы в ночь не успевают скопироваться.
Делается всё это обычно для того, чтобы если до утра задержится копирование, не парализовать работу. Если бэкапы уже сильно не успевают заливаться и уходят в день, то надо что-то менять. Потому что даже с таким ограничением они мешают полноценной работе. У тебя полезная ёмкость канала уменьшается.
#network #backup
Ночь - время для обслуживания и бэкапов. Хорошо, когда ты за ночное окно успеваешь всё сделать и перекинуть данные на бэкап сервера. Но рано или поздно ночного окна начинает не хватать, особенно если бэкапы льются через интернет. Решать вопрос лучше всего комплексно, уменьшая объём передаваемых данных и двигая сервер с бэкапами ближе к источнику.
Если перечисленное выше не приводит к желаемому результату, то я настраиваю ограничение трафика. Вопрос этот непростой, если подразумевать полноценную приоритизацию на основе типов данных. Если ты не занимаешься этим вопросом постоянно, то довольно муторно вникать во все нюансы. Но конкретно в этой задаче не придётся сильно погружаться, так как я предлагаю просто ограничить в определённое время полосу пропускания на основе IP адреса сервера с бэкапами. А это самый простой случай.
В Mikrotik такое ограничение можно настроить с помощью Simple Queue. В шлюзах на базе Linux с помощью tc из пакета iproute2. В других шлюзах и роутерах этот как-то по-другому может решаться.
Для нормальной настройки шейпирования, чтобы не мешать привычной дневной работе, нужно обязательно иметь мониторинг полосы пропускания. Тот же Zabbix или Prometheus без особых проблем решают в типовых ситуациях эти вопросы. Надо знать среднюю загрузку канала и разрешить бэкапам литься с такой скоростью, чтобы днём не было полной утилизации полосы пропускания.
Я обычно делаю отдельные дашборды в мониторинге с загрузкой канала, чтобы во-первых, быстро оценить среднюю дневную загрузку, во-вторых, чтобы потом удобно контролировать загрузку, если бэкапы в ночь не успевают скопироваться.
Делается всё это обычно для того, чтобы если до утра задержится копирование, не парализовать работу. Если бэкапы уже сильно не успевают заливаться и уходят в день, то надо что-то менять. Потому что даже с таким ограничением они мешают полноценной работе. У тебя полезная ёмкость канала уменьшается.
#network #backup
1👍104👎3
Изучал на днях один инструмент и случайно наткнулся на информацию про Systemd.path - триггер на события в файловой системе. Удивился, что не знаком с этой функциональностью. Либо уже забыл это. Но сам точно не использовал. С помощью Systemd.path можно отслеживать изменения в файловой системе и выполнять какие-то действия на их основе.
Функциональность очень полезная. Сразу покажу на примере. Допустим, нам надо выполнить какое-то действие при изменении файла. Настраиваем сначала слежение за файлом. Создаём файл
Будем следить за изменением файла
Для теста и понимания, как это работает, настроил простейшее действие. Команда echo будет писать текущую дату перезапуска службы в файл
Убеждаемся, что первое выполнение службы было сделано в момент старта:
Должен был создаться файл
Такой вот простой и удобный механизм. В строку
В данном примере я использовал директиву слежения за записью в файл PathModified. Помимо неё есть другие:
◽️PathExists= реагирует на появление заданного файла или директории.
◽️PathExistsGlob= то же самое что и предыдущее, но можно использовать маски для имён.
◽️PathChanged= отличается от PathModified тем, что реагирует не на запись в файл, а на закрытие файла после записи.
◽️DirectoryNotEmpty= реагирует на появление файла в пустой директории.
📌 Другая полезная (и не очень) функциональность SystemD:
◽️Systemd timers как замена Cron
◽️Journald как замена Syslog
◽️Systemd-journal-remote - централизованное хранение логов
◽️Systemd-journal-gatewayd - просмотр логов через браузер
◽️Hostnamectl для просмотра информации о системе
◽️Systemd-resolved - кэширующий DNS сервер
◽️Параметры Systemd для приоритизации дисковых операций
◽️Ограничение потребления памяти с Systemd
◽️Синхронизация времени с помощью systemd-timesyncd
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#systemd
Функциональность очень полезная. Сразу покажу на примере. Допустим, нам надо выполнить какое-то действие при изменении файла. Настраиваем сначала слежение за файлом. Создаём файл
/etc/systemd/system/daemon.path:[Unit]Description=Watch /etc/daemon/daemon.conf for changes[Path]PathModified=/etc/daemon/daemon.conf[Install]WantedBy=multi-user.targetБудем следить за изменением файла
daemon.conf. А если оно случится, перезапустим службу daemon.service. Для этого создаём саму службу в файле /etc/systemd/system/daemon.service:[Unit]Description=Restart Daemon ServiceAfter=network.target[Service]Type=oneshotExecStart=sh -c "/usr/bin/echo daemon service restarted at `date` >> /etc/daemon/restart.date"[Install]RequiredBy=daemon.pathДля теста и понимания, как это работает, настроил простейшее действие. Команда echo будет писать текущую дату перезапуска службы в файл
/etc/daemon/restart.date. Запускаем проверку и саму службу:# systemctl enable daemon.{path,service}# systemctl start daemon.{path,service}Убеждаемся, что первое выполнение службы было сделано в момент старта:
# systemctl status daemon.serviceДолжен был создаться файл
/etc/daemon/restart.date. Теперь изменяем файл /etc/daemon/daemon.conf и проверяем снова restart.date. Там должна появиться новая строка с текстом daemon service restarted at и текущее время с датой.Такой вот простой и удобный механизм. В строку
ExecStart вместо echo можно указать любую команду или скрипт. Можете какую-то службу перезапускать или копировать куда-то файл при его изменении. Например, изменился TLS сертификат, можно его скопировать куда-то или перезапустить службу, которая его использует. Удобство тут в том, что всё логируется в systemd. И если у вас логи уже где-то хранятся и анализируются, то все события с path и service поедут туда автоматически и не надо отдельно об этом беспокоиться.В данном примере я использовал директиву слежения за записью в файл PathModified. Помимо неё есть другие:
◽️PathExists= реагирует на появление заданного файла или директории.
◽️PathExistsGlob= то же самое что и предыдущее, но можно использовать маски для имён.
◽️PathChanged= отличается от PathModified тем, что реагирует не на запись в файл, а на закрытие файла после записи.
◽️DirectoryNotEmpty= реагирует на появление файла в пустой директории.
📌 Другая полезная (и не очень) функциональность SystemD:
◽️Systemd timers как замена Cron
◽️Journald как замена Syslog
◽️Systemd-journal-remote - централизованное хранение логов
◽️Systemd-journal-gatewayd - просмотр логов через браузер
◽️Hostnamectl для просмотра информации о системе
◽️Systemd-resolved - кэширующий DNS сервер
◽️Параметры Systemd для приоритизации дисковых операций
◽️Ограничение потребления памяти с Systemd
◽️Синхронизация времени с помощью systemd-timesyncd
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#systemd
2👍238👎5
⇨ Authentik proxy outposts for Traefik, Docker and K8S
Судя по всему Authentik - самый популярный из бесплатных сервисов SSO. Про него последнее время попадается много материала. Указанное видео очень круто сделано. Автор по шагам показал, как настроить интеграцию Authentik с Docker, Traefik (только доступ в его веб интерфейс), Kubernetes. Для Docker настроен удалённый доступ к его сокету с аутентификацией через Authentik.
⇨ Authentik. Часть 2. Установка и обзор пользовательского интерфейса
⇨ Authentik. Часть 3. Аутентификация простых приложений
Тоже очередное видео про Authentik, только в данном случае на примере настройки аутентификации для сервисов, которые вообще её не имеют ни в каком виде. Для этого настраивается обратный прокси (Traefik), на котором осуществляется аутентификация с помощью Authentik.
🔥 Wazuh! Powerful, Open Source Endpoint Security Monitoring!
Очень основательный и подробный материал по настройке open source SIEM-системы - Wazuh. Тут и обзор и демонстрация возможностей, и установка, и настройка, и подключение агентов. И всё это подробно. Очень качественный материал.
⇨ Safeline WAF надежная защита для вашего сайта сервера и данных
Автор сделал обзор на бесплатную версию Safeline WAF, про которую я недавно писал.
⇨ Практика по HTTP API | Компьютерные сети 2025 - 15
⇨ HTTP API в Postman | Компьютерные сети 2025 - 16
Очередные уроки из бесплатного курса Андрея Созыкина по сетям. Автор показывает работу в программе Postman с HTTP API. Я, кстати, у себя на ноуте тоже обычно использую Postman, если надо много работать с API. Для одиночных запросов обычно использую curl.
⇨ Kutt URL Shortener: Easy Installation, Password Protection, and More!
Простенький обзор на небольшой сервис для сокращения ссылок со статистикой переходов по ним. В сервисе ничего особенного, но выглядит аккуратно и удобно.
⇨ Литературно-комиксовая зарисовка для любителей Mikrotik из современного словаря модных в IT слов
Теоретический доклад, который можно просто послушать, от системного администратора, devops инженера и любителя Mikrotik на тему применения всяких современных и модных штук в работе с сетями. Первые 15 минут мне не особо понравились, когда автор просто рассказывал известные вещи про devops. Дальше было более конкретно и интересно с примерами и описанием продуктов для бэкапа, мониторинга, логов и т.д.
⇨ Zellij - Powerful Productivity in your Terminal!
Подробный обзор программы Zellij - консольный мультиплексор, более современный и продвинутый аналог screen и tmux. Я пару раз писал про неё. Интересная штука, но лично я так и не стал пользоваться, так как пользуюсь не часто и в целом мне нет разницы что это - screen или tmux. Раньше использовал screen. Последнее время везде tmux ставлю.
⇨ GitLab CI/CD - Установка своего DOCKER GitLab Runner на LINUX
Продолжение серии уроков по использованию GitLab. Если вам интересна эта тема, то посмотрите предыдущие уроки автора. Их уже довольно много. Информация для новичков, даётся очень доступно, с теорией и практикой.
⇨ DeepSeek: Ваш персональный ИИ-помощник в мире технологий и не только
Обзор на китайский бесплатный аналог ChatGPT - DeepSeek. Автор в восторге от его работы. Рекомендует. Я лично не пользовался, но надо попробовать.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Authentik proxy outposts for Traefik, Docker and K8S
Check out Twingate and supercharge your security: https://bit.ly/3Y1OaZi
In this video, I will guide you through the process of using Authentik Proxy Outposts with Traefik, Docker, and Kubernetes. We'll dive into how to connect Authentik, a powerful open…
In this video, I will guide you through the process of using Authentik Proxy Outposts with Traefik, Docker, and Kubernetes. We'll dive into how to connect Authentik, a powerful open…
👍65👎2
В выходной для разнообразия подниму тему, которая не относится к технической части, но тем не менее будет полезна любому специалисту. Последнее время смотрел много видео на тему того, как современные системные администраторы, devops инженеры и программисты ищут работу. Не знаю, зачем мне это надо. Сам работу искать не собираюсь. Было просто интересно.
По знаниям и техническим подробностям ничего говорить не буду, это и так известная информация, которую легко найти. Расскажу немного о другом. Причём не только со стороны соискателя, но и со стороны работодателя. У меня был опыт, и не очень маленький, когда нужно было закрывать вакансии сисадминов. Я составлял вакансии, проводил собеседования. Иногда прям на потоке по 5-6 человек в день. Довольно утомительное занятие. Тогда я понял, почему люди редко дают обратную связь, когда тебе отказывают. Мало того, что это банально занимает твоё время, так ещё и надо не забыть, почему конкретному человеку ты отказал. А когда было 10-15 собеседований, выбрал ты одного, остальным 14-ти уже трудно каждому написать и объяснить, почему не подошёл. Просто кто-то был лучше.
На собеседованиях часто задают примерно такие вопросы:
❓Какое у тебя было самое большое достижение на прошлой или ещё раньше, работе?
❓Какой был самый большой провал и какие из него были сделаны выводы?
❓Как развиваетесь, повышаете свои навыки? Что последнее изучили, внедрили новое?
Когда тебе надо искать работу и обновлять резюме, затруднительно всё это сразу вспомнить и хорошо написать. Вместо этого я вам советую вести своё резюме в режиме реального времени. Постоянно записывать свои достижения, провалы, полученные навыки, прохождение курсов или изучение чего-то нового пусть даже по видео из Youtube.
Готовый список из описанных событий позволит быстро скомпоновать резюме под конкретные задачи или вакансии. Не обязательно там писать сразу всё. Просто сядьте и подумайте, для какой компании или вакансии было бы уместно указать те или иные достижения. В резюме стоит писать только их. А остальные вещи просто держать в голове и освежать знания перед собеседованиями, чтобы быстро и уверенно ответить, а не судорожно вспоминать, где же я там накосячил и как рассказать так, чтобы мне в итоге не отказали и не посчитали нубасом. Уверенно рассказать про свои косяки и выводы, которые из этого были сделаны, дорого стоит. Сходу может и не получиться.
Кому-то может показаться, что он ничего особенного не делал и писать в достижениях нечего. Вряд ли это так на самом деле, если вы реально занимались работой, а не били баклуши. Наверняка внедряли или дорабатывали систему мониторинга, переносили какие-то сервисы или сервера, настраивали бэкапы и проверяли их. Вот об этом кратко и пишите сразу, как сделаете. Что-то типа такого:
Без остановки производственного процесса выполнил миграцию рабочей нагрузки на новое железо. Предварительно провёл анализ нагрузки, рассчитал бюджет под новое железо, обосновал его. Сделал предварительную настройку, тестовое перемещение работающих сервисов. Составил подробный план. В запланированное время выполнил успешную миграцию.
Это и на текущей работе сможет помочь. Например, если вас просят на какой-нибудь аттестации или просто разговоре с руководством, чем вы, собственно, занимаетесь и почему вам стоит поднять зарплату. А вы сразу готовый список покажете своих достижений, даже если кажется, что это обычная рутина. Но даже хорошо выполняемую рутину можно оформить как достижение.
В общем, заведите себе какой-то документ в своих заметках и пишите там основные вехи в своей деятельности. Это займёт буквально 5 минут в неделю, но сильно поможет как минимум в поиске работе, а скорее всего и на текущем рабочем месте.
К слову, большинство людей, с которыми я беседовал, раньше явно такой список не готовили и начинали плавать в этих очень простых вопросах, которые стоит проработать заранее и подать себя в лучшем виде.
#разное
По знаниям и техническим подробностям ничего говорить не буду, это и так известная информация, которую легко найти. Расскажу немного о другом. Причём не только со стороны соискателя, но и со стороны работодателя. У меня был опыт, и не очень маленький, когда нужно было закрывать вакансии сисадминов. Я составлял вакансии, проводил собеседования. Иногда прям на потоке по 5-6 человек в день. Довольно утомительное занятие. Тогда я понял, почему люди редко дают обратную связь, когда тебе отказывают. Мало того, что это банально занимает твоё время, так ещё и надо не забыть, почему конкретному человеку ты отказал. А когда было 10-15 собеседований, выбрал ты одного, остальным 14-ти уже трудно каждому написать и объяснить, почему не подошёл. Просто кто-то был лучше.
На собеседованиях часто задают примерно такие вопросы:
❓Какое у тебя было самое большое достижение на прошлой или ещё раньше, работе?
❓Какой был самый большой провал и какие из него были сделаны выводы?
❓Как развиваетесь, повышаете свои навыки? Что последнее изучили, внедрили новое?
Когда тебе надо искать работу и обновлять резюме, затруднительно всё это сразу вспомнить и хорошо написать. Вместо этого я вам советую вести своё резюме в режиме реального времени. Постоянно записывать свои достижения, провалы, полученные навыки, прохождение курсов или изучение чего-то нового пусть даже по видео из Youtube.
Готовый список из описанных событий позволит быстро скомпоновать резюме под конкретные задачи или вакансии. Не обязательно там писать сразу всё. Просто сядьте и подумайте, для какой компании или вакансии было бы уместно указать те или иные достижения. В резюме стоит писать только их. А остальные вещи просто держать в голове и освежать знания перед собеседованиями, чтобы быстро и уверенно ответить, а не судорожно вспоминать, где же я там накосячил и как рассказать так, чтобы мне в итоге не отказали и не посчитали нубасом. Уверенно рассказать про свои косяки и выводы, которые из этого были сделаны, дорого стоит. Сходу может и не получиться.
Кому-то может показаться, что он ничего особенного не делал и писать в достижениях нечего. Вряд ли это так на самом деле, если вы реально занимались работой, а не били баклуши. Наверняка внедряли или дорабатывали систему мониторинга, переносили какие-то сервисы или сервера, настраивали бэкапы и проверяли их. Вот об этом кратко и пишите сразу, как сделаете. Что-то типа такого:
Без остановки производственного процесса выполнил миграцию рабочей нагрузки на новое железо. Предварительно провёл анализ нагрузки, рассчитал бюджет под новое железо, обосновал его. Сделал предварительную настройку, тестовое перемещение работающих сервисов. Составил подробный план. В запланированное время выполнил успешную миграцию.
Это и на текущей работе сможет помочь. Например, если вас просят на какой-нибудь аттестации или просто разговоре с руководством, чем вы, собственно, занимаетесь и почему вам стоит поднять зарплату. А вы сразу готовый список покажете своих достижений, даже если кажется, что это обычная рутина. Но даже хорошо выполняемую рутину можно оформить как достижение.
В общем, заведите себе какой-то документ в своих заметках и пишите там основные вехи в своей деятельности. Это займёт буквально 5 минут в неделю, но сильно поможет как минимум в поиске работе, а скорее всего и на текущем рабочем месте.
К слову, большинство людей, с которыми я беседовал, раньше явно такой список не готовили и начинали плавать в этих очень простых вопросах, которые стоит проработать заранее и подать себя в лучшем виде.
#разное
3👍161👎5
Для управления простым в установке и настройке VPN туннелем WireGuard существует много веб-панелей. Про некоторые я уже писал ранее. Недавно перебирал свои черновики и нашёл ещё один проект, который раньше не пробовал. Я развернул и настроил сервер с Wireguard буквально за несколько минут. Установка и настройка очень простые, а возможностей достаточно не только для управления клиентами, но и настройками самого сервера.
❗️Сразу скажу, что это решение не для обхода блокировок и замедлений, а для доступа к закрытым сетям. Не надо писать о том, что WG блокируют провайдеры. Внутри РФ у меня нет с этим проблем. Во время написания заметки пробовал подключаться и через смартфон, и через проводной интернет дома и на работе. У меня не возникает проблем с подключением ни по WG, ни по OVPN. Я пользуюсь ими постоянно во время работы. Иногда бывают проблемы на мобильном интернете, но так было всегда, а не только последнее время.
Оформил всё это дело в короткую заметку, по которой простым копированием команд можно быстро настроить свой сервер и запустить в работу. Настраивать буду, как обычно, на Debian 12.
Устанавливаем необходимые пакеты:
Сразу разрешим пересылку пакетов между сетевыми интерфейсами. Иногда забываю это сделать, а потом долго разбираюсь, почему ничего не работает.
Скачиваем wireguard-ui в ту же директорию, где живут настройки службы WG:
Запускаем wireguard-ui, ждём несколько секунд, чтобы она создала конфигурацию для службы:
Останавливаем wireguard-ui. Нажимаем в консоли
Запускаем службу WireGuard:
Проверяем, что интерфейс wg0 поднялся и правила iptables добавились:
Веб-панель умеет вносить изменения в настройки WG, но не умеет перезапускать службу. Воспользуемся возможностями SystemD.Path для автоматического перезапуска туннеля после изменения файла конфигурации. Создаём файл /etc/systemd/system/wgui.path:
И саму службу /etc/systemd/system/wgui.service:
Запускаем их:
Сделаем отдельный юнит для автозапуска wireguard-ui после старта машины /etc/systemd/system/wireguard-ui.service:
Запускаем и добавляем в автозапуск одновременно:
Идём в веб интерфейс по IP адресу сервера на порт 5000. Учётка по умолчанию - admin / admin. Базовые настройки сервера мы уже сделали. Можно добавлять пользователей и подключаться. При необходимости можно изменить настройки сервера. Не забудьте изменить учётную запись администратора.
⇨ 🌐 Исходники
📌Полезные материалы на тему использования WG:
◽️Wireproxy - socks5/http прокси на базе WG
◽️TunnlTo - управление маршрутами в туннели WG на основе приложений
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#wireguard #vpn
❗️Сразу скажу, что это решение не для обхода блокировок и замедлений, а для доступа к закрытым сетям. Не надо писать о том, что WG блокируют провайдеры. Внутри РФ у меня нет с этим проблем. Во время написания заметки пробовал подключаться и через смартфон, и через проводной интернет дома и на работе. У меня не возникает проблем с подключением ни по WG, ни по OVPN. Я пользуюсь ими постоянно во время работы. Иногда бывают проблемы на мобильном интернете, но так было всегда, а не только последнее время.
Оформил всё это дело в короткую заметку, по которой простым копированием команд можно быстро настроить свой сервер и запустить в работу. Настраивать буду, как обычно, на Debian 12.
Устанавливаем необходимые пакеты:
# apt install wireguard iptablesСразу разрешим пересылку пакетов между сетевыми интерфейсами. Иногда забываю это сделать, а потом долго разбираюсь, почему ничего не работает.
# echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf# sysctl -pСкачиваем wireguard-ui в ту же директорию, где живут настройки службы WG:
# cd /etc/wireguard# wget https://github.com/ngoduykhanh/wireguard-ui/releases/download/v0.6.2/wireguard-ui-v0.6.2-linux-amd64.tar.gz# tar -xzvf wireguard-ui-v0.6.2-linux-amd64.tar.gzЗапускаем wireguard-ui, ждём несколько секунд, чтобы она создала конфигурацию для службы:
# ./wireguard-uiОстанавливаем wireguard-ui. Нажимаем в консоли
Ctrl+C. Сразу добавим необходимые параметры в /etc/wireguard/wg0.conf:PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE;PostDown = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE;Запускаем службу WireGuard:
# systemctl enable --now [email protected]Проверяем, что интерфейс wg0 поднялся и правила iptables добавились:
# ip a | grep wg# iptables -L -v -n -t nat | grep MASQUERADEВеб-панель умеет вносить изменения в настройки WG, но не умеет перезапускать службу. Воспользуемся возможностями SystemD.Path для автоматического перезапуска туннеля после изменения файла конфигурации. Создаём файл /etc/systemd/system/wgui.path:
[Unit]Description=Watch /etc/wireguard/wg0.conf for changes[Path]PathModified=/etc/wireguard/wg0.conf[Install]WantedBy=multi-user.targetИ саму службу /etc/systemd/system/wgui.service:
[Unit]Description=Restart WireGuardAfter=network.target[Service]Type=oneshotExecStart=/usr/bin/systemctl restart [email protected][Install]RequiredBy=wgui.pathЗапускаем их:
# systemctl enable wgui.{path,service}# systemctl start wgui.{path,service}Сделаем отдельный юнит для автозапуска wireguard-ui после старта машины /etc/systemd/system/wireguard-ui.service:
[Unit]Description=WireGuard UI ServiceAfter=network.target[Service]Type=simpleUser=rootWorkingDirectory=/etc/wireguardExecStart=/etc/wireguard/wireguard-uiRestart=on-failure[Install]WantedBy=multi-user.targetЗапускаем и добавляем в автозапуск одновременно:
# systemctl enable --now wireguard-ui.serviceИдём в веб интерфейс по IP адресу сервера на порт 5000. Учётка по умолчанию - admin / admin. Базовые настройки сервера мы уже сделали. Можно добавлять пользователей и подключаться. При необходимости можно изменить настройки сервера. Не забудьте изменить учётную запись администратора.
⇨ 🌐 Исходники
📌Полезные материалы на тему использования WG:
◽️Wireproxy - socks5/http прокси на базе WG
◽️TunnlTo - управление маршрутами в туннели WG на основе приложений
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#wireguard #vpn
1👍170👎5
Коротенькая заметка для пользователей Windows. Никогда не знал, что можно сделать вот так:
Вы только что подключили сетевой диск с набором всех утилит от sysinternals. Теперь их не надо отдельно качать и запускать.
Для тех, кто не знает и не слышал об утилитах sysinternals, поясню. Это очень старый и известный набор программ для управления и администрирования систем Windows. Наиболее известные и полезные по моему мнению там следующие вещи:
◽️procexp.exe - менеджер процессов, где можно посмотреть очень подробную информацию обо всех процессах, особенно системных, которые называются одинаково, но запущены с разными ключами. Там можно потоки, зависимости, открытые соединения и многое другое увидеть;
◽️tcpview.exe - менеджер сетевых соединений, показывает какие приложения и куда открыли сетевые соединения, их статус, порт и т.д.;
◽️Autoruns.exe - подробная информация об автозагрузке;
Там много всего интересного, не буду сильно грузить, так как список большой, можно на сайте всё посмотреть. Там структурированный список по типам программ, с описанием.
Запускаем, соответственно, так:
Когда поработаем, закрываем программу и отключаем диск:
#windows
>net use S: https://live.sysinternals.com/toolsКоманда выполнена успешно.Вы только что подключили сетевой диск с набором всех утилит от sysinternals. Теперь их не надо отдельно качать и запускать.
Для тех, кто не знает и не слышал об утилитах sysinternals, поясню. Это очень старый и известный набор программ для управления и администрирования систем Windows. Наиболее известные и полезные по моему мнению там следующие вещи:
◽️procexp.exe - менеджер процессов, где можно посмотреть очень подробную информацию обо всех процессах, особенно системных, которые называются одинаково, но запущены с разными ключами. Там можно потоки, зависимости, открытые соединения и многое другое увидеть;
◽️tcpview.exe - менеджер сетевых соединений, показывает какие приложения и куда открыли сетевые соединения, их статус, порт и т.д.;
◽️Autoruns.exe - подробная информация об автозагрузке;
Там много всего интересного, не буду сильно грузить, так как список большой, можно на сайте всё посмотреть. Там структурированный список по типам программ, с описанием.
Запускаем, соответственно, так:
> S:> procexp64.exeКогда поработаем, закрываем программу и отключаем диск:
> net use S: /delete#windows
13👍365👎5
Последнее время регулярно сталкиваюсь со следующей проблемой. Помимо того, что многие репозитории заблокированы для IP адресов из РФ, так ещё и скорость загрузки с открытых репозиториев падает иногда до 30-50 кБ/c. Причём не понятно наверняка, где и кто режет скорость. Помогает отмена загрузки или обновления и новый запуск. Иногда с первой, иногда со второй попытки скорость восстанавливается до более приемлемых значений.
Сталкивался во время стандартных обновлений Debian из её базовых реп, с установкой Zabbix, с загрузкой через wget софта с github. Заметил, что конкретно с Debian часто спотыкаешься на загрузке ядра.
Один из вариантов решения данной проблемы - использовать репозитории, которые гарантированно не режут тебе скорость и не блокируют запросы. Могу предложить 2 репозитория, которые закроют практически все потребности:
▪️ https://mirror.yandex.ru
▪️ https://mirrors.huaweicloud.com
Единственный момент, я не понял, где в этих копиях репозиториев искать ключи, которыми подписаны пакеты, если они не лежат в самих репозиториях. Можно сходить на оригинальный репозиторий и скопировать оттуда, но это лишние хлопоты. Так что показываю пример, как подключать их в Debian, без проверки подписи и с ней, используя скачанный оригинальный ключ. Сделать это можно с любой машины, которая имеет к ним доступ.
Проверяем:
Есть пакет свежей версии из подключенного репозитория.
Если для вас вариант с
Теперь никаких предупреждений и проблем с безопасностью быть не должно. Вы точно будете уверены, что устанавливаете оригинальные пакеты.
У Яндекса не увидел зеркала Zabbix, поэтому подключим его зеркало из huaweicloud, используя оригинальный ключ:
По аналогии можно подключать любые другие репозитории. Может знаете ещё какие-то публичные репозитории, с которыми нет проблем?
#apt
Сталкивался во время стандартных обновлений Debian из её базовых реп, с установкой Zabbix, с загрузкой через wget софта с github. Заметил, что конкретно с Debian часто спотыкаешься на загрузке ядра.
Один из вариантов решения данной проблемы - использовать репозитории, которые гарантированно не режут тебе скорость и не блокируют запросы. Могу предложить 2 репозитория, которые закроют практически все потребности:
▪️ https://mirror.yandex.ru
▪️ https://mirrors.huaweicloud.com
Единственный момент, я не понял, где в этих копиях репозиториев искать ключи, которыми подписаны пакеты, если они не лежат в самих репозиториях. Можно сходить на оригинальный репозиторий и скопировать оттуда, но это лишние хлопоты. Так что показываю пример, как подключать их в Debian, без проверки подписи и с ней, используя скачанный оригинальный ключ. Сделать это можно с любой машины, которая имеет к ним доступ.
# echo "deb [trusted=yes] https://mirror.yandex.ru/mirrors/elastic/8/ stable main" > /etc/apt/sources.list.d/elastic.listПроверяем:
# apt update# apt search --names-only ^elasticsearch# apt show elasticsearchЕсть пакет свежей версии из подключенного репозитория.
Если для вас вариант с
trusted=yes неприемлем, то вручную качаем файл https://artifacts.elastic.co/GPG-KEY-elasticsearch и копируем на целевые машины. Далее конвертируем его в бинарник под современный формат и используем:# gpg --dearmor < GPG-KEY-elasticsearch > /etc/apt/keyrings/GPG-KEY-elasticsearch.gpg# echo "deb [signed-by=/etc/apt/keyrings/GPG-KEY-elasticsearch.gpg] https://mirror.yandex.ru/mirrors/elastic/8/ stable main" > /etc/apt/sources.list.d/elastic.listТеперь никаких предупреждений и проблем с безопасностью быть не должно. Вы точно будете уверены, что устанавливаете оригинальные пакеты.
У Яндекса не увидел зеркала Zabbix, поэтому подключим его зеркало из huaweicloud, используя оригинальный ключ:
# wget https://repo.zabbix.com/zabbix-official-repo-apr2024.gpg# gpg --dearmor < zabbix-official-repo-apr2024.gpg > /etc/apt/keyrings/GPG-KEY-zabbix# echo "deb [signed-by=/etc/apt/keyrings/GPG-KEY-zabbix] https://mirrors.huaweicloud.com/zabbix/zabbix/7.0/debian bookworm main" > /etc/apt/sources.list.d/zabbix.listПо аналогии можно подключать любые другие репозитории. Может знаете ещё какие-то публичные репозитории, с которыми нет проблем?
#apt
103👍129👎7
На прошлой неделе смотрел видео про необычную систему под названием Pangolin. Не стал про него упоминать, потому что толком не понял, что это за штука, хоть и подозревал, что что-то полезное. В итоге я её развернул, разобрался, как работает, и теперь расскажу своими словами. Это очень крутой и полезный софт, который, думаю, многим пригодится.
Pangolin - обратный прокси на базе Traefik со своей системой аутентификации или IAM (Identity and Access Management). Он способен объединять разрозненные веб сервера с помощью встроенной интеграции с Wireguard. Расскажу сразу на конкретном примере, как это работает.
Допустим у вас есть веб сервер с каким-то сайтом или другим веб-приложением, к которому вы хотите ограничить доступ, так как у него нет своей аутентификации, или вы просто хотите его скрыть от посторонних глаз. Рассказываю по шагам, что вам нужно будет сделать.
1️⃣ Покупаете или создаёте любую VPS с внешним IP и настроенной DNS записью. Устанавливаете туда Pangolin.
2️⃣ Создаёте в веб панели Pangolin так называемый сайт, что на самом деле означает отдельный веб сервер.
3️⃣ Получаете в Pangolin параметры подключения внешнего веб сервера к серверу с Pangolin. Он может использовать как стандартный WireGuard клиент, так и свой собственный под названием Newt. Это консольная программа, не требующая для установки туннеля прав root. В Pangolin вы получите готовую строку подключения типа:
для подключения веб сервера к Pangolin.
4️⃣ После того, как веб сервер подключится к Pangolin, создаёте у него в веб интерфейсе новый ресурс, который по сути является сайтом, к которому нужно ограничить доступ. Указываете URL, по которому он должен отвечать, IP адрес и порт на веб сервере, куда будут проксироваться запросы.
5️⃣ Меняете DNS запись сайта на IP адрес сервера Pangolin. Теперь он будет перенаправлять все запросы через WG туннель настроенного урла на веб сервер. То есть работает как обычный обратный прокси, только все запросы к веб серверу заворачивает в VPN.
6️⃣ В свойствах сайта в веб интерфейсе Pangolin настраиваете параметры доступа. Это может быть пользователь или роль на самом Pangolin, одиночный пароль или 6-ти значный PIN код.
7️⃣ Теперь при открытие настроенного урла, запрос будет уходить на сервер Pangolin. После успешной аутентификации запрос будет перенаправлен на веб сервер.
Всё это работает по HTTPS, сертификаты Let's Encrypt получаются автоматически. Сервер Pangolin собран в Docker контейнеры. Можно запускать его вручную через Docker Compose или использовать готовый установщик:
Я развернул, довольно быстро разобрался и закрыл аутентификацией тестовый сайт, который запустил на этом же VPS через Nginx на других портах. Каких-то особых проблем не было.
Я не раз видел в чате вопросы на тему того, как закрыть аутентификацией сайт, в котором её нет. До этого я рекомендовал взять Authentik, настроить там интеграцию с каким-то обратным прокси и его basic_auth и таким образом закрыть доступ. Но этот путь гораздо сложнее того, что я описал сейчас. Тут всё проще и быстрее. Разворачиваете Pangolin, создаёте пользователей, настраиваете проксирование и закрываете доступ к сайту.
⇨ 🌐 Сайт / Исходники / Видеообзор
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#webserver #wireguard #traefik #sso
Pangolin - обратный прокси на базе Traefik со своей системой аутентификации или IAM (Identity and Access Management). Он способен объединять разрозненные веб сервера с помощью встроенной интеграции с Wireguard. Расскажу сразу на конкретном примере, как это работает.
Допустим у вас есть веб сервер с каким-то сайтом или другим веб-приложением, к которому вы хотите ограничить доступ, так как у него нет своей аутентификации, или вы просто хотите его скрыть от посторонних глаз. Рассказываю по шагам, что вам нужно будет сделать.
# newt --id qqsyaa51zaovqdn --secret wyfbohgwk1uohzj2u8n2t4xn9gny9czgw7jmx3dk1nys755r --endpoint https://336261.simplecloud.ruдля подключения веб сервера к Pangolin.
Всё это работает по HTTPS, сертификаты Let's Encrypt получаются автоматически. Сервер Pangolin собран в Docker контейнеры. Можно запускать его вручную через Docker Compose или использовать готовый установщик:
# wget -O installer "https://github.com/fosrl/pangolin/releases/download/1.0.0-beta.8/installer_linux_amd64" && chmod +x ./installerЯ развернул, довольно быстро разобрался и закрыл аутентификацией тестовый сайт, который запустил на этом же VPS через Nginx на других портах. Каких-то особых проблем не было.
Я не раз видел в чате вопросы на тему того, как закрыть аутентификацией сайт, в котором её нет. До этого я рекомендовал взять Authentik, настроить там интеграцию с каким-то обратным прокси и его basic_auth и таким образом закрыть доступ. Но этот путь гораздо сложнее того, что я описал сейчас. Тут всё проще и быстрее. Разворачиваете Pangolin, создаёте пользователей, настраиваете проксирование и закрываете доступ к сайту.
⇨ 🌐 Сайт / Исходники / Видеообзор
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#webserver #wireguard #traefik #sso
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍165👎5
Сейчас хайпует тема с китайским ИИ - DeepSeek. Я тоже не удержался, начал использовать. Не нужна ни оплата, ни VPN, что удобно. В целом ничего особенного не увидел. По моим вопросам ChatGPT отвечал лучше.
Смысл хайпа по DeepSeek, как я понял в том, что он:
1️⃣ Open Source. Код открыт. Любой может развернуть и использовать по своему назначению, не отправляя свои вопросы во вне, не обучая чужие модели. Понятно, что большая модель требует очень много ресурсов и слово любой тут условно. Корпорации могут её забирать, использовать у себя, дорабатывать. Очень мощный удар под дых для коммерческих игроков рынка.
2️⃣ Работает быстрее на тех же мощностях, что конкуренты. Заявляют, что разница очень существенная. Не знаю, насколько это правда. Могут и лукавить. Сравнивать модели не такая простая задача. К тому же DeepSeek, насколько я понял, учился с использованием других ИИ, сравнивая свои ответы с ними. За счёт этого быстро развивался и требовал меньше ресурсов. В таком режиме удобно догонять, условно паразитируя на достижениях других, но трудно вырваться вперёд. Собственно, невозможно, не меняя подход.
DeepSeek уже сейчас без проблем можно установить на своё железо с помощью Ollama. Это бесплатная платформа для запуска различных моделей ИИ локально. Она уже поддерживает DeepSeek, так что установка очень простая:
И можете в консоли с ней общаться или установить какой-то веб интерфейс для привычного чата. Например, Chatbox. Это запуск самой маленькой модели deepseek-r1 1.5b. Она весит 1,1GB на диске и может быть запущена даже на ноутбуках и домашних компах. Полный список моделей и их размеры смотрите на сайте ollama.
Я прочитал всю ветку комментариев на Reddit по этой теме, где люди запускали те или иные модели у себя на компах. Сразу могу сказать, что всё, что вы запустите на одной, даже самой мощной видеокарте, будет так себе по сравнению с доступными публичными моделями. Запустить дома можно модели вплоть до 32b. Дальше уже нужны кластеры видеокарт для нормальной работы.
Я запускать у себя не стал, так как нет свободных серверов для этого. Раньше уже тестировал всё это. Вроде работает, но толку для личного использования нет. Бесплатные доступы к публичным моделям покрывают потребности, а бесплатных лимитов хватает за глаза.
Как вариант использования в личных целях может быть интеграция с сервисом заметок Blinko. Я про него писал. У него одна из фишек - интеграция с ИИ, в том числе запущенного на базе ollama. Возможно для поиска по своим заметкам будет достаточно и самой маленькой модели.
❗️В завершении скажу, что надо учиться работать в связке с ИИ. Я почти каждый день что-то спрашиваю у них по разным темам. Не могу сказать, что прям сильно помогает, но надо вырабатывать навык работы с ними. Уже явно видно, что за этим будущее. Важно только понимать, что они не заменяют людей, а повышают их продуктивность. Появление калькуляторов вместо счёт не заменило бухгалтеров. Их, возможно, даже больше стало. Но научиться пользоваться калькуляторами пришлось всем.
#AI
Смысл хайпа по DeepSeek, как я понял в том, что он:
1️⃣ Open Source. Код открыт. Любой может развернуть и использовать по своему назначению, не отправляя свои вопросы во вне, не обучая чужие модели. Понятно, что большая модель требует очень много ресурсов и слово любой тут условно. Корпорации могут её забирать, использовать у себя, дорабатывать. Очень мощный удар под дых для коммерческих игроков рынка.
2️⃣ Работает быстрее на тех же мощностях, что конкуренты. Заявляют, что разница очень существенная. Не знаю, насколько это правда. Могут и лукавить. Сравнивать модели не такая простая задача. К тому же DeepSeek, насколько я понял, учился с использованием других ИИ, сравнивая свои ответы с ними. За счёт этого быстро развивался и требовал меньше ресурсов. В таком режиме удобно догонять, условно паразитируя на достижениях других, но трудно вырваться вперёд. Собственно, невозможно, не меняя подход.
DeepSeek уже сейчас без проблем можно установить на своё железо с помощью Ollama. Это бесплатная платформа для запуска различных моделей ИИ локально. Она уже поддерживает DeepSeek, так что установка очень простая:
# curl -fsSL https://ollama.com/install.sh | sh# ollama pull deepseek-r1:1.5b# ollama run deepseek-r1:1.5bИ можете в консоли с ней общаться или установить какой-то веб интерфейс для привычного чата. Например, Chatbox. Это запуск самой маленькой модели deepseek-r1 1.5b. Она весит 1,1GB на диске и может быть запущена даже на ноутбуках и домашних компах. Полный список моделей и их размеры смотрите на сайте ollama.
Я прочитал всю ветку комментариев на Reddit по этой теме, где люди запускали те или иные модели у себя на компах. Сразу могу сказать, что всё, что вы запустите на одной, даже самой мощной видеокарте, будет так себе по сравнению с доступными публичными моделями. Запустить дома можно модели вплоть до 32b. Дальше уже нужны кластеры видеокарт для нормальной работы.
Я запускать у себя не стал, так как нет свободных серверов для этого. Раньше уже тестировал всё это. Вроде работает, но толку для личного использования нет. Бесплатные доступы к публичным моделям покрывают потребности, а бесплатных лимитов хватает за глаза.
Как вариант использования в личных целях может быть интеграция с сервисом заметок Blinko. Я про него писал. У него одна из фишек - интеграция с ИИ, в том числе запущенного на базе ollama. Возможно для поиска по своим заметкам будет достаточно и самой маленькой модели.
❗️В завершении скажу, что надо учиться работать в связке с ИИ. Я почти каждый день что-то спрашиваю у них по разным темам. Не могу сказать, что прям сильно помогает, но надо вырабатывать навык работы с ними. Уже явно видно, что за этим будущее. Важно только понимать, что они не заменяют людей, а повышают их продуктивность. Появление калькуляторов вместо счёт не заменило бухгалтеров. Их, возможно, даже больше стало. Но научиться пользоваться калькуляторами пришлось всем.
#AI
11👍192👎10
Давно заметил, что в Proxmox с какой-то версии в разделе настройки уведомлений появился тип Gotify. Его же видел в качестве поддерживаемых каналов доставки уведомлений в некоторых других сервиах. Сам никогда им не пользовался и вот решил повнимательнее посмотреть, что это такое.
Gotify – open source проект по доставке уведомлений. Это небольшой одиночный бинарник на Go, который собран даже под Windows. Он состоит из:
▪️API для приёма сообщений;
▪️веб интерфейса для управления и просмотра сообщений;
▪️Android клиента для получения сообщений и пушей на смартфоне.
То есть схема работы такая. Вы поднимаете свой сервер Gotify. Добавляете туда приложение, получаете для него токен. Идёте в тот же Proxmox, добавляете в качестве получения уведомлений Gotify сервер. Для этого нужно будет указать его URL и токен приложения. И всё. Теперь все уведомления от этого Proxmox будут в отдельном канале уведомлений в Gotify, где их можно будет просматривать. Если Gotify открыт в браузере, будете получать уведомления от браузера, если на смартфоне – от смартфона. Только надо не забыть его настроить, чтобы система позволяла работать приложению в фоне, чтобы приходили пуши.
Это почти то же самое, что и ntfy.sh, про который я когда-то рассказывал. Хотел дальше написать, что Gotify более популярный, но глянул звёзды на github, а у ntfy их 19.7k, против 11.9k у Gotify. Так что о популярности трудно так сказать. Тем не менее, не припоминаю, чтобы где-то видел явное указание поддержки ntfy, а вот Gotify встречал много раз.
Даже если в каком-то софте не заявлена поддержка Gotify, отправлять туда сообщения можно обычными веб хуками примерно так:
Из консоли или скриптов можно прямо бинарником Gotify-CLI отправлять уведомления:
Параметры URL и token указываются в конфигурационном файле, который формируется с помощью команды
Запустить сервер можно в Docker:
По умолчанию состояние хранится в sqlite3 базе. Можно настроить хранение в mysql или postgres. Параметры задаются в файле конфигурации сервера. Он небольшой, все значения описаны в документации. В проде сервер имеет смысл ставить за обратным прокси. Примеры настроек всех популярных веб серверов тоже есть в документации.
Пример того, как отправлять уведомления от Zabbix в Gotify через alertscripts. Задача скрипта преобразовать уровни значимости формата Zabbix в приоритеты Gotify. А дальше просто через curl отправка уведомлений.
Продукт простой и полезный. Позволяет с минимумом усилий навести порядок с уведомлениями от различных сервисов, выделив их в отдельный поток, не перемешивая с остальными уведомлениями на смартфоне или почте. Отлично изолирует работу от личной жизни. Не хватает только пересылки в какие-то другие системы. Gotify все уведомления замыкает на себя. Хотелось бы их ещё куда-то дублировать, если появится такая необходимость.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#мониоринг #zabbix
Gotify – open source проект по доставке уведомлений. Это небольшой одиночный бинарник на Go, который собран даже под Windows. Он состоит из:
▪️API для приёма сообщений;
▪️веб интерфейса для управления и просмотра сообщений;
▪️Android клиента для получения сообщений и пушей на смартфоне.
То есть схема работы такая. Вы поднимаете свой сервер Gotify. Добавляете туда приложение, получаете для него токен. Идёте в тот же Proxmox, добавляете в качестве получения уведомлений Gotify сервер. Для этого нужно будет указать его URL и токен приложения. И всё. Теперь все уведомления от этого Proxmox будут в отдельном канале уведомлений в Gotify, где их можно будет просматривать. Если Gotify открыт в браузере, будете получать уведомления от браузера, если на смартфоне – от смартфона. Только надо не забыть его настроить, чтобы система позволяла работать приложению в фоне, чтобы приходили пуши.
Это почти то же самое, что и ntfy.sh, про который я когда-то рассказывал. Хотел дальше написать, что Gotify более популярный, но глянул звёзды на github, а у ntfy их 19.7k, против 11.9k у Gotify. Так что о популярности трудно так сказать. Тем не менее, не припоминаю, чтобы где-то видел явное указание поддержки ntfy, а вот Gotify встречал много раз.
Даже если в каком-то софте не заявлена поддержка Gotify, отправлять туда сообщения можно обычными веб хуками примерно так:
# curl "https://gotify.example.com/message?token=<apptoken>" -F "title=my title" -F "message=my message" -F "priority=5"Из консоли или скриптов можно прямо бинарником Gotify-CLI отправлять уведомления:
# gotify push -t "my title" -p 10 "my message"# echo my message | gotify pushПараметры URL и token указываются в конфигурационном файле, который формируется с помощью команды
gotify init. Запустить сервер можно в Docker:
# docker run -p 80:80 -v /var/gotify/data:/app/data gotify/serverПо умолчанию состояние хранится в sqlite3 базе. Можно настроить хранение в mysql или postgres. Параметры задаются в файле конфигурации сервера. Он небольшой, все значения описаны в документации. В проде сервер имеет смысл ставить за обратным прокси. Примеры настроек всех популярных веб серверов тоже есть в документации.
Пример того, как отправлять уведомления от Zabbix в Gotify через alertscripts. Задача скрипта преобразовать уровни значимости формата Zabbix в приоритеты Gotify. А дальше просто через curl отправка уведомлений.
Продукт простой и полезный. Позволяет с минимумом усилий навести порядок с уведомлениями от различных сервисов, выделив их в отдельный поток, не перемешивая с остальными уведомлениями на смартфоне или почте. Отлично изолирует работу от личной жизни. Не хватает только пересылки в какие-то другие системы. Gotify все уведомления замыкает на себя. Хотелось бы их ещё куда-то дублировать, если появится такая необходимость.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#мониоринг #zabbix
2👍144👎2