Системное и сетевое администрирование практическое руководство

Системное и сетевое администрирование. Практическое руководство

Данная глава имеет очень специфичную тему: обновление операционной системы отдельного узла. Эта задача, хотя и выглядит обманчиво простой, на самом деле требует большого объема предварительной подготовки и последующего тестирования.

Само по себе обновление может осуществляться различными способами. Чем более критичен узел, тем важнее правильность выполнения обновления. Этот метод является строительным блоком.

После его детального изучения вы можете перейти к более крупным проектам по обновлению, рассмотренным в главе 20.

Для успешного выполнения этой задачи требуется единственное средство, вне зависимости от типа операционной системы. Это средство – лист бумаги, который будет использоваться для создания контрольного списка. Использование этого средства обязательно.

Некоторые люди предпочитают имитировать лист бумаги при помощи веб-страницы, википедии или электронной таблицы. Такие высокотехнологичные решения имеют преимущества, которые будут рассмотрены позднее. Однако принцип один: обновлять сервер без контрольного списка недопустимо. Возьмите карандаш, давайте начнем.

Основы

Принципиальная задача любого обновления ОС состоит в том, чтобы как минимум все службы, которые предоставлялись до обновления, работали после обновления. Обновление может проводиться для того, чтобы расширить функциональность или надежность, но оно не должно их снижать. Учитывая это, процесс имеет следующую структуру.

1. Составьте контрольный список служб:

a. Какие службы предоставлялись сервером?

b. Кто является пользователем каждой службы?

c. Какие программы предоставляли каждую службу?

2. Проверьте, чтобы каждая программа работала с новой ОС, или запланируйте путь обновления программного обеспечения.

3. Для каждой службы разработайте тест на проверку работоспособности.

4. Напишите план отмены с конкретными условиями.

5. Выберите технический перерыв.

6. Объявите об обновлении в необходимом порядке.

7. Выполните ранее разработанные тесты, чтобы убедиться, что они действенны.

8. Заблокируйте пользователей.

9. Проведите обновление с наблюдением/помощью (или под руководством) другого человека.

11. Если тесты будут неудачными или произойдут другие события, которые являются условиями для выполнения плана отмены, выполните план отмены.

12. Разблокируйте пользователей.

13. Сообщите пользователям о завершении/отмене обновления.

14. Проанализируйте, что прошло правильно, а что нет, измените контрольный список в соответствии с приобретенным опытом.

А вы думали, что нужно всего лишь воспользоваться установочным диском, не так ли? Давайте более подробно рассмотрим каждый этап.

Этап 1: составьте контрольный список служб

Контрольный список служб – это средство, которым вы будете пользоваться для проведения всей процедуры. Список должен отражать, какие службы предоставляются узлом, кто пользуется каждой службой и какая программа предоставляет каждую службу.

Электронные таблицы – отличный способ представления такой информации. Самым большим преимуществом представления этой информации в электронном виде является то, что ее смогут легко совместно использовать персонал и пользователи.

Лучше предоставить доступ к файлу через Интернет, чем отправлять его каждому человеку, потому что версию в Сети можно быстро обновить. Люди всегда будут видеть самые последние обновления. Однако Сеть предполагает наличие механизмов активной доставки. Люди не будут искать файл сами.

Вы можете включать URL в каждое электронное письмо, касающееся проекта, но это не даст гарантии, что его прочтут. Правильная идея – объявлять о любых значительных обновлениях.

Дважды проверьте свои планы, устройте собрание ключевых представителей затрагиваемого сообщества. Покажите им план, шаг за шагом, попросите их проверить ваши предположения. Наиболее эффективно начать процесс с собрания, а затем пользоваться для обновления электронной почтой, устраивая другие личные встречи, возможно, только в ключевые моменты процесса.

…

Этап 2: проверьте совместимость программ

Следующий этап – убедиться, что каждая программа сможет работать с новой ОС, и запланировать способ обновления для тех программ, которые не будут работать. Используя список, созданный ранее, свяжитесь с разработчиками и узнайте, будет ли работать версия программы после обновления. Часто разработчики предоставляют такую информацию на своих веб-сайтах.

Вы можете захотеть сами проверить достоверность информации или найти другого пользователя, который уже сделал обновление. Представления разработчиков о том, что значит «версия будет работать», часто не включают функции, которые нужны в вашей компании, или точную конфигурацию, которую вы определите.

