авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 7 | 8 || 10 | 11 |   ...   | 33 |

«The Practice of System and Network Administration Second Edition Thomas A. Limoncelli, Christina J. Hogan and Strata R. Chalup Системное и ...»

-- [ Страница 9 ] --

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

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

242 Глава 7. Сети Наличие единой административной единицы не исключает возможность при влечения групп администраторов из других подразделений или регионов, ко торые должны подчиняться одной и той же структуре управления и одному и тому же своду правил и инструкций. Сеть останется единым организмом, если несколько групп администраторов будут работать согласованно друг с другом (раздел 7.2.2).

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

7.2.1. Передовые технологии или надежность Как правило, самое важное качество сети, которого все добиваются, – это на дежность. Более старые решения, которые прошли множество проверок как в аппаратном аспекте, так и в отношении прошивки, обычно отличаются повы шенной надежностью. Все ошибки в них уже исправлены. С другой стороны, новые возможности и увеличенная скорость подключения, как правило, доступ ны только в новых продуктах, которые, возможно, еще не прошли полевые испытания. И именно вы должны добиться нужного баланса.

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

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

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

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

Технологии • Ведущие технологии. Самые современные технологии. Вы возглавля ете движение в эру новых технологий.

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

• Ударные технологии. Удар – именно то, что получают юзеры, если они постоянно находятся на передовой.

7.2.2. Несколько административных единиц По различным политическим, практическим или связанным с безопасностью причинам создать одну административную единицу может быть невозможно.

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

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

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

7.3. Заключение В этой главе мы рассмотрели различные аспекты разработки и создания сети.

Так как сетевые технологии стремительно меняются, некоторые из этих аспек тов со временем также претерпят значительные изменения. Но остальные ас пекты создания сети являются неизменными (константами). В этой главе мы 244 Глава 7. Сети описали, каким образом технологии повлияли на сети, а также рассказали о факторах, которые всегда необходимо учитывать.

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

7.3.1. Константы создания сети • Необходимость четкой архитектуры.

• Надежность.

• Грамотное документирование и ярлыки.

• Соответствие IDF и MDF высочайшим стандартам проводки.

• Надежные системы энергопитания и охлаждения для IDF и MDF.

• Последовательное размещение IDF на всех этажах и во всех зданиях.

• Точки разграничения.

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

• Стандартные открытые протоколы (IETF и IEEE).

• Простая маршрутизация узлов.

• Выделенное сетевое оборудование для передачи пакетов.

• Минимальное количество поставщиков.

• По возможности отказ от использования ударных технологий.

7.3.2. Изменчивые аспекты создания сети • Необходимый тип проводки в помещении и между помещениями.

• Топологии физических и логических сетей.

• Сетевые устройства и протоколы.

• Возможности подключения к глобальной вычислительной сети.

• Структура подключения к Интернету.

• Методы избыточности.

• Технологии мониторинга.

Задания 1. Нарисуйте карту физической сети вашей организации.

2. Нарисуйте карту логической сети вашей организации.

3. Каким образом осуществляется маршрутизация пакетов между узлами се ти? Где в сети существует избыточность? Если избыточности нет, каким образом ее можно внедрить?

4. Представьте, что ваша компания только собирается переезжать в помеще ние, которое вы сейчас занимаете. У вас есть возможность изменить разме щение IDF и MDF. Что бы вы сделали? Насколько такое размещение отли чалось бы от существующего в настоящий момент?

Заключение 5. Где располагаются ваши точки разграничения? Каким образом они доку ментированы и маркированы?

6. Какие протоколы используются в вашей сети и какие соответствующие RFC-номера они имеют? Есть ли среди них проприетарные протоколы? Ес ли да, каким образом можно избежать использования этих протоколов?

7. Оборудование каких поставщиков вы используете в сети? Каким образом можно снизить количество этих поставщиков? Каковы преимущества и недостатки такого шага?

8. Какова политика (неофициальная или какая-либо другая) вашей органи зации относительно использования оборудования ведущих технологий?

Каким образом вы ограничиваете отрицательное влияние этого оборудова ния на надежность?

9. Если в вашей организации существует несколько административных еди ниц, каким образом можно применить подход, описанный в разделе 7.2.2?

10. Мониторинг чего ведется в вашей сети? Мониторинг чего вы хотели бы проводить и что нужно для этого сделать?

Глава Пространства имен В этой главе мы опишем принципы организации и управления пространствами имен. Пространство имен – это набор уникальных ключей и связанных с ними атрибутов. Примерами пространства имен могут служить используемые реги страционные записи, доступные принтеры, имена хостов, Ethernet-адреса, списки названий сервисов/номеров портов и карты расположения домашнего каталога. В пространстве имен для каждого элемента предусмотрены атрибуты.

Для регистрационных записей существуют идентификаторы UID (UNIX) или SID (Windows), домашние каталоги, владельцы и т. д. Атрибуты имени хоста, как правило, включают в себя IP-адреса, серийные номера оборудования, ин формацию о пользователе (владельце), MAC-адрес Ethernet и т. д.

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

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

