nShaper. Динамический шейпер для Linux.

Рано или поздно у многих встает вопрос грамотного распределения трафика в сети. А точнее шейпинга.  Особенно если в сети есть участники, качающие по протоколу bittorrent.  Во времена, когда интернет у меня раздавал роутер DIR-320 с Олеговской прошивкой, этот вопрос особенно остро и для меня встал, так как канал у меня был слабый. И вот однажды нашел на форуме, посвященному этой прошивке, замечательный скрипт с названием nShaper (тема тут). Это был динамический шейпер, суть которого сводилась в динамическом распределении ширины канала в зависимости от типа и источника/назначения трафика. То есть он сам распределял скорость, в зависимости какой трафик проходит. И не надо было отключать торрент клиент, если кому-то в сети захотелось посидеть в ютубе или послушать музыку. Шейпер урезал скорость торренту и оставлял гарантированную полосу для остального трафика.

Но вот роутер отправился на заслуженный покой, а на смешу пришел полноценный Linux шлюз с Ubuntu. Конечно захотелось и на нем использовать этот шайпер. Сразу он работать отказался. Тогда я уже взял в руки "напильник" и стал заниматься "адаптацией", а после и тестированием. По ходу так же немного расширил функционал, добавив создание правил с использованием nDpi и iptables, и приоритезация трафика на основе маркировки трафика (через тот же ndpi или iptables). Скрипт в 2 версиях, с nDpi и без, если кому-то  nDpi не нужен.

Скрипт состоит из 3 файлов. 2 конфиг. файла (nshaper.conf и ip_z1.lst) и самого скрипта (nshaper.sh). Первые 2 лежат в /etc/nshaper, второй в /etc/init.d/ соответственно (естественно надо дать права на запуск и закинуть в автозагрузку при желании).

Конфиг достаточно простой. Основные параметры:

WAN_IF — интерфейс интернет соединения (eth0, ppp0 и т.п)
LAN_IF — интерфейс локальной сети

Если провайдер использует так называемый Russian PPTP, то так же указываем
pptp_ip — сервер подключения pptp
PPTP_IF – название сетевого интерфейса, который смотрит в сеть провайдера (интерфейс, куда воткнут кабель провайдера)
В противном случае их нужно закомментировать.

WAN_DN_RATE — максимально возможная скорость. Не физическая! Например если есть локальные ресурсы, то та самая скорость в локальной сети (если она к примеру выше, чем скорость интернет тарифа). Если же локальных ресурсов нет, то выставляем максимальную скорость интернет соединения. (К примеру, у меня тариф 40мбит Интернет и пиринговые зоны со скоростью 100мбит. Мне надо выставить 100000. Значения в кбит)
WAN_UP_RATE — тоже самое, но для исходящего канала.


WAN_ZONES – название зон. Первая зона всегда остается inet. Вторая уже на Ваш вкус. Если  таких зон нет, то оставляем только inet
ZONE_PATH – каталог с файлами зон. (по умолчанию там же, где и сам конфиг, /etc/nshaper)

WAN_ZONES_DN_RATE, WAN_ZONES_UP_RATE – скорость интернет соединения (входящая и исходящая). Значения в кбит. Первая цифра, это скорость интернет соединения. Вторая и последующая -  для пиринговых зон. Если зон нет, то указываем только скорость тарифа. Например WAN_ZONES_UP_RATE="40000 100000" или WAN_ZONES_UP_RATE="40000" если нет локальных ресурсов.

В этом же блоке настраиваются скорости для тарифов с ночным увеличением. По комментариям в конфиге думаю все понятно.

RATES="10 10 20 40 15 5"
INET_NAMES="200 201 202 203 204 205"
Приоритеты. % от максимальной ширины канала и их названия. % в принципе редактировать нет необходимости. В данном случае для первого и второго приоритета резервируется 10% канала, для второго 20%, для третьего 40%, для четвертого 15% и для самого низкого 5%. Если в какой-то очереди трафика нет, то его ширина «отдается» остальным. Но если канал забит, то каждый получает свой минимум. То есть запусти вы хоть 100 закачек торрента, свои 40% ширины веб трафик получит. Если же торрентов нет, то веб возьмет все что свободно.
Второй параметр это название приоритетов. Видны при просмотре статуса. Можно как угодно называть. Например Prio, Web, Torrent и т. д.

