По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:

Друг, начнем с цитаты:
Redis – это высокопроизводительная БД с открытым исходным кодом (лицензия BSD), которая хранит данные в памяти, доступ к которым осуществляется по ключу доступа. Так же Редис это кэш и брокер сообщений.
Надо признаться, определение не дает точного понимания, что же такое Redis. Если это так круто, то зачем вообще нужны другие БД? На самом деле, Redis правильнее всего использовать в определенных кейсах, само собой, зная про подводные камни – именно об этом и поговорим.
Про установку Redis в CentOS 8 мы рассказываем в этой статье.
Redis как база данных
Говорим про случай, когда Redis выступает в роли базы данных:
Пару слов про ограничения такой модели:
Размер БД ограничен доступной памятью
Шардинг (техника масштабирования) ведет к увеличению задержки
Это NoSQL - никакого языка SQL
LUA скриптинг в качестве альтернативы
Это нереляционная СУБД!
Нет сегментации на пользователей или группы пользователей. Отсутствует контроль доступа
Доступ по общему паролю. Что скажут ваши безопасники?
Теперь про преимущества модели:
Скорость
Хранение данных в памяти делает быстрее работу с ними
Скрипты на LUA
Выполнение прямо в памяти, опять же, ускоряет работу
Удобные форматы запросов/данных
Geospatial – геоданные (высота, ширина, долгота и так далее)
Hyperloglog – статистическе алгоритмы
Hash – если коротко, то хэш в Redis делают между строковыми полями и их значениями
Алгоритмы устаревания данных
Примеры использования
Представь, у нас есть приложение, где пользователям необходимо авторизоваться, чтобы выполнять какие – либо действия внутри приложения. Каждый раз, когда мы обновляем авторизационные данные клиента, мы хотим их получать для последующего контроля.
Мы могли бы отправлять лист авторизационных параметров (с некими номерами авторизаций, сроком действия с соответствующими подписями), чтобы каждое действие внутри приложения, сопровождалось авторизацонной транзакцией из листа, который мы прислали клиенту. С точки зрения безопасности, в этом подходе нет ничего плохого, если мы храним на своей стороне данные в безопасности и используем Javascript Object Signing and Encryption (JOSE), например. Но проблема появится в том случае, когда наш пользователь имеет более одной авторизации внутри приложения – такие схемы плохо поддаются масштабированию.
А что если вместо отправки листа авторизационных параметров, мы сохраним его у себя, а пользователю отправим некий токен, который они должны отправлять для авторизации? Далее, по этому токену, мы легко сможем найти авторизации юзера. Это делает систему гораздо масштабируемой. Redis, такой Redis.
Итого, для указанной выше схемы, мы хотим:
Скорость
Мы не хотим, чтобы пользователь долго ожидал авторизации
Масштабирумость системы
Сопоставление ключа (токена) с авторизациями юзера
А вот, что на эти вызовы может ответить Redis:
Redis хранит данные в памяти – он быстрый.
Redis можно кластеризовать через компонент Sentinel. Масштабируемость? Пожалуйста.
В Redis куча вариантов хранения списков. Самый простой будет являться набором данных.
В качестве бонуса от Redis, вы получите механизм экспайринга токенов (устаревания). Все будет работать.
Redis как кэш!
Redis почти заменил memcached в современных приложениях. Его фичи делают супер – удобным кэширование данных.
Ограничения:
Значения не могут превышать 512 МБ
Отсутствует искусственный интеллект, который будет очищать ваше хранилище данных
Профит:
Совместное использование кэша разными сервисами по сети
Удобные фичи, такие как LUA скриптинг, который упрощает работы с кэшом
Временные ограничения для данных
Еще один кейс
Предположим, перед нами такая задача: приложение, отображает пользователям данные с определенными значениями, которые можно сортировать по множеству признаков. Все наши данные хранятся в БД (например, MySQL) и показывать отсортированные данные нужно часто. Дергать БД каждый раз весьма тяжело и ресурсозатратно, а значит, нам нужно кэшировать данные в отсортированном порядке.
Окей, кейс понятен. Рэдис, что скажешь на такие требования?
Кэш должен хранить сортированные наборы данных
Нам нужно вытаскивать наборы данных внутри наборов данных (для пагинации, например, то есть для переключения между страницами)
Это должно быть быстрее, чем пересчет данных с нуля
Что скажет Redis:
Хранить наборы данных - легко
Может вытаскивать сабсеты из наборов - легко
Конечно быстрее. Ведь данные хранятся в памяти
Redis как брокер сообщений
Редис может выступать в качестве брокера сообщений. Схема обычная и весьма базовая - publish–subscribe (pub/sub), или как можно перевести на русский язык «Издатель - подписчик».
Как и раньше, давайте обсудим плюсы и минусы, хотя их тут и не так много. Минусы:
Только тривиальная модель pub/sub
Отсутствие очередей сообщений
Ну а плюсы, как обычно для Редиса – скорость и стабильность.
Кейс напоследок
Простой пример – коллаборация сотрудников одной компании. Предположим, у них есть приложение, где они работают над общими задачами. Каждый пользователь делает свой набор действий, о котором другие пользователи должны знать. А так же, юзеры могут иметь разные экземпляры приложений – десктоп, мобильный или что то еще.
Требования по этой задаче:
Низкая задержка
Мы не хотим иметь трудности в процессе совместной работы сотрудников
Стабильная работа и непрерывность
Масштабирование
Кампания растет и развивается
Редис, твой выход!
Низкая задержка – да, говорили об этом ранее
Стабильность – минимальное количество точек отказа в Redis
Стабильная работа и непрерывность
Масштабирование – сделаем кластер, нет проблем.
Выводы
Redis - крутая штука, которая позволяет объединять сервисы и следовать 12 принципам приложений. Для приложений, в которых нагрузка ориентирована на быстрое изменение наборов данных и высокая безопасность данных не имеет завышенных требований – Redis прекрасный выбор.
Если данные нуждаются в усиленной защите, Редис подойдет в меньшей степени, лучше посмотрите в сторону MongoDB или Elasticsearch.

Что такое Kali?
Kali Linux является одним из лучших инструментов для проверки вашей системы на защищенность и очень знаменитым инструментом для этичного хакинга. И мало того, что уже после установки в нем доступно огромное количество инструментов, так еще есть и большое сообщество людей, которые постоянно развивают экосистему этого проекта. У нас до этого была небольшая статья, где мы подробно разбирали что такое пентестинг и зачем он делается.
В 2015 году Kali начали двигаться в сторону Agile подхода, для того, чтобы компоненты операционной системы и приложения обновлялись гораздо чаще и имели меньшее число зависимостей, и старый тип перестал поддерживаться 15 апреля 2016 года.
Если вы любите тестировать свои системы и приложения на проникновения, то частый ритм обновлений инструментов для взлома вам подойдет лучше всего: сейчас в Kali находятся самые последние версии таких знаменитых инструментов как Metasploit, Kismet и aircrack-ng. Кроме того, сам Debian Linux, на котором Kali всегда базировался тоже будет обновляться гораздо чаще.
Нужно больше инструментов
Не все знают, что когда вы скачиваете ISO файл для установки Kali Linux, вы получаете далеко не весь доступный инструментарий для тестирования на проникновение – разработчики пытаются найти золотую середину между необходимым набором приложений и постоянно увеличивающимся размером образа. Кроме того, есть такие вещи как инструменты для брутфорса с аппаратным графическим ускорением – они будут работать только на определенных конфигурациях компьютеров, поэтому совершенно точно их не имеет смысла добавлять в образ системы, который скачивают большинство людей.
Но хорошей новостью является то, что получить весь набор инструментов – совершенно тривиальная задача. Чтобы этого добиться, нужно совершить ряд примитивных шагов.
Сначала необходимо открыть терминал и проверить, что вы находитесь в системе, используя права суперпользователя. Для этого введите команду su или просто введите sudo перед командой apt-get updateдля обновления всех имеющихся пакетов.
После завершения процесса, вам останется ввести команду apt-get install kali-linux-all - и она позволит установить вам все возможные тулзы для пентеста – это более чем 430 дополнительных инструментов. Как видите, потребовалось всего лишь две команды!
Но, конечно, есть и обратная сторона медали – ваш Kali Linux начнет занимать гораздо больше места чем прежде, как минимум на 5 Гб больше. Это может быть важным, если вы установили Kali на что-то вроде Raspberry Pi с небольшой картой памяти.
Хотелось бы напомнить, что не стоит использоваться Kali Linux для совершения различных «темных» дел – это совершенно неэтично и в РФ уголовно наказуемо. Правда, не надо – лучше побалуйтесь на своих виртуалках, поймите, где могут находится типичные дыры, которые присущи большинству информационных систем и избавьтесь от них в своей организации – так будет спокойнее спать ночью и снизится шанс того, что ваши данные или данные вашей организации будут в сохранности. Надеемся, статья была вам полезна.

