пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сразу к делу. На рисунке 1 показана базовая конфигурация STP (Spanning Tree Protocol).
Рис. 1 Базовая конфигурация STP
По умолчанию функция STP коммутатора включена. Если STP отключен, используйте команду stp enable в системном режиме, чтобы включить STP.
# На S1 установите режим работы связующего дерева на STP. Используйте режим stp {mstp | rstp | stp}, с помощью которой вы можете установить режим MSTP, RSTP или STP. По умолчанию установлен режим MSTP.
<Quidway> system-view
[Quidway] sysname S1
[S1] stp mode stp
# На S2 установите режим работы связующего дерева на STP.
<Quidway> system-view
[Quidway] sysname S2
[S2] stp mode stp
# На S3 установите режим работы связующего дерева на STP.
<Quidway> system-view
[Quidway] sysname S3
[S3] stp mode stp
# На S4 установите режим работы связующего дерева на STP.
<Quidway> system-view
[Quidway] sysname S4
[S4] stp mode stp
Даже если STP автоматически выберет корневой мост, мы сначала назначим коммутатор ближе к центру сети. Структура сети показана на рис. 1 простая: S1 и S2 подключены через Интернет, а основные коммутаторы, S3 и S4, являются коммутаторами доступа. Мы можем изменить приоритет моста S1, чтобы гарантировать, что S1 будет выбран в качестве корневого моста. Команда stp priority priority используется для установки приоритета моста устройства; значение приоритета колеблется от 0 до 61440 с шагом 4096. Значение по умолчанию-32 768. Чем меньше приоритет, тем больше вероятность того, что устройство будет выбрано в качестве корневого моста. Вы также можете использовать команду stp root primary для обозначения S1 в качестве корневого моста. После выполнения команды на устройстве значение приоритета моста устройства автоматически устанавливается равным 0. Приоритет моста устройства не может быть изменен после этого с помощью команды stp priority priority.
[S1] stp root primary
Затем мы назначим S2 вторичным корневым мостом, чтобы S2 заменил S1 в качестве нового корневого моста в случае сбоя. После запуска на устройстве команды stp root secondary значение приоритета моста устройства автоматически устанавливается на 4096 и не может быть изменено после этого с помощью команды stp priority priority.
[S2] stp root secondary
На этом базовая конфигурация STP сети завершена. Чтобы проверить состояние и статистику дерева SPT, вы можете запустить display stp [interface interface-type
interface-number] [brief]
На S1 используйте команду display stp brief для отображения основной информации STP.
В выводимых данных видно, что, поскольку S1 является корневым мостом, GE0 / 0/2 и GE0 / 0/1 S1 являются назначенными портами в состоянии normal forwarding.
Следующий вывод - это основная информация STP S4.
Интерфейс GE0/0/2 коммутатора S4 является корневым портом в состоянии normal forwarding. Однако его порт GE0/0/1 является альтернативным портом в состоянии блокировки.
OpenNMS - бесплатный, расширяемый, легко масштабируемый продукт уровня предприятия с открытым исходным кодом. Он проверяет состояние удалённых устройств и собирает информацию об этих хостах при помощи SNMP и JMX (Java Management Extensions). Система основана на Java поэтому поддерживает все популярные операционные системы.
OpenNMS работает под управлением таких операционных систем, как Linux и Windows и поставляется с веб-консолью для упрощения добавления сетевых устройств и приложений в систему. Вся информация, введенная в систему, хранится в базе данных Postgres.
Системные требования OpenNMS
Debian 9.0 и выше, Ubuntu 16.04 LTS и выше;
Пакет OpenJDK 11 Development Kit;
2 CPU, 2 Гб RAM, 20 Гб жесткого диска.
В этом материале покажем, как устанавливать свежую версию системы мониторинга OpenNMS Horizont на Debian и Ubuntu.
Шаг 1. Развертывание Java-OpenJDK 11 на Ubuntu
Для начала скачает свежую версию OpenJDK Java 11 при помощи следующей команды:
$ sudo apt-get install openjdk-11-jdk
Затем убеждаемся, что установлена самая последняя версия Java
$ java -version
После этого устанавливаем переменную среду для всех пользователей при загрузке. Чтобы сделать это нужно добавить в файл /etc/profile следующие строки.
export JAVA_HOME=/usr/lib/jvm/java-1.11.0-openjdk-amd64
Сохраняем файл и выполняем следующую команду, чтобы система заново прочитала файл /etc/profile.
$ source /etc/profile
Шаг 2. Установка OpenNMS Horizon на Ubuntu
Чтобы развернуть OpenNMS Horizon, в файл /etc/apt/sources.list.d/opennms.list следует добавить репозиторий и GPG ключ, а затем обновить кеш apt командой ниже:
$ cat EOF | sudo tee /etc/apt/sources.list.d/opennms.list
deb https://debian.opennms.org stable main
deb-src https://debian.opennms.org stable main
EOF
$ wget -O - https://debian.opennms.org/OPENNMS-GPG-KEY | apt-key add -
$ apt update
Далее скачиваем мета-пакеты OpenNMS (opennms-core и opennms-webapp-jetty) со всеми зависимостями (jicmp6 и jicmp, postgresql и postgresql-libs).
$ sudo apt install opennms
Затем с помощью утилиты tree, проверяем, что мета-пакеты OpenNMS установлены в директорию /usr/share/opennms
$ cd /usr/share/opennms
$ tree -L 1
На заметку: Чтобы предотвратить внеплановые обновления, после установки рекомендуется отключить репозиторий OpenNMS
$ sudo apt-mark hold libopennms-java libopennmsdeps-java opennms-common opennms-db
Шаг 3. Инициализация и установка PostgreSQL
В Debian и Ubuntu сразу после установки пакетов программа установки определяет базу данных Postgres, запускает службу и добавляет его в автозапуск при старте системы.
Чтобы проверить, работает ли служба, выполните указанную ниже команду:
$ sudo systemctl status postgresql
Далее делаем вход под пользователем postgre и создаём пользователя opennms и задаем пароль.
$ sudo su - postgres
$ createuser -P opennms
$ createdb -O opennms opennms
А теперь в целях безопасности назначим пользователю postgres пароль:
$ psql -c "ALTER USER postgres WITH PASSWORD 'YOUR-POSTGRES-PASSWORD';"
На данном этапе следует настроить доступ OpenNMS Horizon к базе данных. Для этого редактируем файл конфигурации.
$ sudo vim /usr/share/opennms/etc/opennms-datasources.xml
Найдите в данном файле указанные ниже разделы и введите учетные данные
jdbc-data-source name="opennms"
database-name="opennms"
class-name="org.postgresql.Driver"
url="jdbc:postgresql://localhost:5432/opennms"
user-name="opennms-db-username"
password="opennms-db-user-passwd" /
jdbc-data-source name="opennms-admin"
database-name="template1"
class-name="org.postgresql.Driver"
url="jdbc:postgresql://localhost:5432/template1"
user-name="postgres"
password="postgres-super-user-passwd" /
Сохраните изменения и закройте файл.
Шаг 4. Инициализация и запуск OpenNMS Horizon
Чтобы инициализировать OpenNMS, необходимо интегрировать его с Java. Итак, для обнаружения среды Java и добавления её в файл конфигурации /usr/share/opennms/etc/java.conf выполните следующую команду:
$ sudo /usr/share/opennms/bin/runjava -s
Затем, следует проинициализировать базу данных и найти библиотеки, указанные в файле /opt/opennms/etc/libraries.properties, с помощью следующей команды:
$ sudo /usr/share/opennms/bin/install -dis
После этого запускаем службу OpenNMS используя systemd, затем добавляем её в автозапуск и проверяем статус следующими командами:
$ sudo systemctl start opennms
$ sudo systemctl enable opennms
$ sudo systemctl status opennms
Если в системе установлен межсетевой экран ufw, следует открыть порт 8980
$ sudo ufw allow 8980/tcp
$ sudo ufw reload
Шаг 5. Подключение к веб-консоли OpenNMS
Теперь запускаем любимый браузер и открываем страницу веб-консоли OpenNMS.
http://SERVER_IP:8980/opennms
или
http://FDQN-OF-YOUR-SERVER:8980/opennms
Далее для входа в систему вводим логин и пароль по умолчанию - admin/admin
После этого вы попадете в панели администратора
В целях безопасности следует поменять предустановленный пароль администратора. Для этого переходим на панели меню выбираем "admin → Change Password", в разделе "User account self-service" нажимаем "Change Password".
Вводим текущий пароль, новый пароль и подтверждаем его, затем нажимаем "Submit". После этого выходим из системы и заходим в нее с новым паролем.
А теперь, время изучать, детальные настройки системы и тонкости управления OpenNMS Horizon через веб-интерфейс, добавлять узлы и приложения, согласно Руководству Администратора OpenNMS.
Хуки в Git — это bash-скрипты, которые запускаются до или после команд Git, например, коммитов и пушей. Они позволяют автоматизировать повторяющиеся действия в вашем репозитории, а также применять фильтры и проверки к рабочему процессу Git.
Что такое Git Hooks?
Итак, Git-хуки идут со специальным именем, в папке:
.git/hooks/
Git будет автоматически вызывать эти функции при выполнении определенных задач, что позволит вам «подключиться» к рабочему процессу Git и изменить его с помощью собственного кода.
Репозитории Git инициализируются с несколькими примерами; чтобы применить их, достаточно откомментировать расширение. Это означает, что у вас будет только один скрипт на один хук. Поэтому если вы хотите выполнять несколько действий, вам нужно будет объединить их или делегировать другим скриптам.
Для чего же их можно использовать? Ну, любая задача, которую может выполнить bash-скрипт, будет работать. Два распространенных варианта использования - автоматическое тестирование и применение фильтров/чеков к исходящим коммитам.
Тесты — важная часть любого рабочего процесса. Хотя Git-хуки абсолютно не заменяют правильного конвейера непрерывной интеграции/непрерывного развертывания (CI/CD), который будет запускать тесты перед проверкой и развертыванием, их локальный запуск поможет вам отловить сбои до того, как они выйдут в свет.
Аналогичным образом, проверка содержимого коммитов для предотвращения распространения нежелательного кода может быть очень полезной, хотя для этого нужно быть достаточно умным, чтобы поймать проблему до того, как она станет проблемой. Если вы часто используете отладочный код, который никогда не должен быть зафиксирован, вы можете проверить это и предотвратить.
Существует множество крючков Git, о которых вы можете прочитать в документации Git'а, но наиболее полезными из них являются:
pre-commit, post-commit
pre-push
post-checkout
commit-msg
Каждый хук будет принимать аргументы для скрипта, к которым вы можете получить доступ с помощью:
$1
,
$2
и так далее.
Совместное использование Git Hooks
Git-хуки предназначены только для локального репозитория и не передаются в удаленный. Вы можете установить любые Git-хуки, какие захотите, не затрагивая своих коллег, так что вы можете, например, создать локальную среду тестирования, которая будет зависеть от настроек вашего компьютера при каждом коммите, без каких-либо проблем.
Если же вы хотите поделиться Git-хуками со своей командой, вы можете создать для них новую папку, которая будет отслеживаться в Git, например:
.githooks
и установить в конфигурации значение:
core.hooksPath
git config core.hooksPath .githooks
Как и хуки по умолчанию, эта конфигурация зависит от репозитория, поэтому вашей команде также нужно будет установить это значение.
Как использовать Git Hooks
Как и большинство методов автоматизации, использование Git-хуков во многом зависит от вас и рабочего процесса вашего репозитория, но есть несколько распространенных вариантов использования.
Если вы хотите проверить содержимое коммитов, вы можете использовать git diff для отображения межстрочной разницы, а затем grep для поиска совпадений. В данном случае он блокирует все использование функции Debug.Log, завершая работу с ненулевым кодом:
if test $(git diff --cached | grep -E "Debug.Log(" | wc -l) != 0 then
exit 1
fi
Или вы можете проверить фактическое сообщение о фиксации. Пример pre-push использует аналогичный тест, но вместо него проверяет вывод git rev-list. Он проверяет коммиты, помеченные как незавершённые работы (WIP), и отказывается их проталкивать.
Еще один распространенный вариант использования - автоматический запуск тестов. Вы сами решаете, хотите ли вы, чтобы это происходило при каждом коммите или только перед отправкой изменений на удаленное хранилище.
В любом случае это просто: запустите свою тестовую команду, получите статус выхода последней команды и выбросите ошибку, если она не выполнилась. В этом примере запускаются тесты для приложения .NET:
#!/bin/sh
exec dotnet test "./UnitTests/UnitTests.csproj" --filter "Category!=Integration"
if [ $? -ne 0 ]; then
echo "Tests must pass before commit!"
exit 1
fi
Есть несколько инструментов, которые помогут в этом; Husky легко запустит тесты NodeJS с настройкой конфигурации в package.json, которая будет применяться и ко всем вашим товарищам по команде.
{
"husky": {
"hooks": {
"pre-commit": "npm test",
"pre-push": "npm test",
"...": "..."
}
}
}
Однако это не замена реальным тестам в авторитетном репозитории. Есть сценарии, в которых ваши локальные тесты могут пройти, но удаленные тесты будут неудачными, а именно в случаях, когда вы не ставите все изменения на поток.