По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сегодня хотелось бы кратко описать команды менеджера пакетов yum - официальная сборка FreePBX основана на CentOS, в котором yum установлен по умолчанию. Он пригодится для установки, удаления, обновления пакетов.
Установка пакета
К примеру, для установки пакета mc нужно ввести команду yum install mc. После ввода команды, система попросит подтверждение. Чтобы подтверждение было одобрено по умолчанию, нужно добавить ключ -y , к примеру yum –y install mc:
[root@localhost asterisk]# yum install mc
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.corbina.net
* epel: mirror.datacenter.by
* extras: mirror.corbina.net
* updates: mirror.corbina.net
Resolving Dependencies
--> Running transaction check
---> Package mc.x86_64 1:4.8.7-11.el7 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
mc x86_64 1:4.8.7-11.el7 base 1.7 M
Transaction Summary
================================================================================
Install 1 Package
Total download size: 1.7 M
Installed size: 5.6 M
Is this ok [y/d/N]: y
Downloading packages:
mc-4.8.7-11.el7.x86_64.rpm | 1.7 MB 00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : 1:mc-4.8.7-11.el7.x86_64 1/1
Verifying : 1:mc-4.8.7-11.el7.x86_64 1/1
Installed:
mc.x86_64 1:4.8.7-11.el7
Complete!
Удаление пакета
Для удаления пакета, соответственно, нужно ввести команду yum remove mc. Точно также можно использовать ключ для подтверждения -y :
[root@localhost asterisk]# yum remove mc
Loaded plugins: fastestmirror
Resolving Dependencies
--> Running transaction check
---> Package mc.x86_64 1:4.8.7-11.el7 will be erased
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Removing:
mc x86_64 1:4.8.7-11.el7 @base 5.6 M
Transaction Summary
================================================================================
Remove 1 Package
Installed size: 5.6 M
Is this ok [y/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Erasing : 1:mc-4.8.7-11.el7.x86_64 1/1
Verifying : 1:mc-4.8.7-11.el7.x86_64 1/1
Removed:
mc.x86_64 1:4.8.7-11.el7
Complete!
Обновление пакета
Предположим – у вас старая версия mysql и вам необходимо ее обновить – тут используется команда update. Целиком команда будет выглядеть так: yum update mysql .
Поиск пакета
Если хотите проверить наличие установленного конкретного пакета на сервере и доступные для установки – используйте команду list. Целиком команда будет выглядеть так: yum list mysql. Также можно указать точную версию пакета, если вам требуется более скрупулезный поиск.
Вывод информации о пакете
Если хотите вывести информацию о пакете – используйте команду info. Целиком команда будет выглядеть так: yum info mc .
Вывод информации о всех доступных и установленных пакетах
Для этого используется команда list с модификаторами. Для вывода доступных пакетов: yum list | less, а для вывода всех установленных - yum list installed | less
Проверка доступных обновлений для пакетов и само обновление
Для проверки служит команда check-update, а для обновления - update. Ниже три примера использования команд:
yum check-update mysql - проверка обновлений пакета mysql;
yum list updates - вывод списка обновлений;
yum update mc - обновление Midnight Commander’а;
yum –y update - обновление всех установленных пакетов;
Групповые пакеты и операции с ними
В Линуксе некоторые пакеты собраны в так называемые групповые пакеты – к примеру, DNS Name Server, Editors, Java Development и так далее. С помощью yum можно устанавливать групповые пакеты с помощью команды groupinstall - пример далее yum groupinstall ‘Clustering. Коротко опишу остальные команды для манипуляций с групповыми пакетами:
yum grouplist - вывод всех доступных к установке групповых пакетов;
yum groupupdate ‘Base’ - обновление конкретного группового пакета, в данном случае – Base;
yum groupremove ‘Editors’ - удаление группового пакета;
Репозитории в yum
Поиск пакетов происходит в так называемых репозиториях, ниже приведу несколько команд для работы с ними – принцип тот же, что и с пакетами (команды list, к примеру). Вывод всех активных репозиториев производится с помощью команды yum repolist, вывод также и неактивных репозиториев – с помощью команды yum repolist all
Для установки пакета из конкретного репозитория, неважно, активного или неактивного, используется ключ --enablerepo . Как пример – установка phpmyadmin: yum –enablerepo=epel install phpmyadmin
Терминал в yum и история
Если Вы собираетесь проводить очень много операций с пакетами, то можно сразу зайти в оболочку yum с помощью команды yum shell и с помощью уже известных вам команд (только уже без первых трёх букв, соответственно), Вы можете устанавливатьудалятьобновлятьwhatever пакеты. Также интересной фичей является возможность посмотреть историю установок в yum – с помощью команды yum history.
Решение Cisco Unified Contact Center Enterprise предназначено для крупных контактных центров, которые имею географически распределенные площадки и большое количество персонала, работающего в рамках центра.
Выделим следующие основные преимущества UCCE:
Интеллектуальная маршрутизация с универсальными очередями;
Computer Telephony Integration (CTI) в рамках модели сеть – рабочее место;
Возможность обрабатывать различные канала взаимодействия (звонки, чаты, e-mail, web – обращения, sms и так далее.);
Голосовое меню IVR;
«Умный» алгоритм очередей;
Интеграция со устаревшими моделями телефонных станций;
Единая платформа отчетности.
Рассмотрим архитектуру решения UCCE:
Компонент Intelligent Contact Manager (ICM) это элемент, ответственный за принятие решений о маршрутизации вызова, отчетности и CTI интеграции. Параллельно, с развертыванием ICM компоненты, устанавливается множество других важных узлов, таких как:
Контроллер: делится на две компоненты:
Router («роутер») - выполняет функции направления и контроля почти всех событий происходящих в рамках ICM. С точки зрения маршрутизации, роутер ответственен за обработку входящих запросов на маршрутизацию и отвечает на исходящие события. Запрос на маршрутизацию может приходить из сети провайдера или других периферийных устройств (ACD, IVR IP PBX и так далее);
Logger («логгер») - так же называется сервер базы данных. Главная функция логгера это быть базой данных для ICM компонента. В предыдущих версиях ICM, логгер содержал только информацию об ICM. Текущие актуальные версии логгера выполняют копии конфигурации ICM и другие административные задачи, такие как уведомления в случае ошибок. Логгер частично содержит историческую отчетность, которая, в большинстве своем, передается на Administration & Data Server (сервер администрирования и информации), на котором хранится историческая отчетность и отчетность типа Real – time (реального времени);
Network Interface Controller (NIC) - интерфейс взаимодействия с провайдером. Не все ICM системы напрямую подключаются к провайдеру услуг. Так же ICM может быть развернут без NIC. В рамках разворачиваемой архитектуры, NIC может быть развернут как сторонним сервере, так и на одном сервере с компонентом Router;
Administration & Data Server - интерфейс пользователя для взаимодействия с конфигурацией и отчетностью;
Периферийный шлюз (Peripheral gateway, PG) - термин «переферийный» используется для обозначения того, что любое внешнее устройство может быть подключено к ICM через PG. Внешними устройствами, или как принято говорить «периферийными», могут быть устаревшие типы ACD, IVR – системы, Cisco Unified Communications Manager, Cisco Unified CVP [7] (Customer Voice Portal) и многие другие. Периферийный шлюз это интерфейс между контроллером и периферией.
Взгляните на архитектуру контактного центра Unified Contact Center Enterprise:
В итоге получаем, что сочетание ICM, CUCM и IVR, и есть Unified Contact Center Enterprise.
Рассмотрим требования Unified CCE к программному обеспечению:
Microsoft Windows Server 2003 SP2 или Microsoft Windows Server 2003 R2 SP2 (стандартный или корпоративный). Данные системы необходимы для таких компонент, как Router, Administration & Data Server, Logger, PG и CTI сервер;
SQl Server 2005;
Только 32-х битная архитектура;
Microsoft SQL Server 2005 SP3 (стандартный или корпоративный). Необходим для таких компонент как Logger и Administration & Data Server;
Требования к аппаратной платформе ниже:
MCS сервера;
Виртуализация возможна только для некоторых компонент;
Многоядерный процессор;
Полнодуплексные сетевые интерфейсы.
Лицензирование
Лицензирование UCCE происходит по двум принципам. Первый, это покупка обязательных лицензий для компонентов и агентов. Вторая часть, это покупка дополнительных лицензий, таких как интеграция со сторонними IVR системами и лицензии на сложные модели развертывания.
К любой системе Unified CCE необходимо приобрести одну (или несколько) категорий лицензий для конкретных клиентских каналов взаимодействия центра, такие как:
Голосовые взаимодействия: Лицензия на развертывание компонент Router/Logger, PG, отказоустойчивые компоненты IVR PG, AWDB, HDS, NIC и так далее;
Взаимодействие по каналу e-mail: Лицензия на развертывание обязательных компонент для обработки e-mail транзакций, таких как Services Server, Application Server, Database Server и так далее;
Взаимодействие по каналу WEB: Для общения с клиентом через WEB формы на сайте компании, необходимо приобрести соответствующие лицензии на компоненты, указанные выше. Лицензия включает встраиваемые шаблоны HTML для взаимодействия по каналу WEB, коннекторы в базы данных и так далее;
Существует 4 возможных схемы лицензирования агентов для обработки голосовых транзакций:
Стандартная лицензия - включает в себя Cisco Agent Desktop (CAD) или Cisco Supervisor Desktop. Приложение CAD является тонким клиентом, где агент может работать с входящим и исходящими вызовами;
Расширенная лицензия - включает в себя Enhanced Cisco Agent Desktop или Enhanced Cisco Supervisor Desktop. Расширение представляет из себя возможность «кастомизации» агентского интерфейса;
Премиум лицензия - в рамках данной лицензии предоставляется возможность выбора одного из агентских рабочих мест, а именно:
Cisco Finesse Agent Desktop - представляет из себя WEB – интерфейс, в котором агент может производить обработку различных событий. Обладает широчайшими возможностями «кастомизации»;
Cisco Toolkit Desktop (CTI OS) - разновидность агентского рабочего места. Представляет широкий набор возможностей обработки вызова, таких как набор номера, ответ, отбой, удержание, подключение, помощь супервизора и так далее;
Premium CAD и Supervisor Desktop - максимальный функциональный набор;
CRM Agent Licenses - включает в себя Cisco Unified CRM Connector для Siebel CRM.
Буферизация пакетов для работы с перегруженным интерфейсом кажется прекрасной идеей. Действительно, буферы необходимы для обработки трафика, поступающего слишком быстро или несоответствия скорости интерфейса - например, при переходе от высокоскоростной LAN к низкоскоростной WAN. До сих пор это обсуждение QoS было сосредоточено на классификации, приоритизации и последующей пересылке пакетов, помещенных в очередь в этих буферах, в соответствии с политикой. Максимально большой размер буферов кажется хорошей идеей. Теоретически, если размер буфера достаточно велик, чтобы поставить в очередь пакеты, превышающие размер канала, все пакеты в конечном итоге будут доставлены. Однако, как большие, так и переполненные буферы создают проблемы, требующие решения.
Когда пакеты находятся в буфере, они задерживаются. Некоторое количество микросекунд или даже миллисекунд добавляется к пути пакета между источником и местом назначения, пока они находятся в буфере, ожидая доставки. Задержка перемещения является проблемой для некоторых сетевых разговоров, поскольку алгоритмы, используемые TCP, предполагают предсказуемую и в идеале небольшую задержку между отправителем и получателем.
В разделе активного управления очередью вы найдете различные методы управления содержимым очереди. Некоторые методы решают проблему переполненной очереди, отбрасывая достаточно пакетов, чтобы оставить немного места для вновь поступающих. Другие методы решают проблему задержки, поддерживая небольшую очередь, минимизируя время, которое пакет проводит в буфере. Это сохраняет разумную задержку буферизации, позволяя TCP регулировать скорость трафика до скорости, соответствующей перегруженному интерфейсу.
Управление переполненным буфером: взвешенное произвольное раннее обнаружение (WRED)
Произвольное раннее обнаружение (RED) помогает нам справиться с проблемой переполненной очереди. Буферы не бесконечны по размеру: каждому из них выделено определенное количество памяти. Когда буфер заполняется пакетами, новые поступления отбрасываются. Это не сулит ничего хорошего для критического трафика, такого как VoIP, от которого нельзя отказаться, не повлияв на взаимодействие с пользователем. Способ решения этой проблемы - убедиться, что буфер никогда не будет полностью заполнен. Если буфер никогда не заполняется полностью, то всегда есть место для приема дополнительного трафика.
Чтобы предотвратить переполнение буфера, RED использует схему упреждающего отбрасывания выбранного входящего трафика, оставляя места открытыми. Чем больше заполняется буфер, тем больше вероятность того, что входящий пакет будет отброшен. RED является предшественником современных вариантов, таких как взвешенное произвольное раннее обнаружение (WRED). WRED учитывает приоритет входящего трафика на основе своей отметки. Трафик с более высоким приоритетом будет потерян с меньшей вероятностью. Более вероятно, что трафик с более низким приоритетом будет отброшен. Если трафик использует какую-либо форму оконного транспорта, например, такую как TCP, то эти отбрасывания будут интерпретироваться как перегрузка, сигнализирующая передатчику о замедлении.
RED и другие варианты также решают проблему синхронизации TCP. Без RED все входящие хвостовые пакеты отбрасываются при наличии переполненного буфера. Для трафика TCP потеря пакетов в результате отбрасывания хвоста приводит к снижению скорости передачи и повторной передаче потерянных пакетов. Как только пакеты будут доставлены снова, TCP попытается вернуться к более высокой скорости. Если этот цикл происходит одновременно во многих разных разговорах, как это происходит в сценарии с отключением RED-free, интерфейс может испытывать колебания использования полосы пропускания, когда канал переходит от перегруженного (и сбрасывания хвоста) к незагруженному и недоиспользованному, поскольку все д throttled-back TCP разговоры начинают ускоряться. Когда уже синхронизированные TCP-разговоры снова работают достаточно быстро, канал снова становится перегруженным, и цикл повторяется.
RED решает проблему синхронизации TCP, используя случайность при выборе пакетов для отбрасывания. Не все TCP-разговоры будут иметь отброшенные пакеты. Только определенные разговоры будут иметь отброшенные пакеты, случайно выбранные RED. TCP-разговоры, проходящие через перегруженную линию связи, никогда не синхронизируются, и колебания избегаются. Использование каналов связи более устойчиво.
Управление задержкой буфера, Bufferbloat и CoDel
Здесь может возникнуть очевидный вопрос. Если потеря пакетов - это плохо, почему бы не сделать буферы достаточно большими, чтобы справиться с перегрузкой? Если буферы больше, можно поставить в очередь больше пакетов, и, возможно, можно избежать этой досадной проблемы потери пакетов. Фактически, эта стратегия больших буферов нашла свое применение в различных сетевых устройствах и некоторых схемах проектирования сети. Однако, когда перегрузка канала приводит к тому, что буферы заполняются и остаются заполненными, большой буфер считается раздутым. Этот феномен так хорошо известен в сетевой индустрии, что получил название: bufferbloat.
Bufferbloat имеет негативный оттенок, потому что это пример слишком большого количества хорошего. Буферы - это хорошо. Буферы предоставляют некоторую свободу действий, чтобы дать пачке пакетов где-нибудь остаться, пока выходной интерфейс обработает их. Для обработки небольших пакетов трафика необходимы буферы с критическим компромиссом в виде введения задержки, однако превышение размера буферов не компенсирует уменьшение размера канала. Канал имеет определенную пропускную способность. Если каналу постоянно предлагается передать больше данных, чем он может передать, то он плохо подходит для выполнения требуемой от него задачи. Никакая буферизация не может решить фундаментальную проблему пропускной способности сети.
Увеличение размера буфера не улучшает пропускную способность канала. Фактически, постоянно заполненный буфер создает еще большую нагрузку на перегруженный интерфейс. Рассмотрим несколько примеров, противопоставляющих протоколов Unacknowledged Datagram Protocol (UDP) и Transmission Control Protocol (TCP).
В случае VoIP-трафика буферизованные пакеты прибывают с опозданием. Задержка чрезвычайно мешает голосовой беседе в реальном времени. VoIP - это пример трафика, передаваемого посредством UDP через IP. UDP-трафик не подтверждается. Отправитель отправляет пакеты UDP, не беспокоясь о том, доберутся ли они до места назначения или нет. Повторная передача пакетов не производится, если хост назначения не получает пакет UDP. В случае с VoIP - здесь важно, пакет приходит вовремя или нет. Если это не так, то нет смысла передавать его повторно, потому что уже слишком поздно. Слушатели уже ушли. LLQ может прийти вам в голову как ответ на эту проблему, но часть проблемы - это слишком большой буфер. Для обслуживания большого буфера потребуется время, вызывающее задержку доставки трафика VoIP, даже если LLQ обслуживает трафик VoIP. Было бы лучше отбросить VoIP-трафик, находящийся в очереди слишком долго, чем отправлять его с задержкой.
В случае большинства приложений трафик передается по протоколу TCP через IP, а не по протоколу UDP. TCP - протокол подтверждений. Отправитель трафика TCP ожидает, пока получатель подтвердит получение, прежде чем будет отправлен дополнительный трафик. В ситуации bufferbloat пакет находится в переполненном, слишком большом буфере перегруженного интерфейса в течение длительного времени, задерживая доставку пакета получателю. Получатель получает пакет и отправляет подтверждение. Подтверждение пришло к отправителю с большой задержкой, но все же пришло. TCP не заботится о том, сколько времени требуется для получения пакета, пока он туда попадает. И, таким образом, отправитель продолжает отправлять трафик с той же скоростью через перегруженный интерфейс, что сохраняет избыточный буфер заполненным и время задержки увеличивается. В крайних случаях отправитель может даже повторно передать пакет, пока исходный пакет все еще находится в буфере. Перегруженный интерфейс, наконец, отправляет исходный буферизованный пакет получателю, а вторая копия того же пакета теперь находится в движении, что создает еще большую нагрузку на уже перегруженный интерфейс!
Эти примеры демонстрируют, что буферы неподходящего размера на самом деле не годятся. Размер буфера должен соответствовать как скорости интерфейса, который он обслуживает, так и характеру трафика приложения, который может проходить через него.
Одна из попыток со стороны сетевой индустрии справиться с большими буферами, обнаруженными вдоль определенных сетевых путей, - это контролируемая задержка, или CoDel. CoDel предполагает наличие большого буфера, но управляет задержкой пакетов, отслеживая, как долго пакет находится в очереди. Это время известно, как время пребывания. Когда время пребывания пакета превысило вычисленный идеал, пакет отбрасывается. Это означает, что пакеты в начале очереди-те, которые ждали дольше всего-будут отброшены до пакетов, находящихся в данный момент в хвосте очереди.
Агрессивная позиция CoDel в отношении отбрасывания пакетов позволяет механизмам управления потоком TCP работать должным образом. Пакеты, доставляемые с большой задержкой, не доставляются, а отбрасываются до того, как задержка станет слишком большой. Отбрасывание вынуждает отправителя TCP повторно передать пакет и замедлить передачу, что очень желательно для перегруженного интерфейса. Совокупный результат - более равномерное распределение пропускной способности для потоков трафика, конкурирующих за интерфейс.
В ранних реализациях CoDel поставлялся в устройства потребительского уровня без параметров. Предполагаются определенные настройки по умолчанию для Интернета. Они включают 100 мс или меньше времени двустороннего обмена между отправителями и получателями, а задержка 5 мс является максимально допустимой для буферизованного пакета. Такая конфигурация без параметров упрощает деятельность поставщиков сетевого оборудования потребительского уровня. Потребительские сети являются важной целью для CoDel, поскольку несоответствие высокоскоростных домашних сетей и низкоскоростных широкополосных сетей вызывает естественную точку перегрузки. Кроме того, сетевое оборудование потребительского уровня часто страдает от слишком большого размера буферов.