По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Итак, у нас загрузилось ядро операционной системы. Далее отрабатывают системы инициализации операционной системы. Три варианта: SysV, systemd, Upstart.
Init в стиле SysV
Init в стиле SysV данная процедура инициализации, самая старая она более классический Unix вариант инициализации операционной системы. Для того, чтобы понять, как происходит инициализация необходимо понять, что такое режимы загрузки (они же runlevel), разобраться как между ними переключатся, рассмотреть работу со службами.
Обычно есть 7 уровней выполнения по умолчанию:
Выключение
Однопользовательский режим (чаще всего используется для отладки и настройки операционной системы)
DebianUbuntu по умолчанию
RedHatSuse по умолчанию текстовый режим.
WildCard (программируемый режим, можно сюда поставить любой)
RedHatSuse GUI (Graphical User Interface)
Перезагрузка.
Но существуют операционные системы, где 10 уровней по умолчанию. Конечно речь идет о самых распространенных ядрах и сборках *nix образных операционных системах.
Для дальнейших пояснений, как работает инициализация в стиле sysV нам необходим операционная система CentOS 5.4 или ниже, потому что в более новых операционных системах данный процесс давно уже заменен. Отроем файл настроек текстовым редактором vi или любым другим удобным для вас.
Мы можем увидеть содержание файла. Те самые уровни о которых шла речь выше. Плюс прописан уровень используемые при загрузке по умолчанию. Строчка id:3:initdefault:
Мы данный параметр можем отредактировать и например сказать, чтобы операционная система загружалась по умолчанию в Single Mode например.
Если мы посмотрим далее файл, мы можем увидеть настройку, которая описывает действия нажатия клавиш Ctrl+alt-delete. А также наглядно прописано, что запуск определенного уровня - это запуск определённого скрипта. Все скрипты запускаются из папки /etc/rc.d/
Все дальнейшие варианты инициализации растут, вот из этого варианта. И этой процедуры инициализации. Перейдем в директорию, где лежат все скрипты инициализации и выполняются данные скрипты при старте системы.
В данной папке куча скриптов, которые запускают определенные службы, например, ssh запускает демона ssh для подключения клиентом по 22 порту. Т.е здесь куча служб и запускаются они этими скриптами. Если мы например хотим остановить какую нибудь службу то набираем ./rsync stop , ну и соответственно ./rsync start для запуска данной службы. Аналогично мы можем управлять через команду service, например: service rsync restart . Поднимемся на уровень выше cd ..
Найдем все файлы, которые начинаются с rc. Для этого набираем: ls -l | grep rc. В результате мы увидим несколько скриптов.
Посмотрим rc3.d . А для этого перейдем в эту директорию. В ней можно увидеть кучу скриптов. В вариации Ubuntu современной и затем в вариации CentOS 5.4
Те скрипты, которые начинаются с буквы K, эти скрипты при старте убивают сервис, те скрипты, которые имеют первой букву S запускают сервис. Ну и соответственно порядковый номер исполнения скрипта в очереди. Для каждого runlevel свой набор скриптов.
Основные команды
Init управление инициализацией с помощью нее можно перемещаться между runlevel.
Telinit управление процессом init , в старых дистрибутива использовалась именно эта команда.
Wall вывод сообщения пользователям системы
Halt - выключение компьютера
Reboot перезагрузка компьютера
Shutdown - запланированное выключение
Service service_name start|stop|reload|restart
Для того, чтобы перемещаться по уровням загрузки, нам необходимо понять на каком уровне мы находимся сейчас. Набираем runlevel . Соответственно, если мы хотим переключится telinit 1 отрабатывают скипты мы попадаем в однопользовательский режим 1.
Для того, чтобы послать сообщение все пользователям на данной машине необходимо набрать с соблюдением регистра wall "Abrakadabra". У всех пользователей появится данное сообщение на экране.
Для выключения сейчас компьютера можно использовать shutdown h now.
Init в стиле Systemd
Init в стиле Systemd более современная система инициализации операционной системы Linux.
Необходимым элементом работы системы systemd , являются Unit. Unit- это модуль которыми оперирует systemd:
.service службы
.mount точки монтирования
.device устройства
.socket сокеты
Если при работе в консоли мы не указывает расширение юнита, то в принципе system может догадаться в каком случае, что используется. В операционной системе существуют 2 папки в которых хранятся Unit:
/usr/lib/systemd директория с Units по умолчанию, в которой создаются units при установке какого либо программного обеспечения.
/etc/systemd директория с управляемыми Units. Тут лежат те Unit которыми может управлять админ, добавлять , редактировать.
Посмотрим, что находится в данных директориях переходим в /usr/lib/system
Нам интересны 2 директории system и user.
Содержимое папки system выглядит вот так. В данной директории лежат все необходимые Units для системы в директории user для пользователя. Картинка будет примерно аналогичная.
Директория /etc/systemd.
Тут точно также есть две папки system и user, а также конфигурационные фалы. Данные конфигурационные файлы и отвечают за настройку systemd. Это те файлы которые пришли на замену /etc/inittab, предыдущей версии инициализации операционной системы. Файлы юнитов в директориях system и user мы можем редактировать для каких-то своих целей и даже писать targets.
Далее мы можем посмотреть запущенные Units. Для этого мы можем выполнить systemctl команду, она отвечает за все действия с systemd. Для примера команда systemctl list-units нам выведет все запущенные Units, сокеты ,устройства ,точки монтирования.
Можно посмотреть юниты, которые не стартанули systemd failed. А также мы можем управлять юнитами systemctl status|start|stop|restart crond.
Так же Systemd работает с Target (целями).
Есть target которые работают так же как runlevel в классической процедуре инициализации, они не пронумерованы в отличии от runlevel у них есть конкретные имена. В табличке можно посмотреть какие target соотносятся с какими runlevel. Их этих target может быть несколько, потому что target бывают не только загрузочные. Данная система использования target обратно совместимая с системой инициализации. Для переключения мы можем использовать команду telinit. Сами по себе target есть некая группировка юнитов, последовательность вызова юнитов. Это может быть target последовательного вызова нескольких служб и ниже стоящий target.
Текущий уровень мы можем посмотреть командой runlevel. По умолчанию это будет 3. Далее мы можем написать systemctl list-units --type=target
И можно увидеть, что находимся на 3-м уровне также т.к target соответствует. Так же мы можем переключатся между runlevel командой telinit. Например, для перехода в однопользовательский режим telinit 1. А так же мы можем использовать через синтаксис systemctl isolate reboot.target.
Для того чтобы поставить какой-то загрузочный target по умолчанию, необходимо отредактировать загрузчик, вставить параметры ядра, которые будут запускаться. Или сделать проще командой systemctl set-default f multi-user.target (использование например 3 runlevel по умолчанию).
Одной из особенностей system является интересная система журналирования journald. Демон журналов. Эта система уникальна тем, что собирает информацию из разных источников событий и привязывает их к конкретным юнитам и сервисам. Благодаря этому мы можем всю диагностическую информацию просматривать в одном месте. Соответственно находить неисправности и их устранять.
Работает следующим образом:
Journalctl f - показывает события по мере их возникновения.
Journalctl n 10 вывод последних 10 событий
Инициализация Init в стиле
Инициализация Init в стиле upstart это система инициализации, в том стиле которая задумывалась для Ubuntu, и заменила процедуру инициализации, которая пришла из Unix стандартную init процедуру. Процедура инициализации upstart контролирует инициализацию демонов и служб в течении загрузки системы и их остановку если у нас система выключается или нужно переключится в другой режим. Основное отличие от классической процедуры инициализации в том, что задачи и службы останавливаются по событиям и сами события могут генерироваться задачами и службами, могут приняты быть от любого процесса системы. Могут быть службы перезапущены в автоматическом режиме если они вдруг были завершены в аварийном режиме. Еще одно отличие в том, что у данного режима инициализации есть задачи (tasks). Основными понятиями являются службы и задачи. Основное отличие службы от задачи в том, что служба перезапускается если была аварийно завершена, а задача нет.
Процесс инициализации системы по upstart берет конфигурацию из файлов каталога /etc/init каталог файлов-заданий (jobs). Каждый файл отвечает за запуск каждого задания или службы и должен заканчиваться с расширением .conf . Уровни инициализации остались те же самые. Определение и переключение между уровнями выполняются теми же командами, описанными выше. Изменился файл, в котором мы описываем runlevel запуска по умолчанию. И для управления upstart используется утилита initctl.
Как мы видим в каталоге /etc/init находятся конфигурационные файлы Jobs. Каждый отвечает за запуск отдельной службы. Смотрим файл конфигурации простейшего файрвола операционной системы cat ufw.conf
Как мы видим ufw стартует при условии, описанном start on, выключается на определенных runlevel. Файл конфигурации с runlevel по умолчанию находится в файле cat /etc/init/rc-sysinit.conf
Управляются службы простыми командами status ufw start ufw stop ufw. В данной статье мы рассмотрели различные вариации инициализации. Думаю, информация будет очень полезной.
Протокол Spanning Tree (STP) обеспечивает отсутствие петель в топологии любой сети. Помимо предотвращения петель, STP изолирует угрозу от широковещательного шторма в сетях на втором уровне модели OSI (L2). Разберемся в терминах:
Какие бывают порты?
Можно смело выделить 3 вида портов в рамках протокола Spanning Tree. А именно:
Корневой порт (root port)
Выделенный порт (designated port)
Блокированный (альтернативный порт)
Статусы портов
Порт коммутатора может находиться в различных статусах, в зависимости от результата сходимости Spanning Tree:
Блокирован - как видно из названия, данный порт находится в статусе блокировки. Это означает, что порт не участвует в приеме и пересылке фреймов. Все BPDU сообщения от соседних коммутаторов исключаются.
BPDU (Bridge Protocol Data Unit) это фреймы, необходимые для обмена сообщениями между коммутаторами для выбора корневого (root) устройства в рамках механизма протокола STP (Spanning Tree Protocol).
Слушает – коммутатор все еще не участвует в процессе передачи фреймов с данными, но получает и отправляет сообщения BPDU.
Учится – в данном состоянии порт начинает фиксировать MAC – адреса устройств.
Пересылка – в состоянии пересылки, коммутатор может отправлять и принимать фреймы BPDU параллельно с заполнением таблицы MAC - адресов.
Выключен – порт выключен администратором.
Этапы протокола STP
Выбор «корневого» (root) коммутатора.
Выбор «корневого» (root) порта.
Назначение «выделенного» (designated) порта.
Блокировка остальных портов в рамках алгоритма STP.
Выбор корневого коммутатора
Коммутатор с наименьшим идентификатором (ID) выбирается как корневое устройство. Идентификатор коммутатора (switch ID) состоит из следующих компонентов: .
Номер приоритета .
MAC – адрес коммутатора
Например: 24577.00:00:00:00:00:01 / Приоритет. MAC – адрес
В процессе выбора корневого коммутатора, первым делом сравнивается приоритет. Если у двух коммутаторов одинаковых приоритет, то выбор базируется на MAC – адресе устройства.
Выбор корневого порта
Корневой порт выбирается на основании наименьшей «стоимости» пути к корневому коммутатору. Стоимость пути выражается из стоимости линков, ведущих к корневому коммутатору.
Важно отметить:
Корневые порты назначаются только на не корневых коммутаторах.
Один не корневой коммутатор может иметь только один корневой порт.
Выбор назначенного порта
Порт коммутатора, который имеет кратчайший путь к корневому коммутатору - называется «назначенным».
Каждый сегмент (путь) имеет свой назначенный порт.
Назначенные порты определяются на всех коммутаторах (корневых и нет).
Если два порта имеют одинаковую стоимость, сначала учитывается идентификатор устройства (Bridge ID), а затем идентификатор порта (Port ID).
Все остальные порты переходят в альтернативный статус и блокируются.
Пример
До запуска алгоритма Spanning Tree:
Выбор портов
Финальная топология
Салют! Изо дня в день администраторы IP – АТС Asterisk выполняют рутинные действия связанные с обслуживанием: добавить внутренний номер, настроить новый транк и соответствующие маршруты, посмотреть статус пиров и другие итерации. Для облегчения этих действия существует графическая оболочка FreePBX 13. Сегодня хотим рассказать про очень полезную «кастомизацию» этой самой графической оболочки – настройку вкладок и пунктов меню так, как это будет удобно именно Вам :)
Как это работает?
Кастомизацию интерфейса FreePBX можно осуществлять с помощью файла freepbx_menu.conf, который должен быть расположен в директории /etc/asterisk. При загрузке интерфейса, FreePBX проверяет существование этого файла, парсит настройки и отображает их администратору.
Pre-work
Перед началом работы, давайте проверим наличие файла кастомизации в директории /etc/asterisk. Для этого, выполните последовательность следующих команд:
[root@asterisk ~]# cd /etc/asterisk/
[root@asterisk asterisk]# ls -l | grep freepbx_menu.conf
В случае, если файл находится в указанной директории, он будет отображен в выводе последней команды. В противном случае, просто создадим его вручную командой:
[root@asterisk ~]# touch /etc/asterisk/freepbx_menu.conf
Теперь открываем интерфейс FreePBX, и переходим во вкладку Settings → Advanced Settings. Находим параметр Use freepbx_menu.conf Configuration и выставляем его в значение Yes.
Важно! Убедитесь, что в данном пункте меню, параметры Display Readonly Settings
и Override Readonly Settings выставлены в значение Yes.
Процесс настройки
Допустим, мы хотим создать дополнительную вкладку под названием «Основное», куда вынесем пункты настройки внутренних номеров, транков, входящих и исходящих маршрутов и статус Asterisk. Переходим к конфигурации файла. Открываем его для редактирования:
[root@asterisk ~]# vim /etc/asterisk/freepbx_menu.conf
Для редактирования нажимаем «O» на клавиатуре и добавляем следующую конфигурацию:
[extensions]
category=Основные
name=Внутренние номера
[trunks]
category=Основные
name=Линии к провайдеру
[did]
category=Основные
name=Входящие маршруты
[routing]
category=Основные
name=Исходящие маршруты
[asteriskinfo]
category=Основные
name=Статус Asterisk
Синтаксис следующий:
[extensions] - наименование модуля;
category - категория (наименование вкладки, в которой будет отображаться данный модуль;
name - видимое имя для модуля (параметр для удобства);
Дополнительные параметры:
sort - порядок расположения модуля сверху вниз во вкладке;
remove - удалить модуль из рабочей области интерфейса;
Важно! Параметр remove не удаляет модуль с сервера. Он просто не будет отображаться среди доступных для конфигурации модулей в FreePBX.
Готово. Давайте посмотрим, что у нас получилось в FreePBX: