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

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

В easypay: в начала файла easypay.pl:

Код:

my $account_field = 0; # 1: аккаунт - это логин клиента, 0: платежный код, 2: дополнительное поле
my $account_as_dopfield = '_adr_telefon'; # имя дополнительного поля когда $account_field = 2

В epay: в файла  epay.pl:

Код:

my $it = nod::paysystem->new(
     account_as_login => 1,

или

Код:

my $it = nod::paysystem->new(
     account_as_dopfield => '_adr_telefon',

В citypay, kaznachey аналогично epay.

а в Fondy можно сменить платежный код на логин?

С Fondy - автоматом перенаправляется из ЛК биллинга на оплату.

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

Кто-то в боевой режим уже внедрил?
Как успехи?

[в не истекшем лизинге]

Это все элементарные вещи и все это понятно. Не понятно как поведет себя аксель, когда у него в не истекшем лизинге будет выдан адрес на один мак а с этого же  порта придет снова запрос на новый адрес. А? обосрется  он как ISC-DHCPD или выдаст этот же адрес новому устройству. Сдается мне что обосрется. Тут только делать лизинг довольно коротким и ждать когда он закончится.

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

не факт ...

Зависит от версии платы.
На сайте циско эта проблема описана гдето, про буфферы.
Не на всех 48-х платах.
При трафике в 2,5 гига упирались в гиг, пока не разбросали по портам.

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

В аццеле при схеме влан на клиента работает всё хорошо, можно соседями ходить друг к другу со своими  ноутбуками.
У меня в процедурах проверяется номер влана, с которого пришёл запрос, а не мак абонента. Если этот влан на порту Б, без разницы что в него включать, абонент порта Б будет всегда получать адрес, основанный на влане, прописанном на порту и закреплённым за абонентом.
Если же прилетает несколько mac-адресов - настраивается в настройках аццеля, Replace/Reject/ либо shared (заменяем сессию если 2 мака, отбиваем её либо разрешаем выгребать адреса в одном влане).

Вопрос у кого агрегация выше гига не подымается.
Есть фигня с 48-портовыми платами.
Там группы интерфейсов группируются по 8.
Эти группы из 8 портов используют 1 общий буфер.
Если втыкнуть агрегацию из 4 портов подряд 1-4 или 5-8 то получите только 1Гбит/с трафика и не больше.
Чтобы трафик нормально пошёл - группируйте порты на циске.
Один порт сервака пихаете в первую группу портов (1-8), например в порт 1
Второй порт сервака пихаете во вторую группу портов (9-17), например в порт 9
и т.д. и будет всё нормально.
Если втыкать 4 порта подряд - то на выхлопе получите не больше гигабита, сталкивались уже 

Какую плату на 6500 используете?

Доброго времени суток!
Кто реально тестил работу плагина Fondy для работы с несколькими мерчантами?

Работаем с 3 мерчантами, всё хорошо.

Я так понимаю, у вас реализовано через Zabbix и каждого пользователя(надо добавлять вручную).

У меня мониторинг привязан к телеграм.
Скрипт был оттуда.

Код:

#!/usr/bin/env bash

TOKEN='тут мой токен'

which curl &>/tmp/telegram.log

if [ $? -ne 0 ] ; then echo 'FAIL: curl not found.' && exit 1 ; fi
if [ $# -ne 3 ] ; then echo 'FAIL: Params not defined.' && echo 'Usage: zabbix-to-telegram-notify.sh TelegramID Subject Message' && exit 1 ; fi

CHAT_ID="$1"
SUBJECT="$2"
MESSAGE="$3"

curl -s --header 'Content-Type: application/json' --request 'POST' --data "{\"chat_id\":\"${CHAT_ID}\",\"text\":\"${SUBJECT}\n${MESSAGE}\"}" "https   ://api.telegram.org/bot${TOKEN}/sendMessage" | $

if [ $? -eq 0 ] ; then exit 1 ; fi

Чтобы клиенту отправлять через телеграм
Клиент должен добавить чат id твоего чата
+ ты должен знать id-клиента в телеграмм.

Код:

#!/usr/bin/env bash

TOKEN='тут мой токен'

which curl &>/tmp/telegram.log

if [ $? -ne 0 ] ; then echo 'FAIL: curl not found.' && exit 1 ; fi
if [ $# -ne 3 ] ; then echo 'FAIL: Params not defined.' && echo 'Usage: zabbix-to-telegram-notify.sh TelegramID Subject Message' && exit 1 ; fi

CHAT_ID="$1"
SUBJECT="$2"
MESSAGE="$3"

curl -s --header 'Content-Type: application/json' --request 'POST' --data "{\"chat_id\":\"${CHAT_ID}\",\"text\":\"${SUBJECT}\n${MESSAGE}\"}" "https   ://api.telegram.org/bot${TOKEN}/sendMessage" | $

if [ $? -eq 0 ] ; then exit 1 ; fi

Кастомный кабинет.

На старых прошивках IPMI есть такой баг.

Проверка - виден ли ваш пароль через IMPI

Код:

 telnet ip_ipmi 49152
 GET /PSBlock

Если в ответе видишь свой пароль - обновляй firmwire IPMI.
+ На свиче навешивай access-list кому разрешен доступ по IPMI.

Я думаю баннер они могут видеть только при обращении на 80 порт.
И редирект раз в n минут обращения на 80 порт в заглушку, 443 при этом пропускать как обычно.