Синтаксис правил в конфиге подробно описан. Если будут вопросы, отвечу в комментариях.

Теперь требования для работы скрипта.
Во первых (и самое главное) нужна поддержка IMQ. Для этого нужно патчить ядро. В принципе ничего сложного нет. Инструкция тут же в блоге. Она же включает и сборку nDpi (не обязательно).
Во вторых модуль nDpi (если он нужен конечно)
В третьих  gawk, conntrack и ipcalc (для корректной работы скрипта).

Запуск скрипта /etc/init.d/nshaper start либо start2 (если нужен полный вывод статистики, подробней читать в nshaper.conf). Просмотр статистики /etc/init.d/nshaper status.

По CPU особых требований нет. У меня на шлюзе слабый AMD E-350 без проблем «переваривает»  40мбит/с интернет трафика + еще 50-60 пирингового.

Скрипт возможно не идеален. Но работает.  Если есть замечания — буду рад исправить.

Версия с nDpi и без. Работоспособность проверял на Centos 7 и Ubuntu 12.04/14.04. Без проблем должно работать и в Debian.

UPD. Обновил. Теперь получение адресов и маски через ip, а не ifconfig.

Сборка accel-pptp под Ubuntu 14.04

Многие наверное в курсе, что родной pptp клиент в Ubuntu создает высокую нагрузку, при большом трафике. Поэтому было решено ставить accel-pptp. Поехали.

 cd /usr/src && sudo apt-get install pptp-linux build-essential gawk cmake 

 sudo apt source ppp

 git clone  https://github.com/winterheart/accel-pptp.git 

 sudo ln -s /usr/src/ppp-2.4.7/pppd /usr/src/accel-pptp/src/pppd && cd ./accel-pptp/

 cmake  -DPPP_PREFIX_DIR=/usr -DPPP_PLUGIN_PATH=/usr/src/accel-pptp/ppp-2.4.7/pppd

 make

 cp /usr/src/accel-pptp/pptp.so /usr/lib/pppd/2.4.7/

 modprobe pptp
 echo pptp >> /etc/modules

Остается только в файле настроек клиента убрать строку "pty "pptp....." и добавить

 plugin pptp.so  
 pptp_server XXX.XXX.XXX.XXX  

где XXX.XXX.XXX.XXX адрес pptp сервера. Так же в файлах options и options.pptp комментируем все строки lock

Centos, ndpi и imq. Обновлено 3.06.2015.

Сборка ядра для Centos с патчами IMQ и nDPI. 

Еще один мануал сборки ядра с Ndpi и imq. Теперь для Centos 7. Проверялся только под x64! Мануал максимально подробный, на уровне "копировать-вставить".

Переходим в домашний каталог и создаем необходимые директории

 cd ~/ 
 mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
 echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros 

Устанавливаем необходимые пакеты

 yum install rpm-build redhat-rpm-config asciidoc hmaccalc nano perl-ExtUtils-Embed pesign xmlto
 yum groupinstall "Development Tools"
 yum install audit-libs-devel binutils-devel elfutils-devel elfutils-libelf-devel zlib-devel
 yum install newt-devel numactl-devel pciutils-devel python-devel zlib-devel
 yum install ncurses-devel qt-devel bc libnetfilter_conntrack-devel  libnfnetlink-devel libpcap-devel net-tools wget libselinux-devel

Получаем исходники последнего ядра (на момент написания это 3.10.0-123.20.1) и патч  подправленный (с офф сайта патч выдавал режекты) IMQ.

 rpm -i http://vault.centos.org/7.0.1406/updates/Source/SPackages/kernel-3.10.0-123.20.1.el7.src.rpm 
 cd ~/rpmbuild/SPECS
 rpmbuild -bp --target=$(uname -m) kernel.spec
 cd ~/rpmbuild/SOURCES/ && wget https://www.dropbox.com/s/jay95g9tqbnhu29/linux-3.10-imq.diff

