По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Как и любая современная АТС, Asterisk имеет свою встроенную систему хранения истории звонков - CDR (Call Detail Record). Она используется для снятия статистики, ведения отчетности, прослушивания вызовов или подсчета биллинговых показателей. В Asterisk для этого создана база данных asteriskcdrdb, в которой существует таблица cdr. Давайте рассмотрим как пользоваться данной таблицей и ее структуру. [root@asterisk]# mysql // подключаемся к MySQL После успешного подключения, необходимо выбрать для работы базу данных asteriskcdrdb: mysql> use asteriskcdrdb; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed Давайте убедимся, что у нас есть таблица cdr. Выполним это, как указано ниже: mysql> show tables; +-------------------------+ | Tables_in_asteriskcdrdb | +-------------------------+ | cdr | | cel | +-------------------------+ 2 rows in set (0.00 sec) На данном этапе мы убедились, что у нас есть база данных asteriskcdrdb, в которой находится таблица cdr. Давайте попробуем посмотреть входящие звонки из города за сегодня (дата написания статьи 18 марта 2016 года), в период с 12:00 до 12:10, т.е за 10 минут: SELECT `dst` , `src` , `duration` , `calldate` , `recordingfile` FROM `cdr` WHERE `calldate` >= '2016-03-18 12:00:00' AND `calldate` <= '2016-03-18 12:10:00' AND LENGTH( `src` ) >3; +-----+-------------+----------+---------------------+----------------------------------------------------------------+ | dst | src | duration | calldate | recordingfile | +-----+-------------+----------+---------------------+----------------------------------------------------------------+ | 113 | 84991111111 | 140 | 2016-03-18 12:00:36 | external-113-84991111111-20160318-115933-1458291573.157155.wav | | 104 | 89162222222 | 81 | 2016-03-18 12:01:33 | external-104-89162222222-20160318-120133-1458291693.157169.wav | +-----+-------------+----------+---------------------+----------------------------------------------------------------+ 2 rows in set (0.00 sec) В вышеуказанном примере, в SQL запросе указано LENGTH( `src` ) >3. Столбец ‘src’ – показывает номер звонящего (source - источник). Это сделано для того, чтобы исключить внутренние звонки, так как у нас используется трехзначная нумерация. Тем самым, мы получаем в результате данные, с которыми затем можем работать. Например, отправить на почту в виде отчета. Ниже рассмотрена структура таблицы cdr в базе данных asteriskcdrdb: Столбец Пример значения Описание calldate 2016-03-18 12:00:36 Дата и время звонка clid "Oleg Ivanov" <84991111111> В данное поле попадает полное CallerID (CLID, CID), которое состоит из имени и номера звонящего. Это доступно только для считывания. src 84991111111 Номер звонящего в конструкции CallerID (CNUM). Это доступно только для считывания. dst 113 Номер назначения для звонка. Это доступно только для считывания. dcontext CustomContext1 Контекст для обработки. Это доступно только для считывания. channel SIP/0002B2356854-a34bh3ef Канал, через который поступил звонок dstchannel SIP/0004F6675969-97836bb0 Канал, через который ушел исходящий звонок lastapp Dial, Busy, Congestion Приложение, которое последним отработало этот вызов перед попаданием в таблицу cdr lastdata SIP/0004F6675969,30,tT Аргумент, который был передан приложению, которое отработало вызов последним (lastapp) duration 75 Количество секунд от начала (отметка start) до окончания вызова (отметка end) billsec 67 Количество секунд от ответа (отметка answer) до окончания вызова (отметка end). Данное значение всегда меньше значения duration, и отражает длительность самого разговора, что важно для подсчета стоимости. disposition ANSWERED, BUSY, NO ANSWER, FAILED Результат звонка amaflags OMIT, BILLING, DOCUMENTATION, Unknown Метка Automatic Message Accounting (AMA) – автоматический учет стоимости вызова. accountcode 23232 Идентификатор аккаунта. Данное значение пустое по умолчанию, и определяется параметрами конкретного пользователя. uniqueid 1458291693.157169 Уникальный идентификатор звонка userfield - Пользовательское поле. Здесь можно передавать что угодно, добавляя данные в этот столбец при работе с вызовом внутри контекста обработки. did 4996491913 DID (Direct Inward Dialing). На основании DID вызова на Asterisk осуществляется его маршрутизация (это значение приходит от провайдера). recordingfile external-113-84991111111-20160318-115933-1458291573.157155.wav Имя файла, содержащего запись разговора. В данном имени можно проследить путь к файлу в файловой структуре сервера. cnum 84991111111 Номер звонящего в структуре CallerID. cnam Oleg Ivanov Имя звонящего в структуре CallerID. Теперь, когда вы понимаете принцип формирования запросов к базе данных и ее структуру, вы можете без труда формировать собственные отчеты. Например, ежедневный отчет о количестве входящих звонков за текущий день на почту. Это реализуется средствами php скрипта и добавления расписания через cron. Поговорим об этом в следующей статье
img
Kubernetes - это система с открытым исходным кодом, созданная для оркестровки, масштабирования и развертывания контейнерных приложений. Если вы хоть раз работали с Kubernetes, то знаете, насколько он полезен для управления контейнерами. Вы также знаете, что контейнеры не всегда работают должным образом. Если появляется сообщение об ошибке, вам нужен быстрый и простой способ решить проблему. Из этого туториала Вы узнаете, как перезапустить поды в Kubernetes. Под (Pod) – наименьшая запускаемая единица в ноде. Это группа контейнеров, которые должны работать вместе. Перезапуск подов Kubernetes Допустим, один из подов в вашем контейнере сообщает об ошибке. В зависимости от политики перезапуска Kubernetes может попытаться автоматически перезапустить под, чтобы он снова заработал. Однако это не всегда решает проблему. Если Kubernetes не может решить проблему самостоятельно, и вы не можете найти источник ошибки, перезапуск пода вручную - это самый быстрый способ вернуть приложение в рабочее состояние. Быстрое решение - вручную перезапустить затронутые поды. Это может сэкономить ваше время, особенно если ваше приложение работает и вы не хотите выключать службу. Вот три простых способа сделать это. Метод 1: Rolling Restart Начиная с обновления 1.15, Kubernetes позволяет выполнять непрерывный перезапуск развертывания. В качестве нового дополнения к Kubernetes это самый быстрый метод перезапуска. kubectl rollout restart deployment [deployment_name] Вышеупомянутая команда выполняет пошаговое завершение работы и перезапускает каждый контейнер в вашем развертывании. Ваше приложение по-прежнему будет доступно, поскольку большинство контейнеров все еще будут работать. Метод 2: Использование переменных среды Другой способ - установить или изменить переменную среды, чтобы поды перезагружались и синхронизировались с внесенными вами изменениями. Например, вы можете изменить дату развертывания контейнера: kubectl set env deployment [deployment_name] DEPLOY_DATE="$(date)" В приведенном выше примере набор команд env настраивает изменение переменных среды, развертывание [deployment_name] выбирает ваше развертывание, а DEPLOY_DATE="$(date) изменяет дату развертывания. Метод 3. Масштабирование количества реплик Наконец, вы можете использовать команду масштабирования, чтобы изменить количество реплик неисправного пода. Установка этого количества на ноль по существу отключает под: kubectl scale deployment [deployment_name] --replicas=0 Чтобы перезапустить под, используйте ту же команду, чтобы установить количество реплик на любое значение больше нуля: kubectl scale deployment [deployment_name] --replicas=1 Когда вы устанавливаете количество реплик равным нулю, Kubernetes уничтожает реплики, которые ему больше не нужны. Как только вы установите число больше нуля, Kubernetes создаст новые реплики. Новые реплики будут иметь другие имена, чем старые. Вы можете использовать команду kubectl get pods, чтобы проверить статус модулей и увидеть новые имена. Итог Kubernetes - чрезвычайно полезная система, но, как и любая другая система, она не безошибочна. Когда все же возникают проблемы, вы можете использовать три перечисленных выше метода, чтобы быстро и безопасно заставить ваше приложение работать, не закрывая службу для ваших клиентов.
img
Носки бывают чрезвычайно полезны. Сейчас мы расскажем, как правильно настроить их на роутере MikroTik. Итак, поговорим о SOCKS? Предисловие SOCKS (SOCKet Secure) – это сетевой протокол, с помощью которого можно обеспечивать прохождение TCP пакетов в обход блокирующих правил Firewall’а. Это реализуется за счёт proxy-сервера (также называют SOCKS-сервер), который контролирует подключение внутренних клиентов и их права на доступ к внешним ресурсам или же наоборот – внешних клиентов, к ресурсам внутри сети. SOCKS работает на сеансовом уровне, поэтому с помощью него можно проксировать FTP, HTTP, Telnet и другие верхнеуровневые протоколы. В то время как HTTP-прокси, как правило, позволяет проксировать только GET и POST запросы. Установление соединения Когда клиент хочет получить доступ к внешнему ресурсу, который блокирует Firewall, то соединение происходит следующим образом: Клиент подключается к proxy-серверу (обычно используется TCP порт 1080); Сервер проверяет список доступа и выясняет, есть ли у клиента права на доступ к внешним ресурсам; Если клиент имеет такие права, то proxy-сервер пересылает пакет на внешний ресурс, к которому хочет получить доступ клиент; Сервер создаёт сессию между клиентом и внешним ресурсом и между ними начинается обмен пакетами верхнеуровневых протоколов. После установления соединения можно передавать и UDP пакеты. В настоящее время, MikroTik поддерживает SOCKS версии 4 при указании внешнего ресурса он понимает только IP-адрес. Версия SOCKS4a – может резолвить доменные имена внешних ресурсов. Более поздняя версия протокола – SOCKS5 включает расширенную поддержку аутентификации, подключение по UDP и IPv6. На сегодняшний день, протокол SOCKS5 пока не поддерживается на устройствах MikroTik. Хотя пользователи очень просят разработчиков включить поддержку SOCKS5 в новые релизы RouterOS вот уже 8 лет. Поэтому при работе с SOCKS совместно с MikroTik, клиент также должен иметь 4 версию. Необходимо очень тщательно настроить Firewall'ьные правила и список доступа SOCKS чтобы исключить нежелательный доступ извне. Как правило, скомпрометированные через уязвимости SOCKS устройства, используются для рассылки спама и фишинговых писем. Перейдём к настройкам SOCKS-сервера на MikroTik: Параметры настройки через WinBox Параметры настройки SOCKS сервера в WinBox находятся в IP → Socks: Как только вы поставите галочку напротив Enabled сервер станет активным. Далее, необходимо настроить списки доступа, для этого нажимаем на кнопку Access: Активные SOCKS сессии, проходящие через сервер можно отслеживать на вкладке Connections Параметры настройки через Termial Для того, чтобы настроить SOCKS через терминал нужно также сначала настроить параметры сервера. Настройка проводится через команду ip socks set, доступы следующие параметры: enabled - включает функционал SOCKS proxy-сервера (yes - включен, no - выключен); port - номер порта, на котором сервер будет слушать SOCKS запросы. По умолчанию - 1080 connection-idle-timeout - время, через которое будут сброшены неактивные сессии (по умолчанию – 2 минуты (2m)); max-connections - максимальное число одновременных подключений (по умолчанию - 200) Посмотреть текущие или настроенные параметры можно командой: /ip socks print Далее необходимо настроить правила, по которым будет осуществляться контроль доступа к серверу SOCKS. Для этого вводим команду /ip socks access set, доступны следующие параметры: action - действие, которое будет предпринято при соответствии критериев данного правила: allow - разрешить прохождение трафика по данному правилу; deny - запретить прохождение трафика по данному правилу. dst-address - адрес сервера назначения; dst-port - TCP порт назначения, на котором удаленный сервер слушает SOCKS src-address - адрес источника пакетов (клиент); src-port - TCP порт источника Практическое применение Допустим злой сисадмин заблокировал наш любимый wiki.merionet.ru, выяснил адрес и забанил. О том, как настраивать правила Firewall в MikroTik читайте здесь Но одному нашему сотруднику обязательно нужно иметь доступ к данному ресурсу. Поэтому сисадмин открывает активирует SOCKS сервер и настраивает список доступа. В качестве адреса клиента указывается IP адрес компьютера сотрудника, которому нужно открыть доступ (в нашем случае 192.168.11.48), в качестве порта источника – любой TCP порт от 1024 до 65535. В качестве адреса назначения – IP адрес ресурса wiki.merionet.ru и порт 80 (http). Та же самая настройка через терминал выглядит следующим образом: ip socks> set enabled=yes ip socks access> add src-address=192.168.11.48 src-port=1024-65535 dst-address=212.193.249.136 dst-port=80 ... action=allow Готово, теперь дело за клиентом, который должен настроить сотрудник. Покажем настройку на примере браузера Google Chrome. Открываем Settings → Advanced → Confidentiality and Security, крутим в самый низ до пункта System и выбираем Proxy settings. В появившемся окне выбираем LAN settings → ставим галку напротив Use a proxy server for your LAN и заходим в Advanced. В появившемся окне вбиваем параметры нашего SOCKS сервера в строку Socks (в нашем случае 192.168.11.1 и порт 1080) и применяем настройки: Теперь обновляем страничку wiki.merionet.ru и ву-а-ля, всё заработало! В окне Connections видны соединения с нашего компьютера до IP адреса wiki.merionet.ru. Послесловие Данная статья носит исключительно образовательный характер и не ставит своей целью научить кого-либо обходить правила Firewall. Протокол SOCKS 4 устарел, не поддерживает аутентификацию и не может резолвить доменные адреса. В целях безопасности, мы не рекомендуем использовать этот протокол вообще и в том числе – настраивать его на MikroTik. По умолчанию – сервер SOCKS на роутерах MikroTik отключен. Если Вы обнаружили, что он активирован, то это может быть признаком того, что Ваш роутер был скомпрометирован злоумышленниками. Об этом мы подробнее расскажем в следующих статьях.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59