Подключив SIP – транк к нашему Asterisk, следующим шагом необходимо настроить маршрутизацию вызова. Как это сделать исходящие и входящие маршруты во FreePBX 13 расскажем в сегодняшней статье:
Маршрутизация вызова является важнейшей задачей в настройке офисной АТС. В настройках входящей маршрутизации, как правило, компании реализуют свои бизнес процессы – направляют вызовы с определенных номеров на IVR, c других номеров на Ring Group (группы вызова), а третьи напрямую на ответственного менеджера. При исходящей маршрутизации, можно учитывать направление вызова, например, если у вас 2 провайдера IP – телефонии, и один из них дает наилучшую цену для звонков в Сибирь, а другой для звонков на Урал.
Пошаговое видео
Исходящие маршруты
Начнем с настройки исходящей маршрутизации во FreePBX 13. Для этого перейдем во вкладку Connectivity → Outbound Routes
Открываем интерфейс настройки на первичной вкладке Route Settings.
Давайте разберемся, что можно здесь настроить:
Route Name - Имя маршрута. Рекомендуем записывать названия по номеру телефона – это позволяет быстрее ориентироваться в настроенных маршрутах.
Route CID - В данном поле можно ввести CallerID для этого маршрута, т.е номер звонящего, который мы будем отправлять в сторону провайдера. Важно отметить, что данный CID является менее приоритетным, чем CID настроенный на SIP – транке и правилах Ring Group, Follow Me.
Override Extension - Yes/No: Если выбрано значение Yes, то настроенный в параметрах экстеншена Outbound CID будет игнорироваться
Route Password - Данная настройка позволяет запрашивать у пользователя пароль, чтобы позвонить через данный маршрут. Это достаточно полезная опция, при звонках зарубеж.
Route Type - Выбрать тип маршрута:
Аварийный (Emergency) или Корпоративный (Intra-Company)
Аварийный (Emergency): Набор экстренных служб и прочих
Корпоративный (Intra-Company): В данном случае будет сохранена информация Caller ID в настройках Extension
Music On Hold - Музыка ожидания на маршруте. Для различных направлений звонка, например, можно делать какое-либо звуковое сообщение на нативном для направления языке.
Time Group - Временная группа. Если отмечено, то этот маршрут будет использоваться только в указанное в настройках Time Group времени.
Route Position - Во FreePBX 13, как и в других версиях используется приоритетность маршрутов в зависимости от его позиции. В данном пункте можно выбрать позицию маршрута относительно других.
Trunk Sequence for Matched Routes - Последовательность SIP – транков для отправления вызова в сторону провайдера. Если первый транк не работает, вызов будет отправлен во второй и так далее.
Optional Destination on Congestion - Если вызов не может состоять по причине неработоспособности SIP – транков, то можно отправить вызов, например, на звуковое сообщение «В настоящее время все линии недоступны. Обратитесь в техническую поддержку»
Отлично, мы разобрались со вкладкой Route Settings, теперь перейдем ко вкладке Dial Patterns, в которой мы будем определять формат набора номера. Вот как выглядит типичная настройка на маршруте:
Давайте разбираться более подробно:
Шаблон набора номера (Dial Pattern) – это уникальный набор цифр, который позволяет отправить вызов в нужный SIP – транк. Если шаблон совпадает, то вызов отправляется через SIP – транк в сторону провайдера.
Шаблон набора номера имеет 4 поля настройки:
Prepend, Prefix, Match Pattern и CallerID.
Формат такой:
(prepend) prefix | [ match pattern / caller ID ]
Шаблон
Описание
X
Любое целое число от 0 до 9
Z
Любое целое число от 1 до 9
N
Любое целое число от 2 до 9
[#####]
Любое целое число в скобка. Например, перечисление – [1.2.7], или диапазон чисел –[1.2.6-9], в который попадают числа 1,2,6,7,8,9
.(точка)
Любой набор символов
Теперь давайте разберемся с полями, которые доступны для заполнения:
Prepend - Данная часть будет добавлена к номеру, перед отправкой в SIP – транк в случае совпадения шаблона.
Prefix - Префикс – это часть шаблона, которая будет удалена
Match Pattern - Набранный номер.
ВАЖНО: Asterisk ищет совпадения сопоставляя поле Prefix и Match Pattern.
CallerID - Данный звонок будет выполнен только в случае, если звонок инициирован с указанного CallerID. В данном поле можно использовать шаблоны. Полезно, если компания имеет несколько офисов с нумерацией виду 1XXX, 2XXX и так далее.
Теперь наш маршрут готов. Мы можем совершать исходящие вызовы. Но как настроить входящую маршрутизацию во FreePBX 13? Перейдем во вкладку Connectivity → Inbound Routes
Входящие маршруты
Самым главным пунктом в настройке входящего маршрута является DID Number. Данный параметр вы получаете от вашего провайдера, и, как правило, он совпадает с самим подключаемым номером. Даем имя нашему входящему маршруту – чтобы не путаться, мы советуем так же дать имя в соответствие с номером. Далее, самое главное – поле Set Destination. Выбираем назначение для нашего звонка. Это может быть как IVR, проверка времени, Ring Group или что - угодно
На этом настройка маршрутизации во FreePBX13 завершена