По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сегодня мы хотим рассказать про настройку функции DND (Do Not Disturb, не беспокоить) в Cisco Unified Communications Manager (CUCM) . Эта функция позволяет абоненту отключить звонок для входящего вызова. Когда она включена все входящие звонки с обычным приоритетом попадают под DND. Звонки с высоким приоритетом проходят независимо от настроек DND.
Настройка
Настройка выполняется для профиля телефона. Для этого переходим во вкладку Device → Device Settings → Common Phone Profile и выбираем профиль, для которого мы будем менять настройки.
В поле Common Phone Profile Information в строке DND Option выбираем один из двух параметров:
Ringer Off– Отключает звуковой сигнал, когда включен DND. Абонент видит информацию о звонке и может его принять;
Call Reject – Отклоняет вызов, когда включен DND. Информация о звонке не отображается, но телефон может воспроизвести сигнал или включить светящийся индикатор;
В стоке DND Incoming Call Alert выбираем один из трех параметров:
Flash Only – при входящем звонке загорится индикатор;
Beep Only – при входящем звонке воспроизведется сигнал;
Disable – эта опция отключает сигнал и индикатор. В случае если стоит режим Ringer Off, то информация о звонке будет высвечиваться на экране. Если стоит режим Call Reject, то никакой информации о звонке не отобразится;
Также настройку DND можно выполнять в настройках самого телефона в поле Do Not Disturb.
Дальше необходимо добавить на телефон кнопку DND на телефон (про настройку кнопок можно почитать в этой статье). Переходим во вкладку Device → Phone Settings → Softkey Template и выбираем нужный нам шаблон, переходим в меню Configure Softkey Layout и в нем добавляем функцию Toggle Do Not Disturb (DND) . Затем возвращаемся в меню настройки телефона и выбираем измененный шаблон кнопок. После этого на телефоне появится кнопка включения режима DND.
Классификация сама по себе не приводит к определенному состоянию переадресации со стороны сетевого устройства. Скорее, классификация трафика - это первый необходимый шаг в создании основы для дифференцированного поведения пересылки. Другими словами, пакеты были классифицированы и дифференцированы, но это все. Выявление различий - это не то же самое, что дифференцированные действия с этими классами.
Наше обсуждение QoS теперь переходит в сферу политики. Как управлять перегруженными интерфейсами? Когда пакеты ожидают доставки, как сетевое устройство решает, какие пакеты будут отправлены первыми? Точки принятия решения основаны в первую очередь на том, насколько хорошо пользовательский интерфейс может выдерживать джиттер, задержку и потерю пакетов. Для решения этих проблем возникают различные проблемы и инструменты QoS.
Своевременность: организация очередей с малой задержкой
Сетевые интерфейсы пересылают пакеты как можно быстрее. Когда трафик проходит со скоростью, меньшей или равной пропускной способности выходного интерфейса, трафик доставляется по одному пакету за раз, без каких-либо проблем. Когда интерфейс может соответствовать предъявляемым к нему требованиям, перегрузки не возникает. Без перегрузок нет необходимости беспокоиться о дифференцированных типах трафика. Отметки на отдельных пакетах можно наблюдать в статистических целях, но политики QoS, которую нужно применять, нет. Трафик поступает на выходной интерфейс и доставляется.
Как было рассказано ранее в лекции "Коммутация пакетов", пакеты доставляются в кольцо передачи после коммутации. Физический процессор исходящего интерфейса удаляет пакеты из этого кольца и синхронизирует их с физической сетевой средой. Что произойдет, если будет передано больше пакетов, чем может поддерживать канал связи? В этом случае пакеты помещаются в очередь, выходную очередь, а не в кольцо передачи. Политики QoS, настроенные на маршрутизаторе, фактически реализуются в процессе удаления пакетов из очереди вывода на кольцо передачи для передачи. Когда пакеты помещаются в очередь вывода, а не в кольцо передачи, интерфейс считается перегруженным.
По умолчанию перегруженные сетевые интерфейсы доставляют пакеты в порядке очереди (FIFO). FIFO не принимает стратегических решений на основе дифференцированных классов трафика; скорее, FIFO просто обслуживает буферизованные пакеты по порядку настолько быстро, насколько это позволяет выходной интерфейс. Для многих приложений FIFO - неплохой способ удаления пакетов из очереди. Например, в реальном мире может быть небольшое влияние, если пакет протокола передачи гипертекста (HTTP, протокол, используемый для передачи информации World Wide Web) с одного веб-сервера передается раньше, чем пакет с другого веб-сервера.
Для других классов трафика большое внимание уделяется своевременности. В отличие от FIFO, некоторые пакеты следует переместить в начало очереди и отправить как можно быстрее, чтобы избежать задержки и влияния на работу конечного пользователя. Одно из последствий - это пакет, прибывающий слишком поздно, чтобы быть полезным. Другой удар заключается в том, что пакет вообще не поступает. Стоит рассмотреть каждый из этих сценариев, а затем несколько полезных инструментов QoS для каждого.
Голосовой трафик по IP (VoIP) должен вовремя. При рассмотрении голосового трафика подумайте о любом голосовом чате в реальном времени, который осуществляется через Интернет с помощью такого приложения, как Skype. В большинстве случаев качество связи приличное. Вы можете слышать другого человека. Этот человек может вас слышать. Разговор протекает нормально. С таким же успехом вы можете находиться в одной комнате с другим человеком, даже если он находится на другом конце страны.
Иногда качество звонков VoIP может снижаться. Вы можете услышать серию субсекундных заиканий в голосе человека, при этом скорость передачи голоса нерегулярна. В этом случае вы испытываете джиттер, что означает, что пакеты не поступают стабильно вовремя. Чрезмерно длинные промежутки между пакетами приводят к слышимому эффекту заикания. Хотя пакеты не были потеряны, они не были своевременно доставлены по сетевому пути. Где-то по пути пакеты задерживались достаточно долго, чтобы появились слышимые артефакты. На рисунке 5 показан джиттер при пакетной передаче.
Качество вызова VoIP также может пострадать из-за потери пакетов, когда пакеты на сетевом пути были сброшены по пути. Хотя существует множество потенциальных причин потери пакетов в сетевых путях, рассмотренный здесь сценарий - это "отбрасывание хвоста", когда поступило такое количество трафика, которое выходит за пределы возможностей выходного интерфейса, и в буфере не остается места для добавления в очередь дополнительных излишков. В результате отбрасываются самые последние поступления трафика; это падение называется хвостовым падением.
Качество вызова VoIP также может пострадать из-за потери пакетов, когда пакеты на сетевом пути были сброшены по пути. Хотя существует множество потенциальных причин потери пакетов в сетевых путях, рассмотренный здесь сценарий - это "отбрасывание хвоста", когда поступило такое количество трафика, которое выходит за пределы возможностей выходного интерфейса, и в буфере не остается места для добавления в очередь дополнительных излишков. В результате отбрасываются самые последние поступления трафика; это падение называется хвостовым падением.
Когда трафик VoIP отбрасывается, слушатель слышит результат потери. Есть пробелы, в которых голос говорящего полностью отсутствует. Отброшенные пакеты могут проходить в виде тишины, поскольку последний бит принятого звука зацикливается, чтобы заполнить пробел, продолжительное шипение или другой цифровой шум. На рисунке ниже показаны отброшенные пакеты через маршрутизатор или коммутатор.
Чтобы обеспечить стабильное качество вызовов даже в условиях перегруженности сетевого пути, необходимо применять схему приоритезации QoS. Эта схема должна соответствовать следующим критериям.
Трафик VoIP должен быть доставлен: потеря пакетов VoIP приводит к слышимому прерыванию разговора.
Трафик VoIP должен доставляться вовремя: задержка или прерывание пакетов VoIP приводит к слышимым заиканиям.
Трафик VoIP не должен ограничивать пропускную способность других классов трафика: так же важно, как и VoIP, хорошо написанные политики QoS уравновешивают своевременную доставку голосовых пакетов с необходимостью для других классов трафика также использовать канал.
Распространенной схемой, используемой для определения приоритетов трафика, чувствительного к потерям и jitter, является организация очередей с низкой задержкой (LLQ). Никакие RFC IETF не определяют LLQ; скорее, поставщики сетевого оборудования изобрели LLQ в качестве инструмента в наборе политик QoS для определения приоритетов трафика, требующего низкой задержки, jitter и потерь, например, голоса.
LLQ есть два ключевых элемента.
Трафик, обслуживаемый LLQ, передается как можно быстрее, чтобы избежать задержки и минимизировать джиттер.
Трафик, обслуживаемый LLQ, не может превышать определенный объем полосы пропускания (обычно рекомендуется не более 30% доступной полосы пропускания). Трафик, превышающий предел пропускной способности, скорее отбрасывается, чем передается. Этот метод позволяет избежать потери трафика других классов.
В этой схеме подразумевается компромисс для услуг классов трафика посредством LLQ. Трафик будет обслуживаться как можно быстрее, эффективно перемещая его в начало очереди, как только он обнаруживается на перегруженном интерфейсе. Загвоздка в том, что существует ограничение на то, сколько трафика в этом классе будет обрабатываться таким образом. Это ограничение налагается сетевым инженером, составляющим политику QoS.
В качестве иллюстрации предположим, что канал WAN имеет доступную пропускную способность 1024 Кбит/с. Этот канал соединяет головной офис с облаком WAN поставщика услуг, которое также соединяет несколько удаленных офисов с головным офисом. Это загруженный канал WAN, по которому проходит трафик VoIP между офисами, а также трафик веб-приложений и резервный трафик время от времени. Кроме того, предположим, что система VoIP кодирует голосовой трафик с помощью кодека, требующего 64 Кбит/с на разговор.
Теоретически, этот канал с пропускной способностью 1024 Кбит/с может обеспечить одновременные разговоры VoIP 16 × 64 Кбит/с. Однако это не оставит места для других типов трафика, которые присутствуют. Это занятое соединение WAN! Решение должно быть принято при написании политики QoS. Сколько голосовых разговоров будет разрешено LLQ, чтобы избежать нехватки оставшегося трафика полосы пропускания? Можно было бы сделать выбор, чтобы ограничить LLQ пропускной способностью только 512 Кбит/с, что было бы достаточно для обработки восьми одновременных разговоров, оставив остальную часть канала WAN для других классов трафика.
Предполагая, что канал перегружен, что произойдет с девятым разговором VoIP, если он должен находиться в ситуации, чтобы политика QoS была эффективной? Этот вопрос на самом деле наивен, потому что он предполагает, что каждый разговор обрабатывается отдельно политикой QoS. Фактически, политика QoS рассматривает весь трафик, обслуживаемый LLQ, как одну большую группу пакетов. После присоединения девятого разговора VoIP будет трафик на 576 Кбит/с, который будет обслуживаться LLQ, которому выделено только 512 Кбит/с. Чтобы найти количество отброшенного трафика, вычтите общий трафик, выделенный для LLQ, из общего предлагаемого трафика: 576 Кбит/с - 512 Кбит/с = 64 Кбит/с трафик LLQ будет отброшен в соответствии с ограничением полосы пропускания. Отброшенные 64 Кбит/с будут исходить от класса трафика LLQ в целом, что повлияет на все разговоры VoIP. Если десятый, одиннадцатый и двенадцатый разговор VoIP присоединиться к LLQ, проблема станет более серьезной. В этом случае 64 Кбит/с × 4 = 256 Кбит/с несоответствующего трафика, который будет отброшен из LLQ, что приведет к еще большим потерям во всех разговорах VoIP.
Как показывает этот пример, для управления перегрузкой необходимо знать состав приложений, время пиковой нагрузки, требования к полосе пропускания и доступные варианты сетевой архитектуры. Только после того, как будут учтены все моменты, можно найти решение, отвечающее бизнес-целям. Например, предположим, что 1024 Кбит/с - это максимальное значение, которое вы можете сделать для линии дальней связи из-за ограничений по стоимости. Вы можете увеличить ограничение полосы пропускания LLQ до 768 Кбит/с, чтобы обеспечить 12 разговоров со скоростью 64 Кбит/с каждый. Однако для другого трафика останется только 256 Кбит/с, чего, возможно, недостаточно для удовлетворения потребностей вашего бизнеса в других приложениях.
В этом случае можно согласовать с администратором системы голосовой связи использование голосового кодека, требующего меньшей полосы пропускания. Если новый кодек, требующий только 16 Кбит/с полосы пропускания на вызов, развернут вместо исходных 64 Кбит/с, 32 разговора VoIP могут быть перенаправлены без потерь через LLQ с выделенной полосой пропускания 512 Кбит/с. Компромисс? Качество голоса. Человеческий голос, закодированный со скоростью 64 Кбит/с, будет звучать более четко и естественно по сравнению с голосом, закодированным на скорости 16 Кбит/с. Также может быть лучше кодировать со скоростью 16 Кбит/с, чтобы отбрасывать меньше пакетов и, следовательно, общее качество лучше. Какое решение применить, будет зависеть от конкретной ситуации.
Через интерфейс может пройти больше трафика, чем указано в ограничении полосы пропускания LLQ. Если ограничение полосы пропускания для трафика, обслуживаемого LLQ, установлено на максимум 512 Кбит/с, возможно, что трафик класса более чем на 512 Кбит/с пройдет через интерфейс. Такое запрограммированное поведение проявляется только в том случае, если интерфейс не перегружен. В исходном примере, где используется кодек 64 Кбит/с, передача 10 разговоров со скоростью 64 Кбит/с по каналу приведет к передаче голосового трафика 640 Кбит/с по каналу пропускной способности 1024 Кбит/с (1024 Кбит/с - 640 Кбит/с = 384 Кбит/с осталось). Пока все другие классы трафика остаются ниже общего использования полосы пропускания 384 Кбит / с, канал не будет перегружен. Если канал не перегружен, политики QoS не вступают в силу. Если политика QoS не действует, то ограничение полосы пропускания LLQ в 512 Кбит/с не влияет на 640 Кбит/с агрегированного голосового трафика.
В этой статье о LLQ контекстом был голосовой трафик, но имейте в виду, что LLQ может применяться к любому желаемому виду трафика. Однако в сетях, где присутствует VoIP, VoIP обычно является единственным трафиком, обслуживаемым LLQ. Для сетей, в которых нет трафика VoIP, LLQ становится интересным инструментом, гарантирующим своевременную доставку с малой задержкой и дрожанием других видов трафика приложений. Однако LLQ - не единственный инструмент, доступный для составителя политики QoS. Также пригодятся несколько других инструментов.
В этой статье рассмотрим, как управлять учетными записями пользователей и групп в Linux. Также посмотрим различные базы данных, в которых хранится информация о пользователях и группах и что такое теневые пароли.
Изначально в Linux было 2 файла /etc/password и /etc/group. В первом файле хранилось:
Имя_пользователя : пароль : uid : gid : сведения (поле предназначено для персональных данных) : домашняя_папка : командная оболочк(которая запускается при входе пользователя в систему)
Во втором файле хранилось:
имя_группы : пароль : gid : члены_группы
У группы может быть пароль, но данную функцию очень редко, кто использует, в таком случае пароль будет запрашиваться при смене членства в группе. Данные файлы плохи тем, что у всех пользователей системы, по умолчанию, есть права на чтение. Такие права необходимы потому, что разные пользователи, разные демоны и сервисы обращаются к данным файлам, чтобы брать оттуда информацию. Соответственно в этих файлах хранился пароль пользователя, хотя и в зашифрованном виде, но с помощью различных методов криптографии подбора можно было воспользоваться данным паролем, потому что у всех пользователей был на эти файлы доступ.
Поэтому был создан механизм теневых паролей. Были созданы вот такие 2 файла: /etc/shadow и /etc/gshadow. И к этим двум файлам имеет полный доступ только пользователь root. Следовательно, теперь в файлах passwd и group указываются не пароли, а специальные символы, говорящие что пароли были перенесены в файлы shadow и gshadow.
В новом файле shadow хранится побольше информации о пароле пользователя. Это:
Логин
Пароль
Время после смены пароля – это если пароль сбрасывался после времени установки системы
Минимальный срок действия пароля - как часто можно менять пароль, если, например, стоит 5 дней, то пароль можно менять не чаще, чем раз в 5 дней.
Максимальный срок действия пароля – максимальное количество дней, по прошествии которых обязательно необходимо сменить пароль.
Срок предупреждения – за сколько дней до истечения пароля система предупредит о том, что необходимо сменить пароль.
Время работы с истекшим паролем – это параметр позволяет указанное число дней работать с истекшим паролем.
Срок для блокировки пароля – данный параметр отвечает за время жизни самого пароля, например, пароль будет работать 100 дней, после этого заблокируется.
Соответственно данные параметры можно при необходимости задавать при создании учетной записи пользователя и паролей. Если провести аналогию с операционной системой Windows, то подобные параметры в Windows мы можем задавать через GPO (Group Policy Object - набор правил или настроек, в соответствии с которыми производится настройка рабочей среды в операционных системах Windows). Отличие заключается в том, что в Windows эти параметры выставляются в абсолютных величинах числом, а в операционной системе Linux, относительно даты 1 января 1970 года.
Ну и соответственно gshadow имеет следующую структуру, разделенную символом :.
Имя группы
Пароль зашифрованный
Администраторы, те учетные записи, которые могут менять пароль группы или добавлять другие аккаунты
Члены групп
Следовательно, пароли могут хранится и в тех, и в тех файлах, отличие в том, что у пользователей есть доступ на чтение к файлам passwd и group, а к shadow и gshadow только у пользователя root. Данный механизм называется механизмом теневых паролей, и он присутствует во всех современных Linux системах.
Теперь, посмотрим, как это выглядит в операционной системе.
Заходим в файл passwd любым текстовым редактором, например, nano, без повышения привилегий.
Возьмем пользователя:
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
Логин - list, значок X говорит о том, что пароль хранится в теневом файле. Далее 38 – id пользователя, 38 - gid, прочая информация - Mailing List Manager, домашняя папка пользователя - /var/list и оболочка которая используется при входе - /usr/sbin/nologin.
Можно увидеть, что вместо оболочки у пользователя указан nologin – это означает, что пользователь не может войти, используя стандартный экран входа, используя стандартные средства. На картинке можно найти пользователя siadmin. Можно также увидеть все остальные параметры этого пользователя. У него совпадает uid и gid, это связанно с тем , что при создании пользователя создается одноименная группа. Можно, конечно, при создании указать, что пользователь будет входить в другую группу и не создавать одноименную, но по умолчанию она создается. В конце строчки мы можем увидеть /bin/bash, которая запускается при входе в систему. Можно обратить внимания на uid и gid все реальные пользователи их имеют числом выше 1000. Все пользователи, у которых число ниже – это служебные пользователи или созданные автоматически. В некоторых дистрибутивах Linux нумерация реальных пользователей начинается с 500.
Посмотрим файл с группами, вводим команду nano /etc/group
Данная база очень простая. Указано наименование группы, знак X говорит, о том, что пароль хранится в теневой базе, идентификатор группы и список пользователей в данной группе. Единственный нюанс - если пользователь входит в свою же группу, то после знака двоеточие пользователь не отображается.
Далее файлы /etc/shadow и /etc/gshadow, данные файлы не редактируются с помощью текстовых редакторов, а через специальные команды. Данные файлы — это просто хранилище информации. Эти утилиты будут рассмотрены в следующем уроке.
Зайти в эти файлы могут только пользователи имеющие права root или с помощью команды повышающей привилегии sudo.
sudo nano /etc/shadow
Теперь мы видим в данном файле через двоеточие:
Имя пользователя
* или зашифрованный пароль
Срок с последнего изменения пароля в днях
Минимальный срок изменения пароля, если 0, то сменить пароль можно сразу
99999 - срок действия пароля, 7 - количество дней за которое до истечения пароля придет предупреждение
Символ * говорит о том, что под данным пользователем нельзя зайти стандартным способом, обычно это применяется для служебных аккаунтов, т.е вход вообще заблокирован под данным аккаунтом.
Вот так вот реализуется механизм теневых паролей.