Пространства имен бывают самых разных видов. Некоторые из них являются плоскими, то есть не имеют копий. Например, в Windows каталог WINS являет ся плоским пространством имен. В UNIX набор идентификаторов UID – плоское пространство имен. Другие пространства имен являются иерархическими, напри мер дерево каталогов. В каждом отдельном каталоге не могут существовать два файла с одинаковым именем. Но два файла с одним и тем же именем example.txt могут находиться в разных подкаталогах.

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

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

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

Эта глава должна помочь вам увидеть лес за деревьями.

8.1. Основы Основы пространств имен очень просты:

• Пространствам имен необходимы политики по именам, долговечности, ло кальности и защищенности.

• Пространствам имен необходимы процедуры: добавление, изменение и уда ление.

• Пространствам имен необходимо централизованное управление.

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

8.1.1.1. Назначение имен Политика по назначению имен для пространств имен должна отвечать на сле дующие вопросы. Какие имена разрешены в пространстве имен? Какие имена запрещены в пространстве имен? Каким образом выбираются имена? Каким образом решается проблема перекрытия имен? В каких случаях допускается переименование?

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

Некоторые правила диктуются технологией. Например, в UNIX-системах ло гины могут включать в себя только алфавитно-цифровые символы при ограни ченном их количестве. Кроме того, правила могут диктоваться корпоративным стилем, например ограничениями на «оскорбительные» логины. Внешние стандарты также влияют на правила. До RFC 1123 (Braden 1989, Section 2.1) 248 Глава 8. Пространства имен имена DNS не могли начинаться с цифры, из-за чего компании 3Com было сложно зарегистрировать свой домен.

При выборе имен можно использовать несколько методов:

1. Шаблонный. Все имена составляются по строгому шаблону. Например, все настольные рабочие станции получают имена pc- и четырехзначное число.

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

2. Тематический. Все имена соответствуют определенной теме. Например, все серверы можно назвать в честь планет (если названий настоящих пла нет слишком мало, можно использовать планеты из научной фантас тики).

3. Функциональный. Имена соответствуют функциям. Учетные записи могут соответствовать должностям и ролям (admin, secretary, guest);

имена узлов могут отражать обязанности машины (dns1, cpuserver22, web01) или группы доступа (webmaster, marketing).

4. Описательный. Описательные имена обычно отражают фактическую ин формацию, а не правила. Подходящими примерами здесь являются метки разделов диска, описывающие пользователей или данные, для которых предназначен данный раздел диска (S:\Otdel\Finance, test data). Имена прин теров могут сообщать, какой используется принтер с драйвером (laserjet, photo, 11Ч14) или где этот принтер установлен (testlab, inkjet, CEO-desktop).

Крупные организации часто используют географические названия (назва ния городов или коды аэропортов) для групп доступа и почтовых списков (sjc-all, chicago-execs, reston-eng).

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

Эти четыре метода малосовместимы. После того как вы выберете одну опреде ленную схему, изменить ее будет достаточно сложно. Многие организации из бегают использования только одного метода, объединяя несколько методик. Но, как правило, один метод берется за основу, а другой является вторичным. На иболее распространено использование функционального метода в сочетании с описательным, если офисы компании находятся в разных географических регионах (например, nyc-marketing или sjc-web-03). Особенно это касается сетево го оборудования, имена которого, как правило, делаются максимально инфор мативными для решения проблем. В таких именах используются аббревиатуры провайдера сети, колокейшн-центра или даже координаты стойки.

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

Шансы перекрытия имен повышаются, если обе организации использу ют один и тот же метод назначения имен. Чей сервер с именем gandalf придется переименовать? Какой из Сьюзен придется изменить свой логин на sue или что-то другое? Куда будут доставляться письма, если отделы продаж обеих компаний используют один псевдоним? По нашему опыту, решением могут стать следующие варианты.

• Серверы. Все серверы с одинаковыми именами переименовываются с добавлением псевдонима компании в директории или DNS. На пример, если существуют два сервера с именем gandalf, их можно переименовать в gandalf-CompanyaA и gandalf-CompanyaB до тех пор, пока один из этих серверов нельзя будет списать или переименовать дру гим образом.

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

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

Затем почтовые шлюзы настраиваются таким образом, чтобы почта переадресовывалась пользователям на основе домена, которому она была адресована. Письма для susan.jones@companyaA будут переад ресованы на адрес susan.a.jones@novaya.companya. А письма для susan.jones@companyaB будут переадресованы на адрес susan.

b.jones@novaya.companya. Большинство компаний предпочитают переадресацию почты ее возврату, но ту же стратегию можно ис пользовать для возврата почты с определенным сообщением, на пример «Адрес Susan.Jones@companyaA сменился на адрес Susan.

A.Jones@companyaA. Пожалуйста, обновите эту информацию в сво ей адресной книге». При внедрении политики маршрутизации поч ты, например, описанной выше, важно определить временной пери од (если он будет), по истечении которого особая маршрутизация бу дет отключена.