Переходим в каталог и копируем  конфиг

 cd ~/rpmbuild/BUILD/kernel-*/linux-*/
 /bin/cp configs/kernel-3.10.0-x86_64.config .config   

Подправим spec файл

 cd ~/rpmbuild/SPECS/  
 /bin/cp kernel.spec kernel.spec.back
 sed -i -e '5 s/^/%define buildid .IMQ\n/;' kernel.spec  
 sed -i -e '/Patch999999/i\Patch999998: linux-3.10-imq.diff' kernel.spec
 sed -i -e '/ApplyOptionalPatch linux-kernel-test.patch/i\ApplyOptionalPatch linux-3.10-imq.diff' kernel.spec

Накладываем патч IMQ и включаем модуль

 cd ~/rpmbuild/BUILD/kernel-*/linux-*/
 patch -p1 < ../../../SOURCES/linux-3.10-imq.diff
 make menuconfig

Device Drivers; Network Device Support;
[M] IMQ (intermediate queueing device) support

Networking Supportt; Networking Options; Network Packet Filtering Framework (Netfilter); Core Netfilter Configuration → "IMQ" Target Support

Подправим файл конфига

 sed -i -e '1 s/^/# x86_64\n/;' .config  

Копируем наши конфиги

 /bin/cp ./.config ../../../SOURCES/kernel-3.10.0-x86_64.config  
 /bin/cp ./.config ../../../SOURCES/kernel-3.10.0-x86_64-debug.config  

Ну и сборка

 cd ~/rpmbuild/SPECS/   
 rpmbuild -bb --without kabichk  --without debug --without debuginfo --target=`uname -m` kernel.spec  

После устанавливаем наше ядро.

 rpm -ivh --force ../RPMS/x86_64/kernel-*.rpm 

Перезагружаемся и проверяем

 reboot  
 modprobe xt_IMQ  
 lsmod | grep IMQ  

Если все нормально то увидим приблизительно следующее

 xt_IMQ         12532 0  

Теперь iptables.

 cd ~/ && rpm -ivh http://vault.centos.org/7.0.1406/os/Source/SPackages/iptables-1.4.21-13.el7.src.rpm 
 cd ~/rpmbuild/SPECS
 rpmbuild -bp  iptables.spec 
 cd ~/rpmbuild/SOURCES/ && wget https://www.dropbox.com/s/x2pvnznhq3z4jnt/imq-iptables-1.4.13.diff
 cd ~/rpmbuild/SPECS/

Подправим iptables.spec

 sed -i -e '/Patch1/a\Patch2: imq-iptables-1.4.13.diff' iptables.spec
 sed -i -e '/%patch1 -p1/a\%patch2 -p1 -b imq-iptables-1.4.13' iptables.spec

Теперь можем собрать и установить

 rpmbuild -bb iptables.spec  
 rpm -Uvh  ../RPMS/x86_64/iptables-*.rpm   

Далее xtables

 cd ~/  
 wget https://www.dropbox.com/s/l16zkc8gbubf9ae/xtables-addons-2.6.tar.xz  
 tar -xvf xtables-addons-2.6.tar.xz  
 cd xtables-addons-2.6  
 ./configure  
 make 
 make install 

Следующий шаг nDpi. Использоваться будет версия nDpi без патча ядра. Недостатком этого является отсутствие возможности использовать xt_connlabel. Если кому-то будет интересно, выложу дополнение по сборке с патчем.

 cd ~/  
 wget http://devel.aanet.ru/ndpi/nDPI-1.5.1.20150513.tar.gz  
 tar -xvzf nDPI-1.5.1.20150513.tar.gz && cd ./nDPI-1.5.1.20150513/ && ./autogen.sh && cd ./ndpi-netfilter/
 sed -i -e 's/net, __ndpi_free_flow, n)/net, __ndpi_free_flow, n, 0 ,0)/' src/main.c
 make
 make install  
 make modules_install  
 modprobe xt_ndpi    

