По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сегодня рассмотрим установку малоизвестного аналога FreePBX под названием Wazo – отличий достаточно много, начиная от версии Linux (Debian), дистрибутив с которой можно скачать с официального сайта http://wazo.community и заканчивая крайне непривычным видом самого Web-интерфейса.
Установка
В первую очередь, необходимо создать виртуальную машину под скачанный дистрибутив корректной разрядности – то есть машина должна быть 64-битной, если вы скачали соответствующий дистрибутив и наоборот. Далее, выбираем образ, с которого машина будет грузиться (здесь все также как и прежде – никаких изменений) и запускаем машину. Далее будет предложено выбрать способ установки, выбираем просто Install:
Далее появится возможность выбрать язык для установки – выбираем русский язык.
Выбираем местоположение – страну или регион:
Выбираем раскладку клавиатуры – нам нужна английская:
Далее начинается загрузка дополнительных компонентов – придётся немного подождать.
Дистрибутив Wazo «весит» совсем немного – около 400MB, однако, докачивает много файлов в процессе установки, и, конкретно в моём случае процесс установки получился очень длительным.
Далее вводим пароль суперпользователя (пароль на пользователя root). Обязательно сгенерируйте его соответствующим требованиям безопасности.
Затем выбираем часовой пояс, после чего начнётся установка базовой системы (на скриншотах ниже).
Далее начинается процесс настройки менеджера пакетов (в случае Debian-систем используется apt-get, в отличие от привычного yum). Сначала выбираем страну расположения – логично также выбрать РФ, затем выбираем зеркало – я выбрал зеркало МИФИ:
Оставляем пустым поле HTTP-прокси – в моём случае его заполнять не нужно. Сразу после этого будет довольно длительная процедура по настройке apt:
Последним шагом необходимо выбрать диск для установки системного загрузчика – так как в моём случае Wazo устанавливается на простейшей виртуальной машине, то и диск один – его и выбираем. После этого появится последний прогресс-бар о продолжении процесса установки. Как только процесс завершится (у меня этот процесс занял около 30 минут) произойдет перезагрузка.
Как только система загрузится, введите логин – root и пароль, который вы установили ранее. После чего, введите команду ipconfig для того, чтобы понять, какой адрес был присвоен IP-АТС. Кстати, в случае FreePBX пользователь видит IP - адрес сразу после входа на АТС. Далее заходим по адресу, который вы видите в выводе команды и продолжаем процесс первичной настройки.
Выбираем язык – к сожалению, выбрать можем только между английским и французским. Далее нажимаем Next и сначала читаем, затем соглашаемся с лицензионным соглашением GNU GPL.
После чего последовательно производим следующие настройки:
Hostname - имя вашего сервера с АТС;
Domain name - ваш домен;
WebInterface root password - пароль суперпользователя для управления АТС через веб-интерфейс;
Interface VoIP - адрес АТС и адрес шлюза по умолчанию;
DNS servers -DNS сервер – я оставил данную настройку нетронутой;
Затем будет неожиданное – настройка контекста внутренних вызовов, внешних и интервала нумерации:
Entity - название вашей организации;
Internal calls context - название контекста для внутренних вызовов и диапазон нумерации пользователей – позднее это можно будет изменить;
Incalls context - контекст для прямых вызовов (DID) и их диапазон – я оставил данное поле незаполненным;
Outcalls context - название контекста для исходящих вызовов;
После нажатия на Next вы увидите всю введенную информацию (для подтверждения) ещё раз – необходимо нажать на кнопку Validate:
Наконец-то можно начать пользоваться системой – но предварительно вы увидите экран, похожий на Dashboard у FreePBX – здесь есть информация о сетевых интерфейсах, железе, жёстком диске, запущенных серверах и плагинах.
Попробовать что-то покрутить касаемо телефонной части можно нажав на кнопку Services и, затем, IPBX – тут можно управлять транками, пользователями и так далее.
Заключение
Решать нужна ли вам данная АТС – только вам, но мы настоятельно советуем попробовать её установить, так как определённое количество «фишек» у неё присутствует – о них и о подробной настройке данной АТС мы расскажем в следующих статьях.
Вы наверняка слышали об опасностях разглашения своих паролей и почему этого делать не стоит. Существуют различные протоколы, предназначенные для вашей защиты и которые избавят вас от необходимости повторного ввода ваших паролей или учетных данных. Когда веб-сайт требует ввести пароль для получения доступа, он может воспользоваться техникой под названием OAuth для того, чтобы упростить задачу.
Цель этой статьи – показать вам, как веб-сайт или приложение принимают запросы на вход от пользователей, которые их посещают. У этих платформ есть необходимые полномочия? Есть ли у них право подтверждать вашу личность и получать доступ к некоторым вашим данным от вашего имени? OAuth объясняет весь этот процесс и помогает его упростить. Прочитайте статью до конца, чтобы узнать, как онлайн-проверки стали автоматизированными и как так получилось, что для их завершения требуется всего один клик.
Что такое OAuth?
OAuth – это протокол авторизации открытого стандарта, который можно добавить в приложения, чтобы позволить пользователям получать безопасный доступ к их платформе. Например, с помощью этого протокола вы можете указать приложению Facebook разрешить ESPN.com доступ к вашим сообщениям и обновлениям в социальных сетях без обязательного раскрытия ваших учетных данных. Такой доступ позволяет существенно снизить риск. Если на ESPN.com вдруг произойдет утечка данных, то информация, которой вы владеете в Facebook, будет защищена.
OAuth работает, не обмениваясь паролями с другими платформами. Вместо этого он просто отправляет им маркеры авторизации. Этот маркер используется для подтверждения личности пользователя. Это ключевая стратегия, которой пользуются клиенты и поставщики услуг. Проще говоря, эта концепция представляет собой протокол аутентификации, который позволяет платформам и поставщикам услуг взаимодействовать, не выдавая при этом свои пароли.
Примеры OAuth
Один из распространенных примеров протокола OAuth связан с большинством устройств Android. Когда вы покупаете смартфон Android, то вам необходимо войти в свою учетную запись электронной почты, чтобы получить доступ к большинству функций телефона.
Когда вы вошли в свою электронную почту в телефоне, то вам понадобиться некоторая информация для доступа к другим приложениям или веб-сайтам. Принципы OAuth позволяют пользователям мгновенно обмениваться своими учетными данными электронной почты с платформой. Вам не потребуется вводить пароль, но при этом веб-сайт позволит вам аутентифицироваться и получить доступ.
Существует множество других примеров и вариантов использования протокола OAuth, которые демонстрируют его концепцию. И это при условии, что вы можете обмениваться своими учетными данными для получения информации на разных платформах без повторного ввода пароля.
Хорошим примером здесь может послужить ситуация, когда вас перенаправляют на другой веб-сайт, и вы получаете сообщение с текстом «Эй, вы хотите получить доступ к нашему сайту с учетными данными другого сайта?» Давайте условно назовем веб-сайт, запрашивающий доступ пользователя, получателем, а платформу, на которой вы в данный момент вошли в систему, - отправителем. Когда вы пытаетесь войти на сайт-получатель, вам необходимо будет узнать, заходите ли вы на сайт под тем же именем, что и на сайте-отправителе.
Facebook – один из наиболее распространенных примеров платформ, которые используют данный протокол. Когда вы используете приложение на Facebook, оно запросит доступ к информации и фотографиям вашего профиля. В таком случае Facebook является отправителем ваших данных для получения доступа и изображений. Приложение здесь является получателем, и как пользователь вы намерены пользоваться услугами принимающей платформы. Нажимая кнопку «Разрешить», вы предоставляете получателю доступ к вашим изображениям, а OAuth существенно упрощает весь этот процесс.
Некоторым вашим умным домашним устройствам, таким как телевизору, системе безопасности, тостеру и т.д., требуется вход в систему, чтобы вы могли управлять ими через браузер или мобильное устройство. Эти устройства работают на, так называемой, конфиденциальной авторизации OAuth, и они надежно хранят ваши учетные данные. Таким образом, вам не требуется вводить свои учетные данные на различных терминалах веб-сайта.
Как работает OAuth?
Реальность такова, что OAuth был разработан с целью фокусировки внимания на авторизации, а не на аутентификации. Авторизация предполагает получение разрешения на выполнение определенных действий. А вот аутентификация предполагает доказательство того, то вы являетесь лицом, которое имеет необходимый доступ к информации, защищенной в профиле. OAuth не запрашивает аутентификацию пользователя, а просто разрешает доступ к другим приложениям и ресурсам.
Хороший способ рассмотреть принцип работы этого протокола – это провести аналогию с ключом камердинера. Такой ключ предназначен для того, чтобы дать камердинеру доступ к управлению вашим автомобилем, но при этом он не обязательно позволит ему открыть багажник. Токен OAuth предназначен для использования в качестве служебного ключа для вашего смарт-устройства. Как пользователь вы можете контролировать информацию, которая будет использоваться на разных платформах. Вы можете вручить ключ камердинера каждому получателю, но у них все равно не будет ключа полного доступа или доступа к конфиденциальных данным, которые скрыты в профиле.
В абсолютно любой транзакции OAuth участвуют 3 основные стороны: пользователь, отправитель и получатель. Эти 3 стороны в шутку можно назвать любовным треугольником OAuth. Мы рассмотрим несколько простых шагов для того, чтобы проиллюстрировать то, как OAuth обеспечивает защиту аутентификации для пользователей на разных платформах.
Шаг 1: пользователь показывает свое намерение получить доступ
Шаг 2: получатель получает разрешение. Учетные цифровые идентификационные данные будут отправлены вместе с этим разрешением, которые будут использоваться для выявления подделки и проверки источника запроса на права доступа.
Шаг 3: пользователь перенаправляется к поставщику услуг или отправителю.
Шаг 4: пользователь дает разрешение.
Шаг 5: получатель получает маркер доступа.
Шаг 6: получатель получает доступ к защищенному ресурсу.
SAML vs OAuth
Многие люди очень легко могут указать на сходства между SAML и OAuth, но их концепции все же очень разные. SAML, также известный как язык разметки утверждений безопасности, представляет собой альтернативный стандарт проверки личности пользователя, который многие организации используют для поддержки функций системы единого входа (SSO). SAML – это функция, позволяющая организациям контролировать тех, кто отвечает за корпоративные ресурсы.
Между SAML и OAuth есть множество различий. SAML использует XML для отправки сообщений, а OAuth – технологию JSON. OAuth разработан для того, чтобы упростить работу с мобильными устройствами, а SAML – для обеспечения повышенного уровня безопасности. Последнее различие является основным. OAuth в основном полагается на API. Именно поэтому многие мобильные приложения, современные веб-сайты, игровые приставки и Интернет вещей используют данный протокол. Как правило, OAuth предлагает пользователям больше возможностей. Чтобы провести аутентификацию пользователя, SAML сбрасывает cookie сессию в браузере пользователя, которая позволяла человеку получать доступ к определенным веб-страницам. Такой вариант отлично подходит для краткосрочного доступа, но не очень подходит для случаев, когда вам необходимо входить в сеть многократно.
OpenID vs OAuth
Если говорить простым языком, то OpenID используется для аутентификации, а OAuth – для авторизации.
OpenID поддерживает интегрированную аутентификацию. Это означает, что он поддерживает сторонние приложения для поддержки и аутентификации пользователей при попытке использовать уже имеющиеся учетные записи. В то же время, OAuth был разработан для того, чтобы вам не приходилось вводить свои учетные данные для входа в сторонние приложения.
Оба протокола могут использоваться для выполнения похожих задач, но это вовсе не означает, что они взаимозаменяемы. OpenID обеспечивает подтверждение личности, в то время как OAuth имеет более общее направление использования. Когда клиент использует OAuth, сервер выдает маркер доступа третьей стороне, этот маркер используется для доступа к защищенному ресурсу, а источник проверяет этот маркер. Здесь еще стоит обратить внимание на то, что личность владельца маркера не проверяется.
Сравнение
SAML 2.0
OAuth2
OpenID Connect
Что это?
Открытый стандарт аутентификации и авторизации
Открытый стандарт авторизации
Открытый стандарт аутентификации
Основное назначение
SSO для корпоративный приложений
API-авторизация
Поддержка сторонних приложений
SSO для корпоративных приложений
Формат
XML
JSON
JSON
OAuth 1.0 vs OAuth 2.0
OAuth 2.0 призван полностью улучшить работу OAuth 1.0. Эти два похожих фреймворка просто несопоставимы. Если вы сейчас создаете новое приложение или веб-сайт, то убедитесь, что они основаны именно на OAuth 2.0. Большинство современных веб-сайтов уже перешли на OAuth 2.0, потому что OAuth 1.0 просто-напросто обесценился.
Последнюю версию, OAuth 2.0, проще и быстрее реализовать в приложениях и на веб-сайтах. OAuth 1.0 был разработан с учетом криптографических требований, а также он не поддерживал более трех потоков и даже масштабирование.
OAuth 2.0 разработан так, что он поддерживает целых шесть потоков, которые в свою очередь поддерживают различные приложения и требования. Этот протокол аутентификации позволяет использовать подписанные учетные идентификационные данные через HTTPS. Токены OAuth не нужно шифровать при отправке из одного места в другое, поскольку они шифруются непосредственно при передаче.
Как OAuth защищает API?
Защитить API можно с помощью API Connect. OAuth – это специальный протокол авторизации, который делает доступными сторонние веб-сайты и приложения без регистрации учетных данных пользователя или личной информации.
Сценарий пользователя OAuth
Люди, использующие API Connect совместно с этим протоколом, используют несколько методов для защиты своего API. Вот некоторые доступные варианты:
Создание API поставщика OAuth. API поставщика будет содержать токены OAuth для обеих конечных точек потока OAuth.
Защита API с помощью определения безопасности OAuth. Когда вы добавляете определение безопасности этого протокола в свое приложение или на веб-сайт, то вы добавляете настройки, которые позволяют вам контролировать операции API с помощью стандарта авторизации OAuth.
URL-адрес метаданных OAuth и URL-адрес аутентификации. Вы можете установить URL-адрес метаданных OAuth или URL-адрес аутентификации, который будет использоваться для получения пользовательского контента с веб-сайта. К нему будет установлен доступ с удаленного сервера, и он будет добавлен в маркер доступа или как часть полезных данных, содержащих маркер безопасности.
Ответы OAuth
Во время выполнения процесса OAuth 2.0 API Connect дает различные ответы на запросы.
Устранение неполадок OAuth
Если у вас возникли какие-либо проблемы с данным протоколом, то вы можете устранить неполадки самостоятельно. Перейдите на портал разработчиков и форумы на Youtube, Github и DeveloperWorks.
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 - чрезвычайно полезная система, но, как и любая другая система, она не безошибочна.
Когда все же возникают проблемы, вы можете использовать три перечисленных выше метода, чтобы быстро и безопасно заставить ваше приложение работать, не закрывая службу для ваших клиентов.