Функциональные имена могут упростить конфигурацию программного обеспе чения. Службе поддержки будет проще обслуживать программное обеспечение, если почтовый сервер носит имя pochta, а календарный сервер – calendar. Однако, если такие серверы придется переносить на другие узлы, могут возникнуть сложности. Лучше всего ввести функциональные псевдонимы, указывающие на такие узлы. Такие псевдонимы, как DNS CNAME, отлично подходят для неинтер активных служебных машин, таких как почтовый сервер, веб-сервер, DNS 250 Глава 8. Пространства имен и т. д. Псевдонимы не так эффективны для интерактивных вычислительных серверов, поскольку пользователи заметят имя узла и начнут его использовать.

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

Последовательные имена Шаблонные имена создают ложное впечатление завершенности. Одна сотрудница в панике подала заявку о неисправности, когда заметила, что узлы software-build-1, -4, -5 и -7 не пингуются. Естественно, дело было в том, что существовали только узлы -2, -3, -6 и -8. Остальные были убра ны и переведены в другие отделы. Такая ситуация может представлять проблему только в том случае, если используется четкая последователь ность.

Тематические имена могут быть очень милыми. Иногда даже слишком милыми.

В одном подразделении Bell Labs, где работал Том, для принтеров использовали имена, связанные с видами кофе: latte, decaf, grande, froth. И хотя этот подход был очень мил, намного меньше нервов уходило на поиск нужного принтера в тех подразделениях, в которых принтерам давали имена по номеру кабинетов, в которых эти принтеры установлены, плюс добавляли букву c (сокращение от англ. сolor – цветной), если принтер был цветным. Некоторые подходы к назна чению имен намного логичнее других. Имена в честь кофе раздражали новых сотрудников, а шаблонные имена устраняли необходимость в дополнительных списках, указывающих, где можно найти тот или иной принтер.

Метод, используемый для назначения имен, отражает корпоративную культу ру. Если вы хотите установить свободную и непринужденную рабочую атмос феру, latte – отличное имя для принтера. Если вы сторонник культуры, в кото рой работа скучна, неинтересна и ужасно занудна, пусть именем узлов станет pc и четырехзначный номер. Разумеется, в этом случае стоит начинать нумера цию с pc0011, чтобы пользователи не завидовали везунчикам, которым достались однозначные номера. Кроме того, не забудьте пропустить числа, заканчиваю щиеся на 00, простые числа, числа с непристойным значением и любые другие «интересные» числа, открытые математиком Рамануджаном.

Имена обладают и аспектом безопасности. Внимание мошенников скорее при влечет имя sourcecodedb, чем имя server05. Кроме того, мошенники давно уже поняли, что системные администраторы, как правило, нарушают правила на значения имен в своих собственных системах. Цель мошенников – как можно дольше оставаться незамеченными. Поэтому они избегают узлов, за которыми может быть установлено пристальное наблюдение, например настольных машин системных администраторов. Если они обнаружат сеть, в которой все имена узлов составлены по четкому шаблону, за исключением нескольких машин, названных в честь персонажей «Звездного пути», мошенники решат, что по следние и есть машины системных администраторов. Мошенники будут ста раться избегать этих узлов, чтобы снизить свои шансы быть обнаруженными.

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

RFC 1178 (Libes 1990) содержит отличный совет по поводу выбора имен для узлов сети. Однако нам хотелось бы отметить, что в случае настольных рабочих станций жизнь системного администратора будет намного проще, если имя узлов будет отражать имя пользователя. Если вы получаете письмо от ajay с текстом «У меня проблемы с машиной», будет намного удобнее, если вы знаете, что имя этой машины – тоже ajay. Разумеется, некоторые сервисы каталогов не позволяют устанавливать имена узлов, аналогичные именам в каталоге пользователя.

В таком случае достаточно назначить узлам такие имена, как ajaypc.

Сложные для ввода имена Архитектура одной площадки была построена таким способом, что каж дый кластер включал в себя файловый сервер и несколько вычислитель ных серверов. Пользователи должны были работать на вычислительных серверах и не использовать протокол telnet для обращения к файловому серверу. Чтобы отучить пользователей заходить на файловые серверы, таким серверам были присвоены длинные, сложные имена, а вычисли тельным серверам – простые. В одном таком кластере машины были названы в честь известных математиков. Файловый сервер получил имя ramanujan, а вычислительный сервер – boole. Ведь гораздо проще ввести boole!

8.1.1.2. Контроль доступа Политика по контролю доступа к пространству имен должна отвечать на следу ющие вопросы.

• Какие защита и уровень безопасности требуются данному пространству имен?

• От чего мы пытаемся защитить имена и зачем?

• Нужно ли защищать имена в пространстве или только их атрибуты?

• Кто имеет право добавлять, изменять или удалять целые записи?

• Может ли владелец записи изменять определенные поля своей записи?

От кого необходимо защитить содержимое пространства имен? Это зависит от пространства имен. Доступ к просмотру пространства имен стоит запретить всем, если речь идет о списке паролей. Доступ к некоторым пространствам имен ограничивается узким кругом лиц. Это могут быть пользователи в кластере, все сотрудники, все, за исключением конкурентов, или вообще кто угодно. Кому какая разница, что у Тома идентификатор пользователя 27830?

Ответ зависит от каждого конкретного пространства имен, а также может зави сеть от контекста. Например, отдельные логины в UNIX-системе можно спо койно указывать в исходящих письмах, на визитных карточках, в рекламе и т. д. Однако полный список таких идентификаторов не стоит нигде публико вать, так как его могут использовать спамеры для рассылки нежелательных 252 Глава 8. Пространства имен писем. Разумеется, нельзя раскрывать и пароли, связанные с логинами. Таким образом, в UNIX-системах файл /etc/shadow, в котором хранится пароль, должен быть лучше защищен, чем файл /etc/passwd, где хранятся UID (идентификатор пользователя), полное имя пользователя, домашняя директория и предпочита емая командная оболочка. С другой стороны, хотя мы и не возражаем против внутренней публикации UID, но не советуем раскрывать их всему свету.

Печать файла /etc/passwd Один системный администратор настраивал принтер и в качестве тесто вых страниц распечатывал файл /etc/passwd. В той компании не сущест вовало инструкций по контролю доступа к пространствам имен, поэтому системный администратор не понимал, что раскрытие содержимого фай ла /etc/passwd – не самая удачная мысль (он не знал, что мошенники иногда просматривают корпоративный мусор как раз на предмет подоб ных документов1). Ему порекомендовали распечатывать файл /etc/motd или создать собственный файл с тестовой страницей. Более опытный системный администратор имел бы лучшее представление о защите про странств имен и не стал бы делать ничего подобного.

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

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

Пространства имен, которые хранятся в формате нешифрованного текста, мож но включить в систему контроля изменений, например в SubVersion (UNIX) или SourceSafe (Windows) для сетевого управления. Политики по резервному копи рованию должны особое внимание уделять пространствам имен. Резервное копирование – главный страховой полис.

Каким образом пространство имен защищено от изменений – это другой вопрос.

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

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

8.1.1.3. Долговечность пространства имен Политика по долговечности пространства имен должна отвечать на следующий вопрос: когда необходимо удалять записи в данном пространстве имен? Срок действия некоторых записей в пространстве имен должен заканчиваться в ус тановленный день или через определенный период бездействия. Можно указать, что учетные записи должны обслуживаться одним из сотрудников, который будет обновлять запрос раз в год. При отсутствии обновления учетные записи должны удаляться. IP-адресов может быть недостаточно, и в слабо контроли руемой среде можно завершить срок действия IP-адреса, который был передан пользователю, если система сетевого мониторинга показывает, что этот IP-адрес не использовался в течение определенного количества месяцев.

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

Если адрес электронной почты печатается на визитках, очень сложно будет отозвать все карточки в случае необходимости смены этого адреса. Как только репозиторий документов выложен на файловый сервер fred, даже не думайте о том, чтобы переместить его на barney.

Грамотные технологии позволяют вам маскировать имена, которые не должны быть взаимосвязаны. Средство автоматического монтирования UNIX можно использовать для того, чтобы пользователи обращались к репозиторию как к /home/docs при скрытом имени файлового сервера. Расположение документов не должно быть привязано к имени сервера. Тот факт, что они взаимосвязаны, не должен касаться ваших пользователей. Отличным решением здесь являются псевдонимы, хотя некоторые технологии, такие как NFS, требуют перезагрузки клиентов, чтобы изменения вступили в силу. Никогда не называйте веб-сервер www. Дайте ему общее имя, а www сделайте псевдонимом. Пользователям сообщи те только псевдоним www, и тогда вы сможете спокойно переносить функциональ ность сервера на другой узел. Если вы постоянно используете псевдонимы и другие технологии, должным образом скрывающие имена, вы сможете без проблем переносить функциональность с одного узла на другой.

Машина с именем calendar В течение многих лет календарный сервер, который использовал Том, находился на узле с именем calendar. В момент назначения такое имя казалось очень удачным, так как этот узел был приобретен специально для того, чтобы использоваться в качестве календарного сервера. Но впоследствии он также стал выполнять роль главного сервера печати, 254 Глава 8. Пространства имен и пользователи приходили в замешательство каждый раз, когда задания печати передавались на узел с именем calendar. Имя узла нельзя было изменить, так как к нему была привязана лицензия программного обес печения. Этой проблемы можно было избежать, если бы узлу изначально присвоили любое другое имя, а calendar использовалось бы в качестве псевдонима машины. В идеальном мире Том мог бы присвоить узлу псев доним printer, чтобы клиенты были довольны или хотя бы не приходили каждый раз в замешательство.

8.1.1.4. Вопросы сферы действия Политика по сфере действия пространства имен должна отвечать на следующий вопрос: где будет применяться данное пространство имен? Степень глобальности или локальности того или иного пространства имен определяется двумя факто рами: диаметром (географически, то есть насколько широко оно используется) и плотностью (сколько сервисов его используют).

Диаметр – это число систем, использующих конкретную базу данных пространст ва имен: один узел, кластер, отдел, вся организация и т. д. И хотя вся ваша организация может пользоваться Microsoft ActiveDirectory, конкретная база данных пространства имен – например, имена пользователей и пароли, – может использоваться только машинами вашего подразделения. У иных подразделений есть другие списки пользователей и паролей для своих машин.

RADIUS (Rigney et al. 1997), протокол аутентификации для модемных пулов, VPN-серверов и других сетевых устройств, можно применять таким образом, чтобы устройства всей глобальной системы имели доступ к одной базе данных имен пользователей и паролей. Люди могут входить в систему под одним и тем же именем пользователя и паролем вне зависимости от того, каким модемным пулом они пользуются, путешествуя по всему миру.

Для сайтов, использующих сетевую информационную службу NIS, которые часто являются UNIX-системами, характерно применение пространства имен диаметром в один кластер UNIX-узлов. Каждый кластер имеет свои базы данных пространства имен.

Плотность пространства имен определяется количеством служб, которые его используют. Например, компания может создать уникальный идентификатор для каждого сотрудника, такой как tal или chogan, и использовать его для адре са электронной почты человека, логина, идентификатора входа во внутрисете вые службы, имени в модемных пулах, службах VPN и т. д. Даже несмотря на то что эти системы используют различные базы данных и протоколы – ActiveDirectory, NIS, RADIUS и т. д., – идентификатор применяется везде.

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

Диаметр пространства имен – очень важный фактор во многих случаях. Если каждый отдел имеет свое пространство имен логинов, какими должны быть учетные записи одного человека в базах данных двух пространств имен? На пример, что если в одном отделе tal – это Том Лимончелли (Tom Limoncelli), а в другом – Терри Левайн (Terry Levine)? Все может быть хорошо, пока Тому не понадобится войти в систему в отделе Терри. Должен ли Том быть tal2 толь Основы ко в отделе Терри или нужно потребовать, чтобы он изменил имя своей учетной записи везде? Это может создать очень много проблем, особенно если учетная запись в сети Терри нужна Тому лишь на небольшой срок.

Пример: «метки» в Lucent Может быть полезно иметь единое, глобальное пространство имен и обес печивать согласование с ним других пространств имен. Компания Lucent дает каждому сотруднику «метку», которая является уникальным иден тификатором. Сотрудники могут выбирать метки сами, но по умолчанию метка состоит из первых букв имени и фамилии человека. Данное про странство является глобальным пространством уникальных имен, хотя их уникальность довольно сложно обеспечить, учитывая, что в 2000 году в Lucent было более 160 тыс. сотрудников. Доступ к базе данных меток можно получить как к полю корпоративного онлайн-каталога. Каждый отдел должен создавать имена учетных записей, совпадающие с метками сотрудников. Все службы, поддерживаемые группой руководителя ин формационного подразделения, – электронная почта, кадры, удаленный доступ и т. д. – используют метки только для моделирования правильно го поведения. В результате выигрывают обе стороны. Локальные службы могут применять идентификаторы, соответствующие метке сотрудника, но при желании могут и отказаться от них, но тогда им приходится идти на риск, что нынешние и будущие коллизии могут вызвать дезорганиза цию. Преимущества применения меток Lucent над предоставлением пользователям возможности выбирать уникальные идентификаторы очевидны, и поэтому принуждения практически не требуется. При по глощении компаний присоединяемая компания должна разобраться с возможными коллизиями в пространстве имен.

Иногда глобальное плоское пространство имен нежелательно. В некоторых случаях используемая технология обеспечивает иерархическое пространство имен. Например, именам узлов необязательно быть уникальными в масштабе всей корпорации, потому что DNS обеспечивает зоны и подзоны. При наличии зон DNS в подразделениях каждое подразделение может иметь машину www. – в идеале псевдоним реального сервера с более уникальным именем. Подразде ление может даже называть свои настольные ПК как pc и номер, и сайтам не придется координироваться друг с другом, чтобы обеспечить использование непересекающихся номеров.

Пример: широкие и плотные пространства имен в электронной коммерции Сайты электронной коммерции могут иметь очень широкое и плотное пространство имен пользователя. Пользователь создает и применяет одно имя и пароль для всех служб на сайте, вне зависимости от того, располагаются ли они на одной машине или на сотнях. Подобное харак терно для Yahoo. Когда пользователь создает профиль, он применяется 256 Глава 8. Пространства имен во всех предоставляемых службах. Пользователю может понадобиться активировать дополнительные службы, но они все привязаны к одному имени и паролю, которые человеку нужно помнить.

8.1.1.5. Целостность Политика целостности пространства имен должна отвечать на следующий во прос: целостность каких атрибутов должна сохраняться при использовании одного имени в нескольких пространствах имен?

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

