LINUX практикум. Учебное пособие СанктПетербург 2016
 Скачать 0.55 Mb.
|
|
udevd – демон в пространстве пользователя, который выполняет основные задачи системы, а именно управление файлами в директории /dev. udevadm – утилита для взаимодействия с функциями udev. Утилита udevadm принимает следующие параметры вызова: udevadm info – отображает информацию о текущих устройствах, зарегистрированных в базе данных udev. udevadm trigger – вывод сообщений, отражающих события ядра ассоциированные с устройством. udevadm settle – вывод очереди событий udev. 20 udevadm control – управление состоянием демона udev. udevadm monitor – вывод сообщений ядра uevent и сообщений, инициируемых выполняющимися правилами udev с указанием путей к устройствам. Часто используется для анализа временных интервалов между событиями ядра uevent и событиями, переданными udev. udevadm test – имитация заданных событий udev для выбранного устройства и вывод отладочной информации. Модули ядра ОС Linux Ядро Linux построено по модульному принципу, когда отдельный функционал ядра может динамически добавляться в текущее загруженное ядро путем загрузки соответствующего модуля. Для выполнения задач загрузки и выгрузки модулей ядра задействуются соответствующие утилиты. modprobe – утилита для загрузки и выгрузки модуля из ядра Linux. lsmod – утилита, которая извлекает информацию из файла /proc/modules, и отображает загруженные в данный момент модули ядра. modinfo – утилита отображения сведений об указанном модуле ядра Linux. Описание установки для проведения лабораторной работы Установка для выполнения лабораторной работы представляет собой рабочую станцию, функционирующую под управлением ОС Linux. На каждой рабочей станции установлен пакет VirtualBox, в котором может быть запущена операционная система Linux. Порядок выполнения работы 1. Запуск установки. 1.2 Войдите в систему. Запустите в среде VirtualBox операционную систему Linux. 1.3 Выполните вход в операционную систему Linux. 2. Изучение менеджера устройств udev и утилит работы с модулями ядра ОС Linux. 2.1 Ознакомьтесь с руководством программы udev. 2.2 Ознакомьтесь с возможностями утилиты udevadm. 2.3 Включите udevadm monitor и вставьте какой-либо носитель данных. 2.4 Ознакомьтесь со списком событий, включите скриншот списка в отчет. 2.5 С помощью данного списка событий или любым иным способом (например, командой fdisk –l) запомните название файла устройства (например, sdb1). 21 2.6 Используя название, получите информацию об устройстве, выполнив команду udevadm info --query=all --name=[название файла устройства]. Включите полученную информацию в отчет. 2.7 Перейдите в каталог /lib/udev/rules.d и ознакомьтесь с правилами, используемыми udev. 2.8 Перейдите в /etc/udev/rules.d. В этом каталоге содержатся пользовательские правила, а также правила, необходимые для замены «оригинальных» правил. Создайте файл правила с низким приоритетом (с числом в названии больше 90). 2.9 Включите в файл правило, срабатывающее при вставке носителя: KERNEL=="[ название файла устройства]", ACTION=="add", RUN+="[команда]". команда – выполняемое действие, например /bin/mkdir /home/administrator/new_dir. 2.10 Перезагрузите выполняемые правила, выполнив команду sudo udevadm control –reload-rules. Вставьте носитель, убедитесь в выполнении указанного действия. Включите скриншот содержимого файла с правилом в отчет. 2.11 Попробуйте добавить иные правила. 2.12 Ознакомьтесь с возможностями утилит modprobe, lsmod и modinfo. 2.13 Выведите список загруженных модулей ядра. Включите его в отчет. 2.14 Выберите любой модуль из полученного ранее списка и выведите информацию о нем с помощью modinfo. Включите ее в отчет. 2.15 Выберите любой модуль из набора модулей, хранящихся в /lib/modules, и загрузите его в память. Проверьте, что модуль действительно загружен: для этого снова выведите список работающих модулей. Включите эту информацию в отчет. Требования к оформлению отчета и защите. Отчет должен содержать описание порядка выполнения всех команд и содержание указанных при выполнении работы файлов. При защите отчета, исполнитель должен быть готов ответить на вопросы, касающиеся исследованного функционала. 22 Лабораторная работа №5. Начальная загрузка операционной системы GNU Linux и периодические процессы. Цель работы: Получение навыков написание стартовых скриптов для управления процессами, старт и завершение которых происходит вместе с ОС Linux. Использование системы cron. Теоретические сведения В системе Unix для обеспечения запуска системных и прикладных процессов при старте системы используются системы инициализации типа System V, также возможно использования сходных по функционалу других реализаций. Для управления процессом запуска в различных режимах имеется несколько уровней запуска, при переходе в каждый из уровней осуществляется запуск скриптов из соответствующей директории, с действием, которое происходит (старт или стоп). Для упрощения написания стартовых скриптов имеется возможность использовать пустой файл с уже заданной структурой и форматом имени файла. Такой файл- шаблон называется skeleton, его пример содержится на рисунке 1 ниже: ### BEGIN INIT INFO # Provides: skeleton # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Example initscript # Description: This file should be used to construct scripts to be # placed in /etc/init.d. ### END INIT INFO Рисунок 1 - Файл-шаблон для создания стартового скрипта Описанные в заголовке параметры имеют специальное назначение [skeleton] и указывают на условия, при которых происходит запуск этого стартового скрипта. При написании своего собственного скрипта нужно его логические элементы вставить в соответствующие разделы файла. Таким образом получается единообразная и упорядоченная структура каждого файла запуска и обработка демоном init происходит в нужном порядке и с нужными параметрами. После этого необходимо поместить файл в директорию /etc/init.d и при помощи команды (рисунок 2), добавить в автозагрузку, которая создаст соответствующие ссылки на стартовый скрипт из директорий соответствующих уровней запуска. update-rc.d <имя_скрипта> defaults Рисунок 2 - Команда для обновления ссылок на стартовые скрипты 23 В последних версиях операционных систем Linux все чаще встречается реализация с использованием демона systemd. Его концепция несколько отличается от уровней запуска, хотя и предполагается обратная совместимость скриптовой базы. Первое отличие systemd от традиционного подхода заключается в использовании концепции юнитов – отдельных конфигурационных файлов для каждого аспекта работы сервиса. Типы юнитов бывают: системный сервис, точка автомонтирования, файл устройства и т.д. Сервисные юниты типа service являются аналогами стартовых скриптов System V. Первое различие заключается в расширении системы уровней запуска до целей запуска - targets. С целью обратной совместимости существуют цели, соответствующие семи уровням запуска с 0 до 6. Файлы целей позволяют группировать вместе юниты, используя цепочки зависимостей. Такой подход является гораздо более гибким по сравнению с уровнями запуска. Демон systemd также включает в себя возможности по управлению удаленным узлом посредством протокола ssh. Пример описания сервисного юнита системы регистрации событий представлен на рисунке 3. [Unit] Description=System Logging Service Requires=syslog.socket [Service] Type=notify ExecStart=/usr/sbin/rsyslogd -n StandardOutput=null [Install] WantedBy=multi-user.target Alias=syslog.service Рисунок 3 - Описание сервисного юнита для системы регистрации событий Для запуска различных процессов по расписанию используется системный демон cron. Он позволяет задавать расписание для запуска пользовательских и системных программ. Конфигурационный файл представляет собой набор команд с указанием времени их периодического запуска. Каждая строка имеет вид, показанный на рисунке 4. 0 5 * * 1 cd /var/tmp/updater;./run_update.sh Рисунок 4 - Конфигурационный файл демона cron В начале строки указывается действующее расписание для запуска скрипта, во второй части - строка запуска команды. Расписание имеет вид минуты, часы, день, месяц, день недели. Первые пять столбцов имеют в качестве разделителя пробел, в то время как в команде в качестве 24 разделителей используются стандартные разделители аргумента. На рисунке 4 расписание интерпретируется как запуск скрипта обновления в 05:00 каждый понедельник. Для просмотра конфигурационного файла cron можно воспользоваться командой crontab -l, она покажет расписание для текущего пользователя. Для изменения необходимо запустить команду crontab с ключом e, в таком случае будет запущен текстовый редактор по умолчанию для внесения изменений. Командные строки обрабатываются с использование командного интерпретатора sh, поэтому их вид должен быть соответствующим. Предназначение демона cron обычно связывается с необходимостью запуска периодических задач, необходимых для выполнения обслуживания системы, например: чистка файловой системы, обновление системы, циклическое использование файлов журналов, синхронизация версий файлов, резервное копирование и т.п. Порядок выполнения работы 1. Написать стартовый сценарий, который запускается последним при переходе на режим выполнения в однопользовательском режиме. Стартовый сценарий обязан поддерживать параметры остановки и запуска. 2. В среде, содержащей систему systemd, описать новый тестовый системный юнит, который запускается после монтирования всех файловых систем и сохраняет список смонтированных систем и время в файл журнала. 3. Создать тестовый скрипт и обеспечить его выполнения по расписанию каждую пятницу 2 недели каждого месяца в 01 часов 12 минут. Требования к оформлению отчета и защите Отчет должен содержать описание порядка выполнения всех команд и содержание указанных при выполнении работы файлов. При защите отчета, исполнитель должен быть готов ответить на вопросы, касающиеся написанного стартового сценария и установленного расписания. 25 Лабораторная работа №6. Сетевые средства мониторинга операционной системы Linux. Цель работы: Получение навыков использования утилит мониторинга сети, сбор статистической информации и представление ее в графическом виде. Теоретические сведения Мониторинг за производительностью сетевых средств ОС крайне важен для обеспечения работоспособности целого класса системных и прикладных программ. Мониторинг за сетью в ОС разделяется на три основных направления: Мониторинг работоспособности подключения к сети; Статистика сетевого взаимодействия; Графическое представление графической информации. Необходимость проверки работоспособности возникает при устранении неполадок при подключении компьютера к сетям и во время его эксплуатации. В этом случае характерно применение утилит, позволяющих диагностировать различного рода проблемы при работе сетевых служб. Утилиты различаются по своему назначению от самых простых до достаточно сложных, способных выявлять комплексные ошибки. В любом случае все эти утилиты предоставляют разностороннюю информацию о текущем состояния подключения к сети, для того чтобы администратор вычислительной системы мог самостоятельно, принимая во внимание различные аспекты выявить и устранить ошибки подключения. Самой простой утилитой проверки соединения является программа ping, рисунок 5. Она служит для проверки качества соединения и достижимости сетевыми пакетами целевого узла. Для работы программа использует запросы протокола ICMP и, получая ICMP ответы, показывает статистику доставки пакетов и скорость непосредственно канала между источником и адресатом. Обычный размер запроса составляет 64 байта, но может быть изменен при помощи соответствующего ключа. ping 10.1.5.1 -c 6 PING 10.1.5.1 (10.1.5.1) 56(84) bytes of data. 64 bytes from 10.1.5.1: icmp_seq=1 ttl=64 time=0.223 ms 64 bytes from 10.1.5.1: icmp_seq=2 ttl=64 time=0.178 ms 64 bytes from 10.1.5.1: icmp_seq=3 ttl=64 time=0.256 ms 64 bytes from 10.1.5.1: icmp_seq=4 ttl=64 time=0.241 ms 64 bytes from 10.1.5.1: icmp_seq=5 ttl=64 time=0.237 ms 64 bytes from 10.1.5.1: icmp_seq=6 ttl=64 time=0.245 ms --- 10.1.5.1 ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 4998ms 26 rtt min/avg/max/mdev = 0.178/0.230/0.256/0.025 ms Рисунок 5 - Определение доступности узла при помощи утилиты ping Второй утилитой проверки работоспособности соединения можно назвать traceroute. Особенностью является способность не только определить достижимость по сети целевого узла, но и определить маршрут передачи пакетов. Для отправки запросов утилита может использовать не только ICMP, но и UDP, TCP, GRE. В ходе посылки пакета для определения промежуточных узлов параметр TTL последовательно увеличивается для возможности получения пакета от узла маршрутизатора о том, что время жизни истекло. Этот факт и используется для фиксации очередного узла маршрута следования. Пример трассировки, рисунок 6. traceroute to ya.ru (213.180.193.3), 30 hops max, 60 byte packets 1 192.168.18.1 (192.168.18.1) 0.331 ms 0.430 ms 0.537 ms 2 217-79-5-241.obit.ru (217.79.5.241) 2.529 ms 2.520 ms 2.805 ms 3 vi-xx-1909.kant7-home.255.92.spb.obit.ru (178.16.151.46) 2.486 ms 2.777 ms 2.889 ms 4 vi-xx-1900.ohr1.spb.obit.ru (178.16.151.104) 2.539 ms 2.626 ms 2.615 ms 5 vi-xx-1535.shr2.spb.obit.ru (95.161.159.245) 2.822 ms 2.811 ms 2.935 ms 6 te-0-0-xxx.hnt2.spb.obit.ru (95.161.159.237) 2.921 ms 1.180 ms 2.283 ms 7 vi-xx-1561.ohr1.spb.obit.ru (95.161.159.240) 2.273 ms 2.369 ms 2.359 ms 8 vi-xx-0302.brc1.spb.obit.ru (85.114.1.112) 2.469 ms vi-xx-0303.brc1.spb.obit.ru (85.114.1.114) 2.448 ms 2.442 ms 9 vi-xx-1692.zs33.0.196.spb.obit.ru (79.142.92.103) 2.522 ms 2.610 ms 2.598 ms 10 diana-spb-ix.yandex.net (194.226.100.90) 16.139 ms 16.128 ms 16.116 ms 11 m9-p2-100ge-2-0-3.yndx.net (213.180.213.16) 16.832 ms 17.268 ms 17.399 ms 12 fol5-c2-ae7.yndx.net (87.250.239.84) 10.286 ms 9.997 ms 9.865 ms 13 * * * 14 www.yandex.ru (213.180.193.3) 12.329 ms 16.766 ms 11.709 ms 15 * * * 16 www.yandex.ru (213.180.193.3) 11.494 ms 11.467 ms 10.995 ms Рисунок 6 - Трассировка маршрута утилитой traceroute Использование данной утилиты позволяет не только выяснить доступно ли соединение и в случае отсутствия связи выяснить узел, на котором происходит сбой соединения. В гетерогенных сетях, обладающих сложной конфигурацией соединений данная способность часто оказывается востребованной. Еще одной утилитой, выполняющей трассировку маршрута, является mtr, рисунок 7. Ее отличие заключается в более наглядном представлении результатов и определением статистических параметров скорости и надежности доставки не только по всему маршруту, но и по отдельным его участкам. My traceroute [v0.85] kvm (0.0.0.0) Wed Dec 14 01:55:05 2016 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.18.1 0.0% 22 0.3 0.3 0.3 0.4 0.0 27 2. 217-79-5-241.obit.ru 0.0% 22 1.1 1.1 0.9 2.5 0.2 3. vi-xx-1909.kant7-home.255.92.spb.obit.ru 0.0% 21 1.2 6.8 1.0 66.2 17.6 4. vi-xx-1900.ohr1.spb.obit.ru 0.0% 21 1.0 1.1 0.9 1.9 0.0 5. vi-xx-1535.shr2.spb.obit.ru 0.0% 21 1.0 1.1 1.0 1.2 0.0 6. te-0-0-xxx.hnt2.spb.obit.ru 0.0% 21 1.2 1.1 1.0 1.3 0.0 7. vi-xx-1561.ohr1.spb.obit.ru 0.0% 21 1.2 1.7 1.1 11.8 2.2 8. vi-xx-0302.brc1.spb.obit.ru 0.0% 21 1.4 1.4 1.2 2.1 0.0 9. vi-xx-1692.zs33.0.196.spb.obit.ru 0.0% 21 1.5 1.4 1.2 2.2 0.0 10. diana-spb-ix.yandex.net 0.0% 21 1.5 1.5 1.4 1.6 0.0 11. m9-p2-100ge-2-0-3.yndx.net 0.0% 21 11.0 11.8 10.6 15.3 0.8 12. fol5-c2-ae7.yndx.net 0.0% 21 10.0 10.4 9.8 20.4 2.2 13. www.yandex.ru 0.0% 21 9.5 9.6 9.5 9.8 0.0 Рисунок 7 – Диагностика сетевого маршрута при помощи утилиты mtr Статистические показатели сетевых взаимодействий нужны для целостного представления о среде работы системы. Мониторинг объема трафика может быть необходим для выполнения финансовых расчетов, а также для целей информационной безопасности. Прогнозирование и адекватная оценка максимально возможной производительности узлов невозможно реализовать без исторической информации о нагрузке сетевых интерфейсов высоконагруженных сервисов. Для этих целей можно использовать следующие утилиты: iptraf, dstat, iftop. Iptraf, являясь консольной программой, имеет интерфейс, который позволяет выполнить мониторинг нагрузки на разных интерфейсах, а также с различными опциями, для обеспечения детального анализа нагрузки на сетевом канале. Dstat является модульной утилитой для мониторинга за показателями производительности системы, в случае анализа сетевой активности необходимо использовать с ключом -net. Утилита может работать в интерактивном режиме и показывать текущие значения в активной консоли. Также поддерживается возможность сохранения в файл для последующего анализа. Для визуализации информации о загрузке сетевого интерфейса лучше всего подходят следующие утилиты: mrtg и rrdtool. Наиболее старой из указанных утилит визуализации является mrtg. Утилита позволяет отображать в виде графика информацию не только по загруженности канала, но и другие данные, которые необходимо визуализировать в независимости от их происхождения (использование оперативной памяти, потребление электроэнергии и т.п.), хотя изначально разрабатывалась для мониторинга сетевого трафика. Для работы с |