Если обновление автоматизировано и будет повторяться тысячи раз и потенциальная ошибка будет сильно заметна, тестирование необходимо.

Если используемая версия программы будет работать с новой версией ОС, зафиксируйте, где вы нашли эту информацию, для справки в будущем. Если программа не поддерживается новой ОС, у вас есть несколько вариантов.

• Обновление до версии, которая поддерживается обеими ОС. Если вам повезет, то программу можно обновить до версии, которая работает как в нынешней, так и в будущей системе. Если это возможно, запланируйте обновление до этой версии до обновления ОС. Здесь могут быть полезны тесты, разработанные на этапе 3.

• Обновление возможно, но работает только в новой ОС. В данном случае вы должны запланировать обновление программы после завершения обновления ОС. В зависимости от требований пользователей, это обновление либо может быть элементом обновления ОС, либо можно договориться о перерыве в работе службы, если пользователям не нужен непрерывный доступ. Например, если узел – загруженный веб-сервер, пользователи могут потребовать немедленной установки нового программного обеспечения, потому что это основная функция узла. Однако, если требуется обновить редко используемый компилятор, пользователи могут просто попросить, чтобы он был обновлен на следующей неделе или перед завершением определенного цикла разработки. Это особенно справедливо, если пока для компиляции можно пользоваться другим узлом.

• Продукт больше не поддерживается. Иногда мы только при обновлении операционной системы узнаем, что продукт больше не поддерживается разработчиком. Это может заблокировать обновление, либо пользователи могут пожелать сменить поставщиков или отказаться от этого продукта.

Этап 3: тесты для проверки

После того как будет определена каждая служба, нужно разработать тесты, которые будут использоваться для проверки того, что служба правильно работает после обновления. Лучший сценарий – записать все тесты в виде скриптов, которые могут быть запущены автоматически. Можно создать общий скрипт, который выводит сообщение «ОК» или «FAIL» (Неудачное завершение) для каждого теста.

Затем можно запускать тесты отдельно по мере устранения конкретных проблем. Для более сложных служб пользователи могут писать тесты или, по крайней мере, просматривать их либо предложить, чтобы их вызвали для выполнения вручную их собственных тестов. Некоторые программы имеют средства тестирования установки, которые могут быть запущены для проверки.

Иногда эти средства проверки недоступны пользователям, но их можно получить через представителя разработчика.

Процедуры проверки программ

Все программные пакеты должны иметь процедуры проверки, но так редко бывает на самом деле. Иногда такую процедуру лучше написать самому. Тесты могут простыми, такими как проверка компилятора при помощи компиляции программы Hello, World. Один тест гораздо лучше, чем их полное отсутствие.

Иногда процедура проверки предоставляется, но на самом деле не работает. Один из поставщиков суперкомпьютеров был известен наличием плохих проверочных баз данных, особенно в бета-версиях ОС.

В обществе программистов для описания определенного способа проверки используется термин регрессивное тестирование. Вы сохраняете выходные данные старой системы, вносите изменение, а затем сохраняете выходные данные новой системы. Результаты должны точно соответствовать. Если ожидается, что новый результат будет немного отличаться, вы можете отредактировать базовый вариант вручную, чтобы он отражал ожидаемые изменения, либо воспользоваться алгоритмом нечеткого соответствия.

Для сравнения результатов можно воспользоваться простыми средствами. Например, UNIX-программа diff – это очень полезное средство, которое сравнивает два текстовых файла и указывает на различия между ними. Программа diff имеет ограниченные возможности по оценке нечеткого соответствия, опция -w делает одинаковым все незаполненное пространство.

Более сложные средства регрессивного тестирования могут программироваться на игнорирование конкретных изменений, обычно основанных на системе стандартных выражений. Однако такая сложность необязательна. Вы можете вручную изменить старый результат – сначала сделайте резервную копию! – чтобы отразить отличия, ожидаемые в новом результате. Например, вы можете изменять номера версий, чтобы они соответствовали новым программам.

Прекрасные примеры регрессивного тестирования приведены в книге Кернигана и Пайка «The Practice of Programming» (Kernighan and Pike 1999), как и процедура установки perl (посмотрите, как реализованы тесты make tests).

Иногда тесты могут быть простыми, как при компиляции и запуске программы Hello, world! для проверки работы компилятора. Это может быть определенная последовательность команд или щелчков мышью, после которой можно посмотреть, отображается ли ожидаемый результат. Однако будьте внимательны, чтобы такие тесты не оказались поверхностными.

Вы должны проверять тесты так же подробно, как любую другую службу. Вы ведь не захотите, чтобы при запуске тестов были какие-то сомнения в том, закончился ли тест неудачно из-за обновления или из-за ошибки в самом тесте.

Заманчиво выполнить эти тесты вручную. Однако помните, что каждый тест будет выполнен как минимум три раза и даже больше, если возникнут проблемы. В этом преимущество автоматизации тестов. Если тесты достаточно общие, ими можно будет снова воспользоваться при дальнейших обновлениях. В конце концов, ими можно пользоваться регулярно просто для устранения проблем или в качестве средств мониторинга для обнаружения сбоев прежде, чем их обнаружат ваши пользователи.

Автоматизированные тесты хорошо подходят для программ, которые выводят предсказуемые текстовые данные, но их гораздо сложнее использовать для графических программ, сетевых служб, например NFS, или для таких физических действий, как печать.

Тестирование сетевых служб, имеющих простые текстовые протоколы, таких как электронная почта (SMTP, POP, IMAP) или веб-службы (HTTP), может быть автоматизировано при помощи простых скриптов, использующих средства типа netcat для отправки и получения текста протокола на соответствующий сетевой порт.

Для других программ и служб вы можете найти специализированные тестовые системы, но они обычно очень дорогие. В таких случаях вам придется тестировать их вручную, документируя несколько ключевых функций для проверки или последовательность операций для выполнения. Рано или поздно каждый оказывается в такой ситуации, и все мы должны жаловаться разработчикам, пока они не обеспечат возможность автоматизированного тестирования своих продуктов.

Несмотря на то что автоматизировать все тесты предпочтительно, это не всегда возможно. Некоторые тесты слишком трудно автоматизировать, либо они требуют физического наблюдения. Даже если вы автоматизировали все тесты, то, если вам покажется, что требуется дополнительное тестирование вручную, выполните его. Иногда человеческий глаз видит то, что не может обнаружить лучшая автоматизация.

Разработка через тестирование

TDD (Test-Driven Development) – это относительно новая тенденция в отрасли. Раньше разработчики писали код, а затем создавали тесты, чтобы его проверить (ну, на самом деле это было не так, редко у кого-то было время создавать тесты). TDD – это обратный процесс. Сначала пишутся тесты, а затем – код. Это обеспечивает создание тестов для всего нового кода.

Так как тесты выполняются автоматически, вы строите структуру тестов, которая сохраняется с проектом. По мере развития кода снижается риск того, что изменение нарушит функциональность и это не будет замечено. Разработчики свободно могут переписывать, или перестраивать, большие либо маленькие элементы кода, зная, что, если они что-то нарушат, это будет сразу замечено.

В результате программы содержат меньше ошибок.

Тесты лучше комментариев в коде (документации), потому что комментарии часто устаревают и никто этого не замечает. Тесты, которые охватывают все граничные условия, гораздо более подробны, чем любая документация. Тесты не устаревают, потому что они могут быть включены как элемент процесса разработки, чтобы предупреждать разработчиков об ошибках, которые те внесли в код.

Нам бы хотелось, чтобы и в области системного администрирования изучали TDD и применяли такие методы.

Источник: https://scanlibs.com/sistemnoe-i-setevoe-administrirovanie-prakticheskoe-rukovodstvo/

Сетевое администрирование

Тема книги — построение сетей на основе протоколов TCP/IP для систем Linux, Solaris, BSD и System V и сетевое администрирование этих сетей.

Подключив компьютер к сети, будь то «Всемирная паутина», или локальная сеть, он включается во взаимодействие с другими системами, происходит обмен данными по определенному набору правил (протоколам).

Существует множество различных сетевых протоколов для разных топологий сетей. IP — основной протокол объединивший отдельные компьютеры во всемирную сеть — Интернет, а также и локальные сети.

