По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Переменные окружения (или переменные среды) - это набор пар ключ-значение, которые хранятся в вашем Linux и используются процессами для выполнения определенных операций. Они отвечают за стандартное поведение системы и приложений. При взаимодействии с вашим сервером через сеанс оболочки, есть много информации, которую ваша оболочка обрабатывает, чтобы определить ее поведение и доступы. Некоторые из этих параметров содержатся в настройках конфигурации, а другие определяются пользовательским вводом. Оболочка отслеживает все эти параметры и настройки через окружение. Окружение - это область, которую оболочка создает каждый раз при запуске сеанса, содержащего переменные, определяющие системные свойства. Например, это может быть часовой пояс в системе, пути к определенным файлам, приложения по-умолчанию, локали и многое другое. Переменные окружения также могут использоваться в программах оболочки или в подоболочках для выполнения различных операций.
В этом руководстве мы расскажем, как просматривать, устанавливать и сбрасывать переменные окружения в вашей системе.
Переменные окружения и переменные оболочки
Переменные имеют следующий формат:
KEY=value
KEY="Some other value"
KEY=value1:value2
Должны соблюдаться следующие правила:
Имена переменных чувствительны к регистру (регистрозависимы). Переменные окружения должны быть написаны большими буквами (UPPER CASE).
Несколько значений переменных разделяются двоеточием :
Вокруг символа = нет пробела
Переменные можно разделить на две категории:
Переменные окружения (Environmental Variables) - это переменные, которые определены для текущей оболочки и наследуются любыми дочерними оболочками или процессами. Переменные окружения используются для передачи информации в процессы, которые порождаются из оболочки.
Переменные оболочки (Shell Variables) - это переменные, которые содержатся исключительно в оболочке, в которой они были установлены или определены. Они часто используются для отслеживания эфемерных данных, например, текущего рабочего каталога.
Про Linux за 5 минут
Привет! Сегодня в статье мы хотим рассмотреть систему восстановления Cisco Unified Communications Manager (CUCM) после сбоев, которая называется Disaster Recovery System (DRS) . С ее помощью можно делать бэкапы системы, которые будут храниться на SFTP сервере, и восстанавливать из них систему в случае такой необходимости.
Архивирование при помощи DRS включает следующие компоненты:
Cisco Unified Communications Manager database (CCMDB), включая Cisco Unified Communications Manager/CDR Analysis and Reporting/Call Detail Records);
Platform
Music On Hold (MOH);
BAT Bulk Provisioning Service (BPS);
CCM Preference Files (CCMPREFS);
TFTP Phone device files (TFTP);
SNMP Syslog Component (SYSLOGAGT SNMP);
SNMP CDP Subagent (CDPAGT SNMP);
Trace Collection Tool (TCT);
Cluster Manager (CLM);
Cisco Extended Functions (CEF);
Настройка
Прежде всего, для выполнения резервного копирования нам нужно развернуть SFTP сервер. Cisco рекомендует использовать такие клиенты как Cygwin, Titan FTP, GlobalSCAPE EFT, но можно использовать и другие. Загружаем желаемый клиент, устанавливаем его на машине, на которой будет использоваться SFTP сервер, в нем самом настраиваем сетевые параметры подключения, указываем корневую папку и затем запускаем сервис.
Теперь переходим к настройке CUCM. Нам нужно войти в систему восстановления после сбоев, для этого нам нужно в правом верхнем углу из выпадающего меню выбрать пункт Disaster Recovery System.
Здесь переходим во вкладку Backup → Backup Device и нажимаем Add New. В открывшемся окне необходимо указать названия для бэкапа в строке Backup device name. Ниже в поле Select Destination выбираем Network Directory и указываем IP адрес SFTP сервера в строке Host name/IP address, реквизиты для подключения указываем в полях User name и Password, а поле Path name указываем путь для каталога, где будут храниться наши данные (если необходимо хранить файл в корневом каталоге, то указываем ’’’’). После этого нажимаем Save. Если SFTP сервер работает и доступен, то мы увидим надпись Update Successful.
Теперь чтобы создать бэкап нам нужно перейти во вкладку Backup → Manual Backup, выбрать созданные нами ранее настройки резервирования и нажать Start Backup. Создать расписание для выполнения архивирования можно в меню Backup → Scheduler, где нужно нажать Add New для создания нового расписания. Тут выбираем бэкап, указываем время выполнения архивации и нажимаем Save. После чего нажимаем Enable Schedule наверху экрана.
Теперь рассмотрим восстановление системы, которое называется Restoring a Node or Cluster to a Last Known Good Configuration (No Rebuild) , то есть до последней рабочей конфигурации. Для того чтобы восстановить систему из созданного бэкапа нужно перейти во вкладку Disaster Recovery System → Restore → Restore Wizard. Тут выбираем Backup Device, затем нажимаем Next и выбираем один из доступных файлов.
Далее указываем, какие функции должны быть восстановлены.
Затем выбираем нужные серверы для восстановления и нажимаем Restore.
После этого начнется восстановление системы. Статус текущего восстановления можно посмотреть во вкладке Disaster Recovery System → Restore → Status. После того как произойдет восстановление нужно будет перезагрузить сервер. Проверить статус репликации можно либо при помощи RTMT, в пункте Call Manager → Database Summary → Replication Status, где для всех нод мы должны видеть одинаковое значение, либо через систему отчетов CUCM Unified Reporting в пункте Unified Reporting → System Reports → Unified CM Database Status, где мы должны найти строчку All servers have a good replication status, либо через командную строку CLI, выполнив команду utils dbreplication status, результатом которой мы должны получить строчку No Errors or Mismatches found. Replication status is good on all available servers.
Представьте себе, что рядом с вами в организации есть сетевая розетка и все, что туда подключается, автоматически получает туда доступ. Любые устройства - даже если они являются "шпионскими" или не авторизованными.
Вы конечно скажете - но есть же простой, как тапок, протокол под названием Port Security!
Верно, но как он работает? Вы либо указываете MAC-адрес, который может подключиться к порту и получить доступ в сеть, либо указываете какое-то количество таких MAC адресов, которые будут динамически опознаны коммутатором или смешиваете два этих способа.
Но что если вы находитесь в публичной зоне, например там, куда вы приглашаете клиентов, или, к примеру вы находитесь на некой веранде, откуда зачастую можно работать. Там внедрён Port Security, все нормально.
Но вдруг ваш ноутбук кто-то умудрился ловко спереть и что тогда? У кого-то постороннего появится доступ в вашу сеть, так как доступ по его MAC-адресу разрешен. Тут-то и вступает в дело 802.1X - он позволяет проводить аутентификацию не устройства, но пользователя. Таким образом, если устройство будет украдено, злоумышленники все равно не получат доступ в сеть.
Логичным вопросом будет "Как же я обеспечу гостей доступом в сеть без предоставления им полного доступа"? Ответ - легко, и вариантов десятки: гостевая учетка и гостевой VLAN, специальный портал саморегистрации для гостей и так далее и тому подобное.
Также некоторые скажут - ну конечно, у меня в компании доступ к беспроводной сети так и организован, через синхронизацию с AD и по учетным записям пользователей. Но как это работает в случае проводного доступа? Сразу отвечу, что 802.1X используется как в беспроводной сети, так и в проводной. Подробнее о принципе действия, его компонентах я расскажу ниже.
Из чего состоит 802.1X
У 802.1X есть три основных компонента - суппликант, аутентификатор и сервер аутентификации. Суппликант - это ваше оконечное устройство и пользователь с определенным ПО (здесь нет смысла углубляться в различные виды суппликантов).
Аутентификатор - это коммутатор или точка доступа (первое сетевое устройство уровня доступа, на который пришел трафик с суппликанта.
И, наконец, сервером аутентификации является специальное ПО или устройство, принадлежащее к классу NAC - Network Access Control, или средствам контроля сетевого доступа. Конкретный класс решений для реализации 802.1X называется RADIUS-сервером.
Итак, порядок подключения следующий: вы пытаетесь получить доступ в сеть и аутентификатор говорит - предъявите, пожалуйста документы. Ваше устройство (суппликант) предоставляет нужную информацию - логин и пароль, сертификат, обе этих сущности вместе и прочие. Далее аутентификатор отправляет полученную информацию на сервер аутентификации и ждёт ответа. Далее, в базовом варианте, сервер аутентификации отправит обратно на аутентификатор разрешение и после этого аутентификатор разрешение суппликанту. До этого момента почти никакой трафик разрешен не будет!
Важно понимать, что в сторону аутентификатора уходит фрейм с определенным регистром (для этого и нужен суппликант), а аутентификатор энкапсулирует отправляет полученную информацию от суппликанта в сторону сервера аутентификации как IP – пакет (чтобы его можно было маршрутизировать).
Протоколы в технологии 802.1X
Давайте теперь подробнее поговорим о протоколах в этой технологии – так как 802.1X являет собой неикий собирательный термин. Основных протоколов 2 – EAPoL (Extensible Authentication Protocol over LAN) и RADIUS (Remote Authentication Dial-In User Service).
Есть очень простые и не очень безопасные формы EAP и очень надежные, но крайне сложные в настройке. В простейшем виде будет необходим только логин и пароль. В более сложных – сертификат, токен и прочее. Есть правило – чем проще настроить EAP – тем он менее взломостойкий и наоборот :)
В наше время одним из популярных и очень умных RADIUS – серверов является Cisco ISE. Он позволяет авторизовывать пользователей в зависимости от их контекста: Что за устройство? Кто? Где? Когда? Было ли устройство скомпрометировано ранее? и автоматически профилировать каждое подключенное устройство для того, чтобы понимать какие устройства есть у вас в сети и в каком состоянии они находятся – многие даже не подозревают о том, как много у них в организации подключено неизвестных устройств (при количестве пользователей более 1000).
Ниже на диаграмме можно увидеть весь процесс установления соединения при использовании 802.1X: