По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Каждое семейство операционных систем производит загрузку по-своему. Это связанно с различной архитектурой ядра операционной системы, разными инструкциями по работе с подключенными устройствами. В данной статье попробую разобрать загрузку популярной операционной системы на ядре Linux Ubuntu.
Схематично процесс загрузки можно отобразить следующим образом.
Загружаемся
Итак, Нажимаем кнопку включения компьютера, и центральный процессор переходит на адрес BIOS. BIOS или UEFI, в более современных компьютерах, проводит систему проверок и выбирает носитель информации с которого будет производится загрузка операционной системы. На носителе находится MBR (Master Boot Record) или GPT (Guid Partition table) на новых компьютерах в которых находится загрузчик. А дальше уже в зависимости от настройки. Загрузчик может самостоятельно загружать операционную систему, а может передавать управление следующему загрузчику. Например, если Windows и Linux установлены на одном компьютере и находятся на разных разделах жесткого диска.
В любом случае, если идет речь о Linux у нас есть первая стадия с небольшой частью кода, которая загружает у нас загрузчик. Загрузчик знает где лежит ядро операционной системы, загружает ядро, загружает initial run disk, там находятся необходимые файлы и модули для загрузки ядра. Далее уже ядро берет процесс управления на себя. Происходит инициализация устройств, конфигурирование процессов памяти и так далее. После всех этих процессов ядро запускает процесс init.
Вернемся к вопросу загрузчиков, для каждой операционной системы разработан свой загрузчик, а иногда и несколько. NTLDR - Загрузчик операционной системы Windows, LILO - один из стандартных загрузчиков для Linux и BSD системы. GRUB - загрузчик операционной системы от проекта GNU. Нас интересуют последние два. Данные загрузчики работают в два этапа. На первом этапе у них крошечный код на MBR или GPT, который запускает исполнение кода второго этапа.
Перейдем непосредственно к самой загрузке.
Данное меню мы можем получить при загрузке если зажать клавишу Shift. Как видно на картинке в данном примере загрузчик GRUB версии 2.04. У нас есть несколько вариантов. Загрузка Ubuntu по умолчанию и вариант загрузки с расширенными опциями. В нашем случае расширенные опции не дают многого, а всего лишь позволяют начать загрузку в режиме восстановления recovery mode. Данная опция не является целью стати, и мы ее опустим. Вернемся к первому пункту загрузки. Выбираем, нажимаем "e" получаем следующую картину загрузки.
На данной картинке можно увидеть, что корневой раздел монтируется по uuid, он будет корневым root и непосредственно сам id. ID раздела можно посмотреть после загрузки операционной системы командой blkid. Можно часть параметров отредактировать или большинство. Более подробно можно поискать в интернете. По нажатию F10 осуществляется продолжение загрузки операционной системы.
После загрузки операционной системы, мы можем с помощью команды dmesg посмотреть, сообщения ядра, все что происходило с ядром. Нужно различать сообщения ядра и лог ядра. Который можно посмотреть cat /var/log/dmesg. Данный файл содержи информацию только о загрузке операционной системы. В данном файле содержится информация с самого начала загрузки операционной системы и до конца. Если событие происходит позднее, то в данном файле этой информации вы не найдете.
Система инициализации ОС
Есть такое понятие Init - это первый или родительский процесс, который запускает все последующие процессы. Это может быть проверка и монтирование файловых систем запуск служб и.т.д. Существует 3 варианта работы этого родительского процесса.
Init в стиле SysV - родительский процесс инициализации системы на одном из заданных уровней запуска (runlevel); Т.е. есть несколько уровней загрузки (runlevel) обычно их 7 штук. Один из них - это обычный многопользовательский режим. Другие это выключение компьютера, перезагрузка, режим восстановления и т.д.
Init в стиле systemd - родительский процесс инициализации системы в ускоренном режиме, за счёт параллельного запуска задач; Ускоренный режим достигается за счет использования процессора в частности Intel, который позволяет запускать процессы инициализации параллельно. К этому режиму есть еще куча софта библиотек, которые расширяют функционал.
Init в стиле Upstart - родительский процесс инициализации системы на основе отслеживания событий; Данный режим используется на Ubuntu уже давным - давно, тут не только запускаются скрипты инициализации, но и запускаются скрипты отслеживания событий и реагирования на них. Т.е. это более гибкий процесс инициализации, например, если какая-то служба не запустилась или упала в процессе загрузки то, upstart умеет это отследить и запустить это повторно
В операционной систему Ubuntu можно посмотреть дерево процессов использую команду pstree. В результате ее вывода мы можем увидеть, что родительским процессом являлся процесс systemd. Который запускал уже свои, какие-то дочерние процессы. Перейдем в корневую директорию boot.
Здесь мы можем увидеть директорию загрузчика grub. Ядра линуксовые vmlinuz (ссылка на ядро) и до обновления старое ядро vmlinux.old (ссылка на старое ядро). Соответственно пара initrd* - файлы диска, эти файлы содержат диск, который грузится в оперативную память, данный диск содержит файлы необходимые самому ядру Linux для нормальной загрузки.
Перейдя в директорию grub, мы можем найти конфигурационный файл grub.cfg и несколько вспомогательных, но не менее важных фалов. Соответственно мы можем внести изменения в данный файл на постоянной основе и соответственно данный код будет выполнятся при каждой загрузке операционной системы.
Друг, на днях к нам в офис подъехал E1 - шлюз от китайского вендора Dinstar модели MTG200-1-E1. Взяв в руки коробку мы устремились в лабораторию – скрещивать шлюз с E1 потоком со стороны ТфОП и с IP – АТС Asterisk другой.
Коротко про шлюз
Произведем небольшой «анбоксинг» шлюза. Изделие поставляется в коробке и защищено специальной пленкой:
В комплект поставки входит:
Ethernet – кабель;
Провод для подключения E1 потока;
Консольный кабель;
Сам шлюз;
На фронтальной панели MTG200 расположились:
Индикатор питания;
Индикатор «алярмов»;
Физический разъем, предназначенный для сброса настроек устройства к заводским;
Консольный порт;
Индикация E1/T1 и Fast Ethernet интерфейсов;
Разворачиваем шлюз на 180 градусов и видим:
Разъем для подключения питания;
Физические интерфейсы для E1/T1;
Физический интерфейсы для Fast Ethernet;
Вот такой шлюз ожидает своего владельца :) Мы переходим к настройке связки с IP – АТС Asterisk с помощью FreePBX.
Связка со стороны Asterisk
Настройки мы будем выполнять с помощью графического интерфейса FreePBX 14 версии. Подключившись, переходим в раздел Connectivity → Trunks и добавляем новый транк для MTG200 (chan_sip). Дайте удобное для вас имя транка в поле Trunk Name. В разделе Outgoing (исходящие параметры) заполняем:
host=IP_адрес_Dinstar
type=friend
fromuser=логин
username=логин
secret=пароль
qualify=yes
port=5060
context=from-pstn
Переключаемся на вкладку Incoming (входящие параметры) и указываем следующие реквизиты:
disallow=all
allow=alaw&ulaw
canreinvite=no
context=from-pstn
dtmfmode=rfc2833
username=логин
secret=пароль
qualify=yes
insecure=invite
host=dynamic
type=friend
Отлично. Теперь давайте проверим статус этих пиров:
Мы немного забежали вперед, и, как видите, статус нашего входящего пира так же отмечен как OK. Это возможно, только после создания «плеча» в сторону Asterisk на шлюзе. Мы наглядно покажем этот процесс далее.
После, создайте входящий/исходящий маршрут для направления вызовов в нужном направлении или формате. Как это сделать, можно прочитать в этой статье.
Связка со стороны провайдера
Приступаем к настройке шлюза. Провайдер прислал нам следующие параметры:
Каждая настройка сильно зависит от параметров вашего провайдера. Свяжитесь с ним, перед настройкой
CRC выключен
D-канал User
А-номер от Вашей АТС должен приходить 10 знаков с типом National (49Xxxxxxxx)
План нумерации А-номера должен быть ISDN/Telephony
С ними мы и будем работать. По умолчанию, шлюз почти готов к работе – поменяем некоторые параметры. Переходим в раздел PRI Config → PRI Trunk и добавляем новый транк со следующими настройками:
Скорректируем SIP параметры: переходим в SIP Config → SIP Parameter:
Скорректируем SIP параметры: переходим в SIP Config → SIP Trunk. Указываем IP – адрес и порт со стороны Asterisk:
Настроим общие E1/T1 параметры: PSTN Group Config → E1/T1 Parameter :
Готово. Делаем телефонный звонок и проверяем, как занимаются тайм – слоты на нашем шлюзе: Status & Statistics → E1/T1 Status :
Мы сделали входящий звонок – как видите, зеленым цветом, отображается занятый тайм – слот, а сам звонок, улетает по SIP в сторону Asterisk.
Ansible один из двух (наряду с SaltStack) наиболее популярных программных комплексов третьей волны, которые позволяют удалённо управлять конфигурациями. Тем не менее, в сегменте сетевого оборудования лидирует наш сегодняшний герой (если о ПО можно так сказать). В первую очередь это вызвано тем, что Ansible не поставит перед пользователем задачи устанавливать агент на хостинги, требующие от него управления. Тем паче ежели Ваш аппарат взаимодействует с ними через CLI, то Ansible это то, что доктор прописал.
Одним выстрелом три "электронных зайца"
Вообще, прежде чем знакомить уважаемых читателей со сценарием работы в данном программном комплексе, позвольте перечислить несколько его достоинств:
Ansible позволяет параллельно подключать по SSH к устройствам (пользователь может сам определить их число).
Ansible может передавать задачи на подключённые машины.
Ansible способен разбивать машины, входящих в систему, на подгруппы и передавать специальных задачи для каждой подгруппы.
Конечно, указаны не все достоинства Ansible. Просто в данных 3 пунктах, как мне кажется, отражена основная суть работы в данной среде. Выполняя эти три задачи, система автоматически освобождает Вас от головной боли по делегированию задач и функций в компании. Время деньги, как говорится.
Сценарии
Ну и переходим к основному блюду нашего материала - сценариям (playbook). Они состоят из двух частей набора команд для выполнения (play) и конкретных команд (task). Они выполняются друг за другом.
Все записи данных осуществляются с помощью YAMLа. К несомненным плюсам его использования следует отнести то, что он гораздо лучше воспринимается людьми, нежели тот же самый JSON. Ежели Вы больше привыкли Вы к Python, то тут у Вас не возникнет проблем с адаптацией, так как синтаксис у них схожий.
А вот так происходит процесс написания сценария (комментарии даны построчно к выводу):
Имя сценария обязательный элемент для любого сценария;
Сценарий применяется к машинам в подгруппе cisco-routers;
Выключение режима сбора событий в конкретной машине (если не выключить данный режим, то система потратит много времени на решение ненужных задач);
В разделе task указывается список команд для каждого конкретного случая;
После чего происходит выполнение команды:
PLAY [Run show commands on routers] ***************************************************
TASK [run sh ip int br] ***************************************************************
changed: [192.168.100.1]
changed: [192.168.100.3]
changed: [192.168.100.2]
TASK [run sh ip route] ****************************************************************
changed: [192.168.100.1]
changed: [192.168.100.3]
changed: [192.168.100.2]
PLAY [Run show commands on switches] **************************************************
TASK [run sh int status] **************************************************************
changed: [192.168.100.100]
TASK [run sh vlans] *******************************************************************
changed: [192.168.100.100]
PLAY RECAP ****************************************************************************
192.168.100.1 : ok=2 changed=2 unreachable=0 failed=0
192.168.100.100 : ok=2 changed=2 unreachable=0 failed=0
192.168.100.2 : ok=2 changed=2 unreachable=0 failed=0
192.168.100.3 : ok=2 changed=2 unreachable=0 failed=0
И запускаем проверку выполнения команд:
SSH password:
PLAY [Run show commands on routers] ***************************************************
TASK [run s hip int br] ***************************************************************
Changed: [192.168.100.1] => {“changed”: true, “rc”: 0, “stderr”: “Shared connection
To 192.168.100.1 closed.
”, “stdout”: “
Interface IP-Address
OK? Method Status Protocol
Ethernet0/0 192.
168.100.1 YES NVRAM up up
Ethernet0/1
192.168.200.1 YES NVRAM up up
Loopback0
10.1.1.1 YES manual up up
”, “stdout_lines
“: [“”, “Interface IP-Address OK? Method Status
Protocol”, “Ethernet0/0 192.168.100.1 YES NVRAM up
up “, “Ethernet0/1 192.168.200.1 YES NVRAM up
up “, “Loopaback0 10.1.1.1 YES manual up
up “]}
А что внутри?
А теперь поговорим о начинке сценария. Основу составляют переменные. Это могут быть данные о машине, выводы команд, а также их можно вводить вручную.
Главное не забывать правила написания имён. Их всего два:
имена всегда должны состоять из букв, цифр и нижнего подчёркивания;
имена всегда должны начинаться с буквы.
Переменные могут быть определены разными способами:
Инвентарным файлом
[cisco-routers]
192.168.100.1
192.168.100.2
192.168.100.3
[cisco-switches]
192.168.100.100
[cisco-routers:vars]
ntp_server=192.168.255.100
log_server=10.255.100.1
PLAYBOOKом
-name: Run show commands on router:
hosts: cisco-routers
gather_facts: false
vars:
ntp_server: 192.168.255.100
log_server: 10.255.100.1
tasks:
-name: run sh ip int br
raw: s hip int br | ex unass
-name: run s hip route
raw: sh ip route
Специальными файлами, созданными для групп:
[cisco-routers]
192.168.100.1
192.168.100.2
192.168.100.3
[cisco-switches]
192.168.100.100
Или группами каталогов
|– group_vars _
| |– all.yml |
| |–cisco-routers.yml | Каталог с переменными для групп устройств
| |–cisco-switches.yml _|
|
|–host vars _
| |–192.168.100.1 |
| |–192.168.100.2 |
| |–192.168.100.3 | Каталог с переменными для устройств
| |–192.168.100.100 _|
|
|–myhosts | Инвертарный файл
Команда register позволяет сохранять результаты выполнений модулей в переменные. После чего переменная может быть использована в шаблонах, принятиях решений о выполнении заданного сценария.
---
- name: Run show commands on routers
hosts: cisco-routers
gather_facts: false
tasks:
-name: run s hip int br
raw: s hip int br | ex unass
register: sh_ip_int_br_result
---
debug отображает информацию в стандартном потоке вывода в виде произвольной строки, переменной или фактах о машине.
---
- name: Run show commands on routers
hosts: cisco-routers
gather_facts: false
tasks:
-name: run s hip int br
raw: sh ip int br | ex unass
register: sh_ip_int_br_result
-name: Debug registered var
debug: var=sh_ip_int_br_result.stdout_lines
После чего результатом работы станет следующее:
SSH password:
PLAY [Run show commands on routers] ***************************************************
TASK [run sh ip int br] ***************************************************************
changed: [192.168.100.1]
changed: [192.168.100.2]
changed: [192.168.100.3]
TASK [Debug registered var] ***********************************************************
ok: [192.168.100.1] => {
“sh_ip_int_br_result.stdout_lines”: [
“”,
“Interface IP-Address OK? Method Status Protocol”,
“Ethernet0/0 192.168.100.1 YES NVRAM up up “,
“Ethernet0/1 192.168.200.1 YES NVRAM up up “,
“Loopback0 10.1.1.1 YES manual up up “
]
}
ok: [192.168.100.2] => {
“sh_ip_int_br_result.stdout_lines”: [
“”,
“Interface IP-Address OK? Method Status Protocol”,
“Ethernet0/0 192.168.100.1 YES NVRAM up up “,
“Ethernet0/2 192.168.200.1 YES NVRAM administratively down down “,
“Loopback0 10.1.1.1 YES manual up up “
]
}
ok: [192.168.100.3] => {
“sh_ip_int_br_result.stdout_lines”: [
“”,
“Interface IP-Address OK? Method Status Protocol”,
“Ethernet0/0 192.168.100.3 YES NVRAM up up “,
“Ethernet0/2 192.168.200.1 YES NVRAM administratively down down “,
“Loopback0 10.1.1.1 YES manual up up “,
“Loopback10 10.255.3.3 YES manual up up “
]
}
PLAY RECAP ****************************************************************************
192.168.100.1 : ok=2 changed=1 unreachable=0 failed=0
192.168.100.2 : ok=2 changed=1 unreachable=0 failed=0
192.168.100.3 : ok=2 changed=1 unreachable=0 failed=0
Вместо заключения
Можно ещё долго приводить примеры работы в системе, но ещё один факт так сказать "вишенка на торте". К плюсам Ansible следует отнести и то, что заданную команду система может выполнять практически до бесконечности. Пока не наступит требуемый результат трансформации не прекратятся. Пользователю можно не беспокоиться - программа сама всё сделает за Вас, а Вы можете заниматься другими делами.