Из книги вы узнаете зачем нужны протоколы ( в том числе и RIPv2, OSPF и BGP), как они работают, происходит адресация и маршрутизация, передаются данные по сети, как работают сетевые службы: DNS, сервера Apache, sendmail, Samba, РРР и DHCP. Научитесь грамотно настраивать параметры безопасности и обслуживать сетевые соединения, а также полностью выполнять сетевое администрирование созданных сетей.

В третьем издании добавлена новая глава, посвященная настройке сервера Apache и раздел по настройке Samba для создания совместного доступа к файлам и принтерам в смешанной сети Unix-Windows. В приложениях (в конце книги) приводится описание синтаксиса для программ: gated, pppd, named, dhcpd и sendmail. Книга предназначена для системных и сетевых администраторов Unix систем.

ISBN-10:5-93286-056-1

ISBN-13:978-5-93286-056-4

1. Обзор TCP/IP 18Интернет и TCP/IP 19Модель обмена данными 24Архитектура протоколов TCP/IP 27Уровень доступа к сети 30Уровень Internet 30Транспортный уровень 36Прикладной уровень 41

Резюме 42

2. Доставка данных 43Адресация, маршрутизация и мультиплексирование 43Адрес IP 45Архитектура маршрутизации в Интернет 55Таблица маршрутизации 57Разрешение адресов 64Протоколы, порты и сокеты 65

Резюме 71

3. Сетевые службы 72Имена и адреса 73Таблица узлов 74DNS 75Почтовые службы 83Серверы файлов и печати 98Серверы настройки 100

Резюме 106

4. Начинаем работу 108Связанные и не связанные с Интернетом сети 109Базовые сведения 110Планирование: маршрутизация 122Планирование: служба имен 126Прочие службы 130Что сообщить пользователям 132

Резюме 133

5. Базовая настройка 134Настройка ядра 134Загрузочные файлы 151Демон Internet 158Расширенный демон Internet 160

Резюме 161

6. Настройка интерфейса 163Команда ifconfig 164TCP/IP и последовательные линии 180Установка РРР 183

Резюме 201

7. Настройка маршрутизации 203Варианты настройки маршрутизации 203Простейшая таблица маршрутизации 204Создание статической таблицы маршрутизации 206Протоколы внутренней маршрутизации 212Протоколы внешней маршрутизации 224Демон шлюзовой маршрутизации 228Настройка gated 230

Резюме 241

8. Настройка DNS 243BIND: служба имен Unix 243Настройка DNS-клиента 245Настройка демона named 249Работа с nslookup 268

Резюме 272

9. Локальные службы сети 273Сетевая файловая система (NFS) 274Совместный доступ к принтерам Unix 295Samba и Windows: совместный доступ к ресурсам 302Сетевая информационная служба (NIS) 312DHCP 317Управление распределенными серверами 322Серверы почтовой службы 326

Резюме 329

10. sendmail 330Назначение sendmail 331sendmail в роли демона 332Псевдонимы sendmail 333Файл sendmail.cf 336Язык настройки sendmail.cf 343Переписывание почтового адреса 356Изменение файла sendmail.cf 367Тестирование sendmail.cf 371

Резюме 380

11. Настройка Apache 382Установка сервера Apache 383Настройка сервера Apache 386Постигаем файл httpd.conf 390Безопасность веб-сервера 413Шифрование 423Управление веб-сервером 432

Резюме 434

12. Сетевая безопасность 435Планирование безопасности 436Проверка подлинности пользователей 442Безопасность приложений 458Наблюдение за безопасностью 460Управление доступом 466Шифрование 477Брандмауэры 484Последнее напутствие 493

Резюме 494

13. Разрешение проблем TCP/IP 495Подход к проблеме 495Инструменты диагностирования 498Проверка наличия подключения 501Разрешение проблем доступа к сети 504Проверка маршрутизации 512Проверка службы имен 518Анализ проблем протоколов 534Пример исследования для протокола 537

Резюме 541

Приложения

A. Инструментарий РРР 543B. gated, справочник 570C. named,справочник 619D. dhcpd, справочник 660E. sendmail, справочник 675F. Файл httpd.conf в Solaris 748G. Выдержки из RFC 767

Алфавитный указатель 775

Скачать книгу бесплатно24,6 мб. pdf

Источник: https://www.htbook.ru/kompjutery_i_seti/setevye_tekhnologii/setevoe-administrirovanie