Проверяем с помощью lsmod | grep xt_ndpi. Если все нормально то в выводе увидите xt_ndpi

Протоколы с которыми можно работать.

 iptables -m ndpi -h  

Как и в прошлый раз привожу ссылку на тему, с которой все началось. За патчи говорим спасибо Vel.

Полноценное тестирование не проводил. Максимум что я проверил - поднятие интерфейсов IMQ, перенаправление трафика с интерфейсов на IMQ и  1-2 правила nDpi с маркировкой. Поэтому если что-то работает не так просьба отписаться.

UPD. В новых патчах добавлен target Ndpi. Теперь можно упростить маркировки трафика или его классификацию. Например:

iptables -t mangle -A POSTROUTING -m ndpi --http -j MARK --set-mark 3  
iptables -t mangle -A POSTROUTING -m ndpi --http -j RETURN

Теперь можно записать как:

 iptables --t mangle -A POSTROUTING -m ndpi --proto bittorrent -j NDPI --value 3 --set-mark --ret  

А классификацию:

 iptables -t mangle -A POSTROUTING -m ndpi --bittorrent -j CLASSIFY --set-class 1:5  
 iptables -t mangle -A POSTROUTING -m ndpi --bittorrent -j RETURN  

Можно записать как:

 iptables -t mangle -A POSTROUTING -m ndpi --proto bittorrent -j NDPI --value 0X10005 --set-clsf --ret  

UPD2. Обновлено.  Цитата Vel

Большие изменения в BT: добавлен парсер сообщений (dht) и хеш для хранения ip:port получаемых парсером
По-умолчанию хеш отключен! Чтобы его включить нужно указать его размер 1-32 (параметр bt_hash_size). Число элементо хеша будет равно N*1024.
Кроме это можно указать время хранения данных в хеше 900-3600 секунд (параметр bt_hash_timeout)
Число хранимых элементов в хеше и другую информацию о хеше можно посмотреть в /proc/net/xt_ndpi/info
При тестировании на сети /24 с 300Мбитным трафиком число элементов было 0.8-1.2 миллиона элементов!
Каждый элемент - 24 байта!

Хэш включается командой  modprobe xt_ndpi bt_hash_size= bt_hash_timeout= подставив нужные значения  для bt_hash_size и bt_hash_timeout (Естественно если модуль уже был загружен до этого, то его надо выгрузить).

P.S.  Уважаемые копипастеры. Будьте добры указывать первоисточники. Хотя бы ссылку на тему https://www.linux.org.ru/forum/general/9685281

Уведомление занятости абонента при включенном Call Waiting в Asterisk.

     Наверное многие знают о существовании опции Call Waiting в Asterisk.  Функция конечно хорошая, но не без недостатка. Если абонент, кому звонят, понимает, что на второй линии другой абонент, на которого он в случае чего может переключиться, то звонящий же не узнает, разговаривает сейчас  абонент на другом конце или просто не отвечает на звонок. И, казалось бы, хорошая опция  этим недостатком может убить  все плюсы. По крайней мере в нашем офисе сотрудники часто были недовольны друг другом, думая что  на их звонки не отвечают.

     В конце концов  мне это надоело и решил искать решение. Нашел его достаточно быстро. Оказалось что я не один, кому не очень понравилась работа это функции. Решение нашел тут.

     Если  коротко, то в extensions_custom.conf надо добавить

  [from-internal-custom]  
 include => macro-dialout-one-predial-hook  
 [macro-dialout-one-predial-hook]   
  exten => s,1,Noop(DEVICE STATE - ${DEVICE_STATE(${DSTRING})})   
  exten => s,n,ExecIf($["${DEVICE_STATE(${DSTRING})}" = "INUSE"]?Playback(abonent_zanyat))   
  exten => s,n,ExecIf($["${DEVICE_STATE(${DSTRING})}" = "INUSE"]?Set(D_OPTIONS=Ttm))   
  exten => s,n,ExecIf($["${DEVICE_STATE(${DSTRING})}" = "RINGINUSE"]?Playback(abonent_zanyat))   
  exten => s,n,ExecIf($["${DEVICE_STATE(${DSTRING})}" = "RINGINUSE"]?Set(D_OPTIONS=Ttm))   

где abonent_zanyat название проигрываемого файла. Кстати саму начитку заказывать  у сторонних фирм не хотелось (уж больно много просят за пару слов), так что на помощь пришли онлайн синтезаторы речи. В частности этот. Текст был следующий: "В настоящий момент абонент разговаривает. Вы можете дождаться ответа или перезвонить позже." Сохранить файл можно с помощью инструментов разработки  браузера. При выборе голоса Milena получилось очень даже натурально. Был даже удивлен что не сразу и заметно, что это речь синтезатора (особенно если это услышать в трубке телефона).

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

     Сотрудники теперь довольны =)

UPD. Если у вас версия freepbx не самая свежая (например freepbx 2.11) то в файле ..admin/modules/core/functions.inc.php находим строку

 $ext->add($mcontext,$exten,'godial', new ext_dial('${DSTRING}', '${ARG1},${D_OPTIONS}'));  

и меняем на

 $ext->add($mcontext,$exten,'godial', new ext_execif('$["${QAGENT}"=""]', 'Macro', 'CHECK_DEVICE_STATE,')); 
 $ext->add($mcontext,$exten,'', new ext_dial('${DSTRING}', '${ARG1},${D_OPTIONS}'));  

В extensions_custom.conf в свою очередь контекс именуем не macro-dialout-one-predial-hook, а macro-CHECK_DEVICE_STATE

Ubuntu, imq, ndpi. Обновлено. 03.2021

Сборка ядра для Ubuntu с патчами IMQ и nDPI (UPD. Актуализировано под 18.04)

Очередное обновление от Vel
Проверенно на Ubuntu Server 18.04. (Для тех кто использует версию 16.04 придется скачивать/применять другие версии ядер/iptables/патчей. Думаю разберетесь)
Приступим:

1. Ставим необходимые пакеты.

 cd /usr/src/ && sudo apt-get install bc libnetfilter-conntrack-dev libnftnl-dev libssl-dev flex libmnl-dev libncurses5-dev bison libnfnetlink-dev linuxdoc-tools kernel-package dh-autoreconf dkms iptables-dev bzr libpcap-dev git arptables ebtables libjansson4 libmxml1 libnftnl7
 sudo apt-get build-dep iptables  

2. Скачиваем ядро 5.4.0.

sudo wget  http://security.ubuntu.com/ubuntu/pool/main/l/linux/linux-source-5.4.0_5.4.0-216.236_all.deb  
sudo dpkg -i ./linux-source-5.4.0_5.4.0-216.236_all.deb
sudo ln -s ./linux-source-5.4.0 ./linux  
sudo tar -xjf ./linux-source-5.4.0/linux-source-5.4.0.tar.bz2 &&  cd /usr/src/linux

3. Скачиваем подправленный IMQ патч

sudo wget https://raw.githubusercontent.com/imq/linuximq/master/kernel/v5.x/linux-5.4-imq.patch -O kernel.patch

4. Накладываем патч IMQ

sudo patch -p1 < ./kernel.patch

5. Включаем imq.  

sudo make menuconfig  

Device Drivers; Network Device Support;
[M] IMQ (intermediate queueing device) support

Networking Supportt; Networking Options; Network Packet Filtering Framework (Netfilter); Core Netfilter Configuration → "IMQ" Target Support

6. Начинаем сборку. Вместо 7 ставим количество своих ядер процессора + 1.

sudo CONCURRENCY_LEVEL=7 fakeroot make-kpkg --initrd --append-to-version=-v-ndpi+imq kernel-image kernel-headers  

7. Устанавливаем.

 sudo dpkg -i ../linux*.deb  

8. Перезагружаемся

 sudo reboot  

9. Следующим делом iptables. Скачиваем, патчим, собираем и устанавливаем(проверено на iptables версий 1.6.0):

cd /usr/src
sudo apt-get source iptables   
cd /usr/src/iptables-*/ 
sudo wget https://raw.githubusercontent.com/imq/linuximq/master/iptables/iptables-1.6.0-imq.diff
sudo patch -p1 < ./iptables-1.6.0-imq.diff  
sudo dpkg-buildpackage -rfakeroot -uc -b   
sudo dpkg -i ../iptables_*.deb   ../libxtables*.deb

10. Xtables-addons

sudo apt install xtables-addons-dkms xtables-addons-source xtables-addons-common

11. Теперь nDPI. Переходим в каталог и начинаем сборку

cd /usr/src  
sudo git clone https://github.com/vel21ripn/nDPI.git
cd ./nDPI && sudo ./autogen.sh
cd src/lib ; sudo make ndpi_network_list.c.inc 
cd ../../ndpi-netfilter  
sudo make   
sudo make install   
sudo make modules_install   
sudo modprobe xt_ndpi  

12. И проверяем с помощью lsmod | grep xt_ndpi. Если все нормально то в выводе увидите xt_ndpi

13. Протоколы с которыми можно работать.

 iptables -m ndpi -h  

Дальше их уже можно маркировать и скармливать Linux Traffic Control.  
Как и в прошлый раз привожу ссылку на тему, с которой все началось. За патчи говорим спасибо Vel.


UPD. В новых патчах добавлен target Ndpi. Теперь можно упростить маркировки трафика или его классификацию. Например:

iptables -t mangle -A POSTROUTING -m ndpi --http -j MARK --set-mark 3  
iptables -t mangle -A POSTROUTING -m ndpi --http -j RETURN

Теперь можно записать как:

 iptables --t mangle -A POSTROUTING -m ndpi --proto bittorrent -j NDPI --value 3 --set-mark --ret  

А классификацию:

 iptables -t mangle -A POSTROUTING -m ndpi --bittorrent -j CLASSIFY --set-class 1:5  
 iptables -t mangle -A POSTROUTING -m ndpi --bittorrent -j RETURN  

Можно записать как:

 iptables -t mangle -A POSTROUTING -m ndpi --proto bittorrent -j NDPI --value 0X10005 --set-clsf --ret  

UPD2. Обновлено.  Цитата Vel

Большие изменения в BT: добавлен парсер сообщений (dht) и хеш для хранения ip:port получаемых парсером
По-умолчанию хеш отключен! Чтобы его включить нужно указать его размер 1-32 (параметр bt_hash_size). Число элементо хеша будет равно N*1024.
Кроме это можно указать время хранения данных в хеше 900-3600 секунд (параметр bt_hash_timeout)
Число хранимых элементов в хеше и другую информацию о хеше можно посмотреть в /proc/net/xt_ndpi/info
При тестировании на сети /24 с 300Мбитным трафиком число элементов было 0.8-1.2 миллиона элементов!
Каждый элемент - 24 байта!

Хэш включается командой  modprobe xt_ndpi bt_hash_size= bt_hash_timeout= подставив нужные значения  для bt_hash_size и bt_hash_timeout (Естественно если модуль уже был загружен до этого, то его надо выгрузить).

UPD3. 13.01.2015.  Патчить ядро для nDpi больше не нужно. Только Imq. но нельзя при этом использовать connlabel. Если нужен connlabel, то нужно патчить ядро патчем из архива nDpi.

P.S.  Уважаемые копипастеры. Будьте добры указывать первоисточники. Хотя бы ссылку на тему https://www.linux.org.ru/forum/general/9685281

Мониторинг HASP ключей 1с в Zabbix

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

Велосипед изобретать не хотел. Поэтому первым делом начал искать готовые решения. Решения, которые   удовлетворяли бы меня, я не нашел. Но наткнулся на интересную тему на форуме Zabbix. Правда то решение мне не особо нравилось. Потому что практически на все у меня настроены LLD. Руками каждый раз вбивать элементы данные в какой-то момент мне надоело, и я настроил на все что мог LLD. Поэтому и для HASP я решил пойти этим путем.