Пример: простой способ установки стандартов назначения имен В компании Bell Labs Research много UNIX-систем, или кластеров, но удивительно мало конфликтующих UID. Этот факт был обнаружен, к нашему глубокому удивлению, при слиянии некоторых из этих систем.

Как же это случилось?

Много лет назад кто-то пригласил всех системных администраторов из всех вычислительных центров на бизнес-ланч. На этом бизнес-ланче системные администраторы разделили пространство UID, отдав большие диапазоны каждому исследовательскому центру. Все согласились при держиваться рамок выделенных пространств, за исключением создания учетных записей для людей из других вычислительных центров – в этом случае переносились UID из их центра. Не было создано политики, не был назначен ответственный руководитель по распределению, а также не была реализована система санкций. Все согласились соблюдать реше ния, поскольку знали, что это разумно. Через некоторое время после встречи кто-то отправил электронное письмо с описанием диапазонов.

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

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

Том обнаружил, что одной из таких машин был DNS-сервер. Учетные записи были только у тех, кому нужно было вносить обновления в DNS, и их UID размещались в диапазоне от 1000 и далее. Предыдущий систем ный администратор оправдывал это решение тем, что для DNS-сервера было необходимо обеспечить такую безопасность, что об NFS даже не приходилось говорить. Поэтому UID не должны быть такими же, как во всех остальных системах, иначе определение обычного UID одной учетной записи занимало бы целых 10 с. За три года эксплуатации машины такое решение позволило сэкономить, пожалуй, одну-две минуты в год. Но в итоге, когда резервные копии данных с этой машины восстанавливались на других узлах, UID оказывались другими. Для предотвращения буду щих проблем Том установил такую политику, что все новые учетные записи должны создаваться с использованием UID их домашних систем, а старые UID переназначались во время модернизации, когда разрешал ся простой.

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

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

Эта политика предотвращает следующий злонамеренный прием: в некоторых компаниях есть автоматизированная процедура перенаправления почты с имен ных адресов. Например, вы можете задать перенаправление почты с foosupport@ companyname.com вам – человеку, который поддерживает продукт foo. Если ваши служебные обязанности изменятся, почта с этого адреса может быть пере направлена тому, кто вас сменит. Однако, если Джон До (John Doe) (jdoe@ companyname.com) уволится из компании, вы можете воспользоваться этим, чтобы перенаправить себе почту jdoe и получать его письма, пока все его коррес понденты не узнают новый адрес. Будет особенно плохо, если компанию покинет генеральный директор. Устанавливая требование недействительности удаленных адресов электронной почты в течение 6 месяцев, вы будете иметь большую уве ренность в том, что повторное применение этого адреса безопасно.

Политика повторного использования может быть реализована программно.

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

258 Глава 8. Пространства имен 8.1.1.7. Выводы Политики назначения имен, контроля доступа, долговечности, охвата, целост ности и повторного использования должны быть записаны, одобрены управляю щим и техническим персоналом и доступны для ознакомления пользователям и системным администраторам, четко устанавливая таким образом правила ва ших пространств имен. Так можно избежать многих проблем. Небольшие сайты могут себе позволить работать без такой документации потому, что в данном случае требуется совсем немного системных администраторов, которые работают вместе, и такая политика является частью их культуры. Однако такой нефор мальный подход становится препятствием расширяемости. Сайты со временем становятся крупнее и вдруг оказываются под управлением большего количества системных администраторов, не посвященных в «стандартные» методы работы.

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

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

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

8.1.3. Централизация управления пространством имен Управление пространством имен должно быть максимально централизованным, насколько это возможно для любой конкретной среды. С централизацией при ходит целостность. Иначе пространства имен становятся разрозненными на различных серверах или даже в различных директориях на одном сервере.

Лучше иметь один узел, поддерживающий ваши пространства имен, и распро странять их по другим узлам.

Пример: очистка пространства имен На одном сайте Том обнаружил, что некоторые пространства имен име ли контрольные копии на конкретном узле и распространялись по всем узлам UNIX-командой make. На паре других узлов хранились контроль ные копии других пространств имен. Для этих пространств нужно было Основы отредактировать файл и затем запустить скрипт, чтобы распространить данные по другим узлам. Фактически это был не один скрипт, а набор скриптов с именами типа update_printcap, aliases_push и push_stuff. Имена этих скриптов были неупорядоченными, потому что система представ ляла собой совокупность нескольких более мелких систем. Директории, в которых хранились файлы и скрипты, часто были различными для разных узлов.

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

Ни один из файлов не был записан в системе управления редакциями (RCS – Revision Control System) или системе контроля исходного кода (SCCS – Source Code Control System), поэтому для любого управления изменениями системные администраторы были вынуждены полагать ся на резервные копии на магнитных лентах. Системные администра торы не могли отменить какое-либо изменение без значительных уси лий. Том тоже мог ошибиться, поэтому его и беспокоило такое положе ние вещей.

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


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

Со стабилизацией новой системы ее стало возможно оптимизировать.

Некоторые старые скрипты были неустойчивыми или медленными.

С объединением системы основное внимание было уделено замене отдель ных скриптов на более эффективные.

Также это объединение упростило введение новых автоматизированных процессов, например для создания новых учетных записей. Вместо того чтобы требовать от системных администраторов запоминать имена скрип тов для создания учетной записи, например make newuser, стали создавать памятки. Сами скрипты были интегрированы в Makefile. Поэтому, вместо того чтобы запоминать, какой скрипт создавал учетную запись, человек просто вводил команду make account – и скрипт задавал соответствующие вопросы и завершал задачу.

260 Глава 8. Пространства имен GNU-приложение cfengine Марка Барждеса (Burgess 1995) – отличное средство под UNIX для поддержки контрольных копий пространств имен и файлов и распространения их по узлам. Преимуществами этого средства являются автоматическое поддержание любой конфигурации узла UNIX и возможность программирования других конфигураций для определенных узлов. Microsoft ActiveDirectory и OpenDirectory в Mac OS X были созданы по другому принци пу – клиенты должны отправлять запросы на LDAP-серверы, которые центра лизованно хранят информацию о пространствах имен.

8.2. Тонкости Теперь мы можем выйти на новый уровень за счет дальнейшей централизации и автоматизации. Применение пространств имен может стать общим методом ведения дел.

8.2.1. Одна большая база данных Централизация – хорошая практика, а централизация всех пространств имен в базе данных SQL даже лучше. Вы можете разработать клиент (веб-приложение или приложение с оконным интерфейсом), который позволит операторам вносить большинство изменений. Затем программы могут передавать данные другим системам, например ActiveDirectory, LDAP, NIS, конфигурациям принтера и т. д. Джон Финке (John Finke) из политехнического института Ренсселера напи сал по этой теме ряд статей (Finke 1994a, 1994b, 1995, 1996, 1997). До недавнего времени многие организации не могли воспользоваться этим решением. Но реали зации баз данных SQL с открытым исходным кодом, такие как Postgres и My SQL, существенно снизили финансовые затраты на централизацию баз данных.

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

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

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

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

8.2.3. Обновление, управляемое пользователем Автоматизация также может пойти в другом направлении: к большей самосто ятельности пользователей. В каждой среде есть много возможностей для авто матизации служб. Периодически просматривайте свои журналы запросов и проведенных работ, обсудите с пользователями, что бы они хотели автомати зировать. В разделе 3.1.3.3 описана система DHCP, которая автоматизирует выдачу IP-адресов.

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

8.2.4. Эффективное использование пространств имен Всеобъемлющие пространства имен могут быть полезны не только в вашей компьютерной инфраструктуре, но и в других инфраструктурах. Существует тенденция по снижению нагрузки по администрированию некомпьютерной инфраструктуры за счет ее привязки к пространствам имен компьютерной ин фраструктуры. Например, офисные АТС, а также системы голосовой почты, доступа по смарт-картам и обслуживания кредитных карт в кафе все чаще об ращаются к LDAP. Представьте дополнение вашей корпоративной базы данных LDAP, когда при найме новых сотрудников создаются их учетные записи элек тронной почты, копируются шаблоны внешних домашних страниц, настраива ются телефон, голосовой почтовый ящик и доступ по смарт-карте для обеспече ния прохода в нужные части здания.

262 Глава 8. Пространства имен 8.3. Заключение В этой главе мы установили ряд правил для пространств имен. Во-первых, мы должны осознать, какую роль выполняют пространства имен в системе. Далее, очевидно, что всем пространствам имен присущи определенные качества. Про странствам имен требуются правила для присвоения имен, контроля доступа, долговечности, сферы действия, целостности и повторного использования.

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

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

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

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

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

Задания 1. Какие пространства имен есть в вашей системе? Как они поддерживаются?

2. Одним из признаков хорошо развитой системы является наличие базовых признаков в пространствах имен системы, которые были рассмотрены в раз деле 8.1. Оцените свою систему.

3. Какая автоматизация применяется для поддержки пространств имен? Ка кую автоматизацию нужно обеспечить?

4. Какие задачи по поддержке системы можно переложить на пользователей благодаря автоматизации?

5. Предположим, вы перешли в новую организацию и ваш логин уже исполь зуется. Что вы будете делать?

6. Кем был Рамануджан и какие числа он посчитал интересными?

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

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


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

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

Истина заключается в том, что за счет одновременного хранения и распростране ния знаний документация позволяет организации развивать своих людей.

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

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

264 Глава 9. Документация 9.1.1. Что документировать Наиболее важные для документирования процессы чаще всего являются либо (1) сложными и неприятными, либо (2) теми, которые вы постоянно объясня ете кому-то. Иногда предмет документирования принадлежит обеим категори ям, например доступ к корпоративной сети в поездках. Мы используем харак теристику «сложный и неприятный» по отношению как к самому процессу, так и к последствиям в случае ошибки. Хорошим примером является процесс подготовки рабочего места для нового сотрудника: настройка компьютера, создание нужных учетных записей, в том числе необходимых в конкретном подразделении, уведомление нужных людей и т. д.

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

можете быть вы сами.

Документация неприятных процессов Том считает, что он плохо выполняет работу, которая ему не нравится.

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

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

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

9.1.2. Простой шаблон для начала Самый сложный этап создания документа – это начало. Вот простой принцип:

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

1. Название: простое название, понятное другим.

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

3. Что: предложение, описывающее содержание документа или цель, кото рой человек должен достичь, следуя указаниям. Достаточно одного-двух предложений.

4. Как: шаги, предпринимаемые для выполнения задачи. Для каждого шага, который может быть непонятным или запутанным, вы можете добавить почему, например «Перемотать ленту (Почему? Потому что мы выявили, что в этом случае при полном резервном копировании ошибки записи слу чаются реже, даже с новыми лентами»).

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

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

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

После успешного использования этой документации несколькими сотрудника ми создайте на ее основе более емкое «краткое руководство», обобщающее шаги.

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

Пример: два набора документации Клифф Миллер (Cliff Miller) в компании Bell Labs создал систему поддерж ки базы программного обеспечения для однородных UNIX-систем. Важ ным элементом структуры базы было пространство имен, применяемое для различных дистрибутивов, часть которых должна быть видима толь ко на определенных платформах или конкретных узлах. Процесс добав 266 Глава 9. Документация ления дистрибутивов в пространство имен был немного сложным. Не смотря на то что он был подробно документирован, инструкция содержа ла много пояснительных данных. Это было замечательно при первом добавлении дистрибутива, но потом начинало раздражать. Решением стало создание «краткого руководства», содержавшего только необходи мые для ввода команды с лаконичными пояснениями о том, что выпол няется, и гипертекстовыми ссылками на соответствующий раздел полной документации. Теперь как новые, так и опытные системные админист раторы могли легко выполнять процесс, пользуясь документацией в необходимом объеме.

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

9.1.3.1. Сохранение скриншотов Научитесь пользоваться средством для снятия скриншотов. Когда вы в следу ющий раз будете делать что-то, что хотите описать в документации, снимайте скриншоты при выполнении каждого шага. Если вы создадите документ из скриншотов, все, что вам останется, – это добавить одну-две строки текста к каждому изображению, описывающие, что выполняется на данном этапе.

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

9.1.3.2. Сохранение содержимого командной строки Если вы чаще работаете с командной строкой, чем с графическим интерфейсом, копируйте и вставляйте в документ содержимое окна терминала или консоли.

Некоторые программы терминалов или консолей содержат функцию сохранения в файл, UNIX-команда script сохраняет в файл весь сеанс.

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

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

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

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

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

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

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

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

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

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

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

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

268 Глава 9. Документация Вы можете дополнить свою систему заявок пометкой «база знаний» и полем для комментария, где будете отмечать процессы, которые нужно описать в докумен тации. Вам также понадобится метод обобщения таких отмеченных заявок – на пример, еженедельный отчет по электронной почте. Если вашу систему заявок нельзя легко дополнить таким образом, вы можете создать отдельную очередь запросов для внесения элементов в базу заданий и просто копировать заявки в эту очередь. Первоначальный запрос пользователя может быть закрыт, а копия останется в отдельной очереди, пока у кого-нибудь не появится возможность преобразовать ее в документ. Данные о заявках позволяют системным админис траторам быстро создавать формальную документацию. Применение этих ме тодов обычно приводит к написанию большего количества документации и, как результат, меньшему количеству жалоб о ее отсутствии – ситуация беспроиг рышная во всех отношениях.

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

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

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

Типичные контрольные листы включают:

• Задачи, которые необходимо выполнить при каждом найме на работу ново го сотрудника.

• Задачи, которые необходимо выполнить при каждом увольнении сотруд ника.

• Задачи по установке каждой операционной системы, которая используется в организации.

• Процессы по архивации и внешнему хранению данных в соответствии с тре бованиями юридического отдела.

• Процессы по обеспечению безопасности ОС перед вводом машины в эксплу атацию.

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

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

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

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

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

Вам может потребоваться добавить шаблон из раздела 9.1.2. Создайте несколь ко начальных поддиректорий с названиями нужных тем, например рабочие станции, принтеры или Linux.

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

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

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

270 Глава 9. Документация Создание общей директории Когда Том работал в Mentor Graphics, его группа имела директорию /home/adm/docs на центральном сервере, которая содержала неформаль ные инструкции по различным темам. Имена файлов были длинными и описательными: how-to-create-accounts.txt или reasons-why-printer p32-fails.txt. Поиск осуществлялся при помощи средств командной строки UNIX, таких как ls и grep. Возможности для поддержания поряд ка были очень примитивными: всем приходилось проверять дату послед него изменения файла с целью убедиться, что информация не устарела.

Сейчас вместо этого использовалась бы система контроля версии.

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



Pages:     | 1 |   ...   | 7 | 8 || 10 | 11 |   ...   | 33 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.