Делать все будем на Windows сервере. В вышеприведенной ссылке один из участников форума написал небольшую программу, которая обращается к библиотеке hsmon.dll из состава Aladdin  Monitor. Ее и будем использовать. Так же нам понадобиться утилиты sed и grep. Чтоб не заниматься поиском, в конце будет ссылка на архив.

Итак. Предположим что zabbix-agent у нас в папке C:\zabbix. Создаем в этой папке еще одну папку и называем ее hasp. Содержимое архива кидаем туда. В конфиг zabbix добавляем строки

UserParameter=hasp_id,powershell -File "C:\zabbix\hasp\hasp.ps1" get_id
UserParameter=hasp_used[*],powershell -File "C:\zabbix\hasp\hasp.ps1" get_load $1 
UserParameter=hasp_max[*],powershell -File "C:\zabbix\hasp\hasp.ps1" get_max $1 

Скрипт занимается 2 вещами. Для начала он выводит в формате JSON ID ключей Hasp. Это необходимо для работы LLD. Если скрипту в качестве переменной передать ему get_load ID, то он выдаcт количество активных подключений. Если передать get_max ID, то выдаст еще и максимально возможное количество.

В самом Zabbix создаем шаблон. Называем как угодно, например Template Hasp. Переходим в Правила Обнаружения. Создаем новое. Пусть называется оно Hasp discovery. В графе ключ вписываем hasp_id, интервал 3600. Сохраняем. Дальше в прототипы данных. Создаем прототип. Назовем Hasp keys used for id {#ID}, ключ hasp_used[{#ID}], Интервал обновления можно 60 сек. И еще один такой же элемент, но с именем Hasp keys max for id {#ID}, а  в строке ключ hasp_max[{#ID}]. Первый покажет сколько занято. Второй максимальное количество. На основе этих элементов создаем график с таким же именем. В качестве прототипа выбираем наши созданные элементы данных. Так же можно создать триггер, который будет сравнивать текущее количество с максимальным. Как создавать такой триггер описывать не стану. Ничего сложного в этом нет.

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

UPD. Перевел на Powershell.  Архив обновил.

Не забываем разрешить выполнение скриптов Powershell.

Бэкап системы в "облако".

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

Для начала устанавливаем сам яндекс диск. Ничего сложного. Все подробно описано по ссылке http://help.yandex.ru/disk/cli-clients.xml

Теперь скрипт.

 #!/bin/sh  
 back=backup-`date '+%d-%B-%Y'`  
 yadisk=/media/yandex.disk/backup  
 cd /tmp  
 tar -cvpf ./fullbackup.tar --exclude=/proc --exclude=/dev --exclude=/media --exclude=/mnt --exclude=/proc --exclude=/sys --exclude=/temp --exclude=/tmp --exclude=/usr/src --exclude=/var/spool/squidcache /  
 cd $yadisk  
 7z a $back.7z -mx3 /tmp/fullbackup.tar -v200M  
 for i in `find * | grep -v "$back"`; do rm $i; done  
 rm -f /tmp/fullbackup.tar  

Где:

/media/yandex.disk/backup — каталог примонтированого яндекс диска.

backup-`date '+%d-%B-%Y'` — шаблон имени нашего бэкапа.

--exclude — каталоги, которые исключаем из архивирования. 

-mx3 — степень сжатия. Можно поставить mx7, уровень сжатия высокий, но и выполняться будет дольше. Мне достаточно и 3 уровня.

-v200M — разделяем на архивы по 200Mb (мне так удобней)

for i in `find * | grep -v "$back"`; do echo $i; done — удаляет предыдущий бэкап (чтоб не занимало место, на яндекс диск не так много и места, а каждый бэкап у меня занимает по 3 Gb =) ). Кому не нужно просто удаляем строку.

Не забывает делать его исполняемым. 

Сперва бэкапим все tar'ом (чтоб сохранились права доступа файлов), а потом сжимаем и делим все 7z. Все это закинул в крон, чтоб в раз в неделю запускался.