Модуль программной системы оптимизации работы сети на платформе операционной системы Linux

Размещено на http://www.allbest.ru/

Пояснительная записка к дипломному проекту

138 страниц, 66 рисунков, 23 таблицы и 33 источника.

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

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

Метод исследования - сбор статистических данных, анализ, написание программы.

Аппаратура - компьютер IBM PC совместимый под управлением операционной ситемы Linux Debian, сетевые карты Ethernet.

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

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

Прогнозные предложения о развитии объекта исследования - ряд мер по оптимизации работы сети на платформе операционной системы Linux.

Перечень ключевых слов - операционная система (ОС) Linux, протоколы управления, оптимизация работы сети.

СОДЕРАЖНИЕ

ВВЕДЕНИЕ

1. ПОСТАНОВКА ЗАДАЧИ

2. ОБЗОР ЛИТЕРАТУРНЫХ ИСТОЧНИКОВ

2.1 Основные задачи оптимизации сетей

2.2 Оптимизация работы сети на основе протоколов управления в ОС Linux

3. ОБОСНОВАНИЕ АКТУАЛЬНОСТИ ТЕМЫ И ЕЕ ПРАКТИЧЕСКОЙ ЗНАЧИМОсти

4. СИСТЕМОТЕХНИЧЕСКИЙ АНАЛИЗ

4.1 Принцип конечной цели

4.2 Принцип единства

4.3 Принцип связности

4.4 Принцип модульности

4.5 Принцип иерархии

4.6 Принцип функциональности

4.7 Принцип развития

4.8 Принцип сочетания централизации и децентрализации32

4.9 Принцип учета неопределенностей и случайностей32

5. ВАРИАНТНЫЙ АНАЛИЗ РЕАЛИЗАЦИИ ПРОГРАММНОГО МОДУЛЯ

5.1 Построение иерархии

5.2 Построение матрицы парных сравнений 2-го уровня

5.3 Оценка критериев (второй уровень иерархии)

5.3.1 Синтез локальных приоритетов для матрицы парных сравнений 2-го уровня

5.3.2 Исследование на согласованность матрицы парных сравнений 2-го уровня

5.3.3 Анализ результатов оценки критериев

5.4 Оценка альтернатив (третий уровень иерархии)

5.4.1 Критерий «Быстродействие»

5.4.2 Критерий «Стоимость»

5.4.3 Критерий «Используемые ресурсы»

5.4.4 Критерий «Возможность аутентификации сервера»

5.4.5 Критерий «Возможность шифрования паролей и данных»

5.4.6 Анализ результатов оценки альтернатив

5.5 Синтез глобальных приоритетов

5.6 Количественные оценки вкладов критериев в конечный результат

6. ОПИСАНИЕ ПРОГРАММНОГО МОДУЛЯ

6.1 Общие сведения

6.2 Функциональное назначение

6.3 Руководство пользователя

6.4 Описание логической структуры

7 ТЕСТИРОВАНИЕ ПРОГРАММНОГО ПРОДУКТА

7.1 Объект испытаний

7.2 Цель испытаний

7.3 Требования к программе

7.4 Средства и порядок испытаний

7.5 Методы испытаний

7.6 Анализ результатов тестирования

8. ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ СОЗДАНИЯ ПРОГРАММНОГО ПРОДУКТА

8.1 Исследование программного продукта

8.1.1 Назначение программного продукта

8.1.2 Основные свойства программного продукта

8.1.3 Основные потребительские свойства

8.1.4 Требования к функциональным характеристикам программного продукта

8.1.5 Требования к надежности программного продукта

8.1.6 Требования к условиям эксплуатации

8.1.7 Конкурентоспособность

8.1.8 Оценка рыночной направленности

8.2 Исследование рынка сбыта программного продукта (ПП)

8.2.1 Сегментация рынка

8.2.2 Анализ тенденции рынка

8.2.3 Предпочтительный потребитель

8.2.4 Возможные причины финансовых неудач

8.3 Итоги маркетинговых исследований

8.4 Определение затрат на проектирование продукта

8.4.1 Определение трудоемкости разработки ПП

8.4.2 Вычисление себестоимости часа машинного времени

8.4.3 Формирование цены предложения разработчика

8.4.4 Расчёт капитальных затрат

8.4.5 Расчет эксплуатационных расходов

8.4.6 Оценка эффективности проектируемого программного продукта

9. ОХРАНА ТРУДА

9.1 Анализ условий труда разработчика проектируемого продукта

9.1.1 Краткая характеристика помещения и выполняемых работ

9.1.2 Планировка и размещение оборудования и рабочих мест

9.1.3 Микроклимат рабочей зоны

9.1.4 Шум и вибрация

9.1.5 Освещение

9.1.6 Электро- и пожаробезопасность

9.1.7 Электромагнитное излучение

9.1.8 Эргономика и техническая эстетика

9.1.9 Напряженность труда. Режим труда и отдыха работников

9.2 Расчет системы естественного освещения

10. БЕЗОПАСНОСТЬ В ЧРЕЗВЫЧАЙНЫХ СИТУАЦИЯХ

10.1 Вводная часть

10.2 Расчётная часть

10.3 Мероприятия по защите сотрудников лаборатории

ЗАКЛЮЧЕНИЕ

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

ПРИЛОЖЕНИЕ А

ВВЕДЕНИЕ

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

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

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

Объединение компьютеров в сети позволило значительно повысить производительность труда. Компьютерные сети используются как для производственных (или офисных) нужд, так и для обучения, общения и т.д.

Практически все операционные системы, занимающие заметное место на рынке, стали сетевыми. Сетевые функции сегодня встраиваются в ядро ОС, являясь ее неотъемлемой частью. Операционные системы получили средства для работы со всеми основными технологиями локальных (Ethernet, Fast Ethernet, Gigabit Ethernet, Token Ring, FDDI, ATM) и глобальных (Х.25, frame relay, ISDN, ATM) сетей, а также средства для создания составных сетей (IP, IPX, AppleTalk, RIP, OSPF, NLSP).

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

1. Постановка задачи

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

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

- установка, конфигурирование и запуск в сети служб DHCP, DNS, FTP, Proxy и электронной почты;

- установка, конфигурирование и запуск службы, реализующей протокол маршрутизации;

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

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

а) реализация интерактивного взаимодействия с пользователем;

б) обработка данных, введенных пользователем, написание скриптов, через которые программа будет взаимодействовать с операционной системой и сетью;

г) анализ данных и выдача результатов пользователю.

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

- модуль протоколов управления;

- модуль протоколов высокого уровня;

- модуль маршрутизации.

Каждый модуль будет иметь графический интерфейс.

В рамках разработки модуля протоколов управления следует спроектировать и реализовать:

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

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

Программное обеспечение должно быть тестировано.

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

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



2. ОБЗОР ЛИТЕРАТУРНЫХ ИСТОЧНИКОВ ПО ТЕМЕ

2.1 Основные задачи оптимизации сетей

Для того чтобы оптимизировать сеть, то есть сделать ее работу более эффективной, необходимо решить следующие задачи [10]:

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

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

Все варьируемые параметры могут быть сгруппированы различным образом. Например, параметры отдельных конкретных протоколов (максимальный размер кадра протокола Ethernet или размер окна неподтвержденных пакетов протокола TCP) или параметры устройств (размер адресной таблицы или скорость фильтрации моста, пропускная способность внутренней шины маршрутизатора). Параметрами настройки могут быть и устройства, и протоколы в целом. Так, например, улучшить работу сети с медленными и зашумленными глобальными каналами связи можно, перейдя со стека протоколов IPX/SPX на протоколы TCP/IP. Также можно добиться значительных улучшений с помощью замены сетевых адаптеров неизвестного производителя на адаптеры BrandName.

3) Определить порог чувствительности для значений критерия эффективности. Так, производительность сети можно оценивать логическими значениями "Работает"/ "Не работает", и тогда оптимизация сводится к диагностике неисправностей и приведению сети в любое работоспособное состояние. Другим крайним случаем является тонкая настройка сети, при которой параметры работающей сети (например, размер кадра или величина окна неподтвержденных пакетов) могут варьироваться с целью повышения производительности (например, среднего значения времени реакции) хотя бы на несколько процентов. Как правило, под оптимизацией сети понимают некоторый промежуточный вариант, при котором требуется выбрать такие значения параметров сети, чтобы показатели ее эффективности существенно улучшились, например, пользователи получали ответы на свои запросы к серверу баз данных не за 10 секунд, а за 3 секунды, а передача файла на удаленный компьютер выполнялась не за 2 минуты, а за 30 секунд.

Таким образом, можно предложить три различных трактовки задачи оптимизации:

1) Приведение сети в любое работоспособное состояние. Обычно эта задача решается первой, и включает:

- поиск неисправных элементов сети - кабелей, разъемов, адаптеров, компьютеров;

- проверку совместимости оборудования и программного обеспечения;

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

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

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

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

2.2 Оптимизация работы сети на основе протоколов управления в ОС Linux

Эффективная профессиональная работа в Linux немыслима без использования командной строки. Пользователям, привыкшим работать в системах с графическим интерфейсом, работа с командной строкой может показаться неудобной: то, что можно сделать одним перетаскиванием мышью в командной строке потребует ввода с клавиатуры нескольких слов: команды с аргументами. Однако в Linux этот вид интерфейса всегда был основным, а поэтому и хорошо развитым. В командных оболочках, используемых в Linux, есть масса способов экономии усилий (нажатий на клавиши) при выполнении наиболее распространённых действий: автоматическое дополнение длинных названий команд или имён файлов, поиск и повторное выполнение команды, уже когда-то исполнявшейся раньше, подстановка списков имён файлов по некоторому шаблону и многое другое. Преимущества командной строки становятся особенно очевидны, когда требуется выполнять однотипные операции над множеством объектов. В системе с графическим интерфейсом потребуется столько перетаскиваний мышью, сколько есть объектов, в командной строке будет достаточно одной (пусть длинной и сложной) команды [5].

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

Командная оболочка (или интерпретатор команд) - это программа, задача которой состоит в том, чтобы передавать ваши команды операционной системе и прикладным программам, а их ответы -- вам. По своим задачам ему соответствует command.com в MS-DOS или cmd.exe в Windows, но функционально оболочки в Linux несравненно богаче. На языке командной оболочки можно писать небольшие программы для выполнения ряда последовательных операций с файлами и содержащимися в них данными - сценарии (скрипты).

В дистрибутиве Linux доступны следующие командные оболочки:

? bash - самая распространённая оболочка под Linux. Она умеет дополнять имена команд и файлов, ведёт историю команд и предоставляет возможность их редактирования;

? pdkdh - клон korn shell, хорошо известной в системах UNIX командной оболочки;

? sash - особенность этой оболочки состоит в том, что она не зависит ни от каких разделяемых библиотек и включает в себя упрощённые реализации некоторых важнейших утилит, таких как ls, dd и gzip. Поэтому sash особенно полезна при восстановлении после некоторых системных сбоев или при обновлении версии важнейших разделяемых библиотек;

? tcsh - улучшенная версия C shell;

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

Оболочкой по умолчанию является bash (Bourne Again Shell). Чтобы проверить, какая оболочка используется, небходимо набрать команду: echo $SHELL.

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

Ниже перечислены некоторые из эмуляторов терминала вошедших в дистрибутив Linux:

? xterm - стандартный эмулятор терминала для X Window System. Этот эмулятор совместим с терминалами DEC VT102/VT220 и Tektronix 4014 и предназначен для программ, не использующих графическую среду напрямую. Если операционная система поддерживает изменение окна терминала (например, сигнал SIGWINCH в системах, произошедших от 4.3bsd), xterm может использовать сообщать программам, запущенным в нем, что размер окна изменился;

? aterm - это цветной эмулятор терминала rxvt версии 2.4.8, дополненный полосами прокрутки в стиле NeXT от Альфредо Кодзима (Alfredo Kojima). Он предназначен для замены xterm в случае, если не нужна эмуляция терминала Tektronix 4014.

Оптимизация работы сети на платформе операционной системы Linux по протоколам управления выполняется на четырех этапах или уровнях [4]:

1) Управление пользователями.

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

Файл /ETC/PASSWD

Файл /еtс/раsswd содержит список пользователей, которые известны системе. В процессе регистрации пользователя система обращается к этому файлу в поисках идентификатора пользователя и его домашнего каталога. Каждая строка файла описывает одного пользователя и содержит семь полей, разделенных двоеточиями:

* регистрационное имя;

* шифрованный пароль или “заполнитель” пароля;

* идентификатор пользователя;

* идентификатор группы по умолчанию;

* поле GЕСОS (полное имя, номер офиса, рабочий и домашний телефоны);

* домашний каталог;

* регистрационная оболочка.

В наши дни совершенно недопустимо хранить зашифрованные пароли в текстовом виде. Современные быстрые компьютеры позволяют взламывать такие пароли за считанные минуты. Все версии UNIX позволяют спрятать их, поместив в отдельный файл, недоступный для чтения. Это называется механизмом скрытых паролей и (по вполне понятным причинам) применяется в большинстве дистрибутивов. Механизм скрытых паролей становится понятнее, когда его описывают в качестве расширения к традиционному файлу /еtс/раsswd.

Ниже рассматривается назначение отдельных полей файла /еtс/раsswd.

Регистрационное имя

Регистрационные имена (называемые также пользовательскими именами) должны быть уникальными и состоять не более чем из 32 символов. Они могут содержать любые символы, кроме двоеточия и символа новой строки. Если используется база данных, длина имени ограничена 8 символами независимо от операционной системы.

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

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

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

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

Например, схема выбора имен может быть такой: первый инициал и фамилия каждого сотрудника. Пользователь Брент Браунинг (Вгеnt Вгowning), таким образом, превратится в “bbrowning”, но девять символов это слишком много для некоторых систем. Лучше присвоить пользователю регистрационное имя “brentb”, а “bbrowning ” сделать элементом файла а1iases: bbrowning: brentb.

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

В крупных организациях в адресах электронной почты часто используются полные имена (например, John.Q.Рublic@mysite.соm), благодаря чему регистрационные имена скрываются от внешнего мира. Это прекрасная идея, но, чтобы облегчить работу администраторам, необходимо установить четкое и понятное соответствие между регистрационными именами и реальными именами пользователей.

Регистрационные имена должны быть уникальными в двух отношениях. Во-первых, необходимо, чтобы имя пользователя на всех компьютерах было одинаковым. Это удобно как самому пользователю, так и администратору. Во-вторых, регистрационное имя всегда должно относиться к одному и тому же лицу. Некоторые команды (например, ssh) можно настроить так, чтобы они аутентифицировали удаленных пользователей по регистрационным именам. Даже если адреса scott@boulder и scott@refuge относятся к разным пользователям, то в случае неправильной настройки учетных записей оба пользователя могут при определенных обстоятельствах получить доступ к файлам друг друга, не вводя пароль.

Зашифрованный пароль.

Прежде чем переходить к деталям, напомним: в большинстве систем зашифрованные пароли хранятся в файле /еtс/shadow, а не /еtс/раsswd.

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

Вручную редактируя файл /еtс,/раsswd для создания новой учетной записи, необходимо поставить звездочку (*) в поле зашифрованного пароля. Звездочка воспрепятствует несанкционированному использованию учетной записи до установки реального пароля. Нельзя оставлять это поле пустым, иначе безопасность системы подвергнется серьезному нарушению, поскольку для доступа к такой учетной записи пароль не требуется.

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

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

Зашифрованные пароли имеют постоянную длину (34 символа в случае МD5 и 13 символов в случае DES) независимо от длины исходного пароля. Пароли шифруются с добавлением случайной “примеси”, чтобы одному исходному паролю соответствовало много зашифрованных форм. Таким образом, факт выбора пользователями одинаковых паролей не может быть выявлен путем просмотра зашифрованных паролей. Пароли МD5 легко распознать, так как они всегда начинаются с последовательности “$1$”.

Идентификатор пользователя

Идентификатор пользователя (UID) - это 32-битное целое число. Но для обеспечения совместимости со старыми системами мы рекомендуем, чтобы значение самого старшего идентификатора по возможности не превышало 32767 (наибольшее 16-битное целое число со знаком).

По определению пользователь гооt имеет идентификатор 0. В большинстве систем есть также псевдопользователи bin, daemon и ряд других. Как правило, такие псевдоимена помещаются в начало файла /еtс/раsswd, и им назначаются маленькие идентификаторы. Чтобы зарезервировать побольше номеров для неперсонифицированных пользователей, рекомендуется присваивать реальным пользователям идентификаторы, начиная с номера 100 (или выше).

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

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

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

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

Идентификатор группы по умолчанию

Как и идентификатор пользователя, идентификатор группы (GID) является 32-битным целым числом. Идентификатор 0 зарезервирован для группы с именем гооt, идентификатор 1 - для группы bin, а идентификатор 2 для группы daemon.

Группы определяются в файле /еtс/group, а поле идентификатора группы в файле /еtс/раsswd задает стандартный (“эффективный”) идентификатор на момент регистрации пользователя в системе. Этот идентификатор не играет особой роли при определении прав доступа; он используется лишь при создании новых файлов и каталогов. Новые файлы обычно включаются в эффективную группу своего владельца, но если у каталога установлен бит SGID (2000) или файловая система смонтирована с опцией grpid, новые файлы включаются в группу своего каталога.

Поле GECOS

Поле GECOS в основном используется для хранения персональной информации о каждом пользователе. Оно не имеет четко определенного синтаксиса. Первоначально в Веll Labs его использовали для хранения регистрационной информации, необходимой при передаче пакетных заданий из UNIХ-систем мэйнфрейму, работающему под управлением GECOS (Gеnегаl Еlесtriс Соmрrеhеnsivе Ореrаting Sуstem - комплексная операционная система компании Gеnегаl Еlесtriс).

В принципе структура поля GECOS может быть произвольной, но команда finger интерпретирует разделенные запятыми элементы поля в следующем порядке:

* полное имя (часто используется только это поле);

* номер офиса и здания;

* рабочий телефон;

* домашний телефон.

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

Домашний каталог

Войдя в систему, пользователь попадает в свой домашний каталог. Если на момент регистрации этот каталог отсутствует, выводится сообщение вроде “nо hоmе diгесtоrу” (домашний каталог отсутствует). Если в качестве значения поля домашнего каталога по умолчанию DEFAULT_НОМЕ в файле /еtс/1оgin.defs установлено nо, продолжение регистрации пользователя будет невозможно в противном случае пользователь попадает в корневой каталог.

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

Регистрационная оболочка

В качестве регистрационной оболочки, как правило, задается интерпретатор команд, например /bin!sh или /bin/сsh, но в принципе это может быть любая программа. По умолчанию используется интерпретатор bash, который запускается, если соответствующее поле в файле /еtс/раsswd не задано. В Linuх имена сsh и sh являются всего лишь ссылками на tcsh (надмножество команд csh) и bash (GNU-версия sh), соответственно. Во многих дистрибутивах есть также открытая версия интерпретатора ksh.

Пользователи могут менять интерпретатор с помощью команды сhsh. Файл /еtс/shells содержит список тех интерпретаторов, которые доступны для выбора. В SuSE этот список является обязательным для соблюдения, а в Red Hat будет лишь выдано предупреждение в случае выбора незарегистрированного интерпретатора.

Файл /ETC/SHADOW

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

Файл shadow не включает в себя файл раsswd, и последний не генерируется автоматически при изменении файла shadow. Оба файла необходимо сопровождать независимо друг от друга (или использовать команду наподобие useradd для автоматического управления файлами). Как и /еtс/раsswd, файл /еtс/shadow содержит одну строку для каждого пользователя. Каждая строка состоит из 9 полей, разделенных двоеточиями;

* регистрационное имя;

* зашифрованный пароль;

* дата последнего изменения пароля;

* минимальное число дней между изменениями пароля;

* максимальное число дней между изменениями пароля;

* количество дней до истечения срока действия пароля, когда выдается предупреждение;

* количество дней по истечении срока действия пароля, когда учетная запись аннулируется;

* срок действия учетной записи;

* зарезервированное поле, которое в настоящее время всегда пустое.

Лишь первые два поля обязательно должны быть заполнены. Поля дат задаются в виде числа дней (а не секунд), прошедших с 1-го января 1970 г. Это отличается от стандартного способа вычисления времени в UNIХ. Задавать поля можно с помощью команды usermod.

Типичная запись выглядит так:

millert:inN0.VRsc1Wn.:11508:0:180:14::12417:

Более подробное описание каждого поля.

* Регистрационное имя берется из файла /еtс/раsswd. Оно связывает записи файлов passwd и shadow.

* Зашифрованный пароль идентичен тому, который ранее хранился в файле /еtс/ раsswd.

* Третье поле содержит дату последнего изменения пользователем своего пароля. Это поле обычно заполняется программой /usr/bin/раsswd.

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

* В пятом поле задано максимальное число дней между двумя изменениями пароля. С помощью этой установки администраторы заставляют пользователей менять свои пароли. Максимальное время жизни пароля определяется суммой значений данного и седьмого полей.

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

* Седьмое поле определяет, спустя какое число дней после устаревания пароля отменяется учетная запись. Его назначение не совсем понятно.

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

* Девятое поле зарезервировано на будущее.

Теперь, когда назначение полей стало понятным, вернемся к рассмотренному выше примеру:

millert:inN0.VRsc1Wn.:11508:0:180:14::12417:

В этой записи говорится о том, что пользователь millert последний раз менял свой пароль 18 июля 2006 г. Следующий раз пароль должен быть изменен через 180 дней. За две недели до этого пользователь начнет получать предупреждения о необходимости сменить пароль. Учетная запись действительна до 31 декабря 2010г.

С помощью утилиты рwconv можно согласовать содержимое файлов /еtс/shadow и /еtс/раsswd. Большинство параметров файла shadow берется из стандартных установок файла /еtс/login.defs.

Базовая модель управления учетными записями реализуется автоматизированными утилитами с помощью стандартных команд:

1) adduser - регистрирует нового пользователя или изменяет информацию по умолчанию о новых пользователях.

Синтаксис:

- adduser [options] [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID] [--firstuid ID] [--lastuid ID] [--ingroup GROUP | --gid ID][--disabled-password] [--disabled-login][--gecos GECOS] [--add_extra_groups] user;

- adduser --system [параметры] [--home КАТ] [--shell ОБОЛОЧКА] [--no-create-home][--uid ID] [--group|--ingroup ГРУППА|--gid ID] [--disabled-password] [--disabled-login] [--gecos GECOS] пользователь.

Добавление обычного пользователя

При запуске с двумя аргументами и без параметров --system или --group, adduser добавляет обычного пользователя. adduser выберет первый доступный UID из диапазона обычных пользователей, заданного в файле настройки. UID может быть изменён с помощью параметра --uid. Диапазон, задаваемый файлом настройки, может быть изменён с помощью параметров --firstuid и --lastuid.

По умолчанию, каждый пользователь в Debian GNU/Linux входит в соответствующую группу с тем же именем. Объединение пользователей в группы позволяет групповую запись в каталог, что легко достигается посредством помещения соответствующих пользователей в новую группу, установкой set-group-ID бита на каталог и проверкой того, что все пользователи используют значение umask со значением 002. Если параметру USERGROUPS присвоить значение no, то все GID пользователей будут устанавливаться в USERS_GID. Первичные группы пользователей также могут быть изменены из командной строки с помощью параметров --gid или --ingroup, которые задают группу по id или по имени соответственно.

Также, пользователей можно добавить в одну или более групп, указанных в adduser.conf, установкой ADD_EXTRA_GROUPS равной 1 в adduser.conf, или указав --add_extra_groups в командной строке.

adduser создаёт домашний каталог в соответствии со значениями DHOME, GROUPHOMES и LETTERHOMES. Домашний каталог может быть изменён из командной строки с помощью параметра --home, а оболочка с помощью --shell. На домашнем каталоге устанавливается Set-group-ID бит, если USERGROUPS равно yes, и поэтому любые файлы, создаваемые в домашнем каталоге пользователя, будут иметь правильную группу.

adduser копирует файлы из SKEL в домашний каталог, запрашивает информацию для finger (gecos) и пароль. Gecos также может быть задан с помощью параметра --gecos. При задании параметра --disabled-login, учётная запись будет создана, но пока не будет определён пароль, доступ через неё останется заблокированным. При задании параметра --disabled-password пароль не нужен, но вход в систему всё равно возможен (например с помощью SSH RSA ключей).

Если файл /usr/local/sbin/adduser.local существует, то он будет выполнен после создания учётной записи пользователя, чтобы выполнить все локальные настройки. Аргументы передаваемые adduser.local: имя_пользователя uid gid домашний_каталог.

Значение переменной среды VERBOSE устанавливается по следующему правилу:

- 0, если указан -quiet;

- 1, если не указан --quiet или -debug;

- 2, если указан -debug.

Добавление системного пользователя.

При запуске с одним параметром без аргументов и параметром --system, adduser добавляет системного пользователя. Если пользователь с тем же именем уже существует, то adduser завершает работу с выдачей предупреждения.

adduser выберет первый доступный UID из диапазона системных пользователей, заданного в файле настройки (FIRST_SYSTEM_UID и LAST_SYSTEM_UID). Если необходим какой-то определённый UID, то можно указать его с помощью параметра --uid.

По умолчанию, системные пользователи помещаются в группу nogroup. Чтобы поместить нового системного пользователя в уже существующую группу, используйте параметры --gid или --ingroup. Чтобы поместить нового системного пользователя в новую группу с тем же ID, используйте параметр --group.

Домашний каталог создаётся по тем же правилам что и для обычных пользователей. Новый системный пользователь имеет оболочку /bin/false (если не указан параметр --shell) и заблокированный пароль. Начальные файлы настроек не копируются.

Параметры:

* --conf файл - использовать файл вместо /etc/adduser.conf.;

* --disabled-login - не запускать passwd для задания пароля. Пользователь не сможет использовать свою учётную запись, пока его пароль не установлен;

* --disabled-password - то же что и --disabled-login, но вход в систему возможен(например, с помощью ключей SSH RSA), но не использующих парольную аутентификацию;

* --force-badname - по умолчанию, имена пользователя проверяются согласно заданному регулярному выражению NAME_REGEX, указанному в конфигурационном файле. Этот параметр заставляет adduser выполнять только слабую проверку правильности имени;

* --gecos GECOS - задаёт поле gecos для новой создаваемой записи. adduser не будет запрашивать информацию для finger, если указан этот параметр;

* --gid ID - при создании пользователя этот параметр помещает пользователя в группу с этим номером;

* --group - при совместном использовании с --system, создаётся группа с тем же именем и ID как и у системного пользователя. Если же -system не задана, то создаётся группа с указанным именем;

* --help - показать краткую инструкцию;

* --home КАТ - использовать КАТ в качестве домашнего каталога пользователя, а не как задаётся по умолчанию в файле настроек. Если каталог не существует, то он будет создан и будут скопированы начальные файлы настроек;

* --shell оболочка - использовать оболочку в качестве регистрационной оболочки, а не как задано по умолчанию в файле настроек;

* --ingroup ГРУППА - добавить нового пользователя в ГРУППУ, а не в группу с тем же именем или группу по умолчанию, определяемую USERS_GID в конфигурационном файле. Это влияет на первичную группу пользователей;

* --no-create-home - не создавать домашний каталог, даже если он не существует;

* --quiet - не выводить информационные сообщения, показывать только предупреждения и ошибки;

* --debug - показывать отладочную информацию, очень полезно, если вы хотите понять в чём проблема у adduser;

* --system - создать системного пользователя;

* --uid ID - принудительно назначить новому userid определённый номер. adduser завершится неудачно, если такой userid уже используется;

* --firstuid ID - изменить первый uid диапазона, из которого выбран данный uid (заменяет значение FIRST_UID, указанное в конфигурационном файле);

* --lastuid ID - изменить последний uid диапазона, из которого выбран данный uid (LAST_UID);

* --add_extra_groups - добавляет нового пользователя в дополнительные группы, указанные в конфигурационном файле;

* --version - показать номер версии и информацию об авторском праве.

Команда useradd завершая работу, возвращает следующие значения:

* 0 - указанный пользователь существует. Возникает в 2 случаях: пользователь был создан adduser или пользователь уже был в системе перед тем как вызывалась adduser. Запуск adduser второй раз с теми же параметрами также вернёт 0;

* 1 - не удалось создать пользователя, так как он уже существуют но с другим UID, чем указано. Имя пользователя было отвергнуто, так как не подпадает под настроенные регулярные выражения. Работа adduser была прервана сигналом. Или по многим другим ещё неописанным причинам, которые объясняются выдаваемыми на консоль сообщениями. Затем можно убрать параметр --quiet, что сделает вывод adduser более подробным.

2) userdel - изменяет системные файлы учётных записей, удаляя все записи, относящиеся к указанному имени_пользователя. Заданная учётная запись должна существовать.

Синтаксис:

- deluser [параметры] [--force] [--remove-home] [--remove-all-files] [--backup] [--backup-to КАТ] пользователь;

- deluser --group [параметры] группа;

- deluser [параметры] пользователь группа.

При запуске с параметром, не имеющим аргументов и без параметра --group, deluser удалит обычного пользователя. По умолчанию, deluser удаляет пользователя без уничтожения домашнего каталога, почтового ящика или всех файлов системы, принадлежащих данному пользователю. Чтобы домашний каталог и почтовый ящик удалялся, можно указать параметр --remove-home. С параметром --remove-all-files удаляются все файлы в системе, принадлежащие данному пользователю. Заметим, что в этом случае указывать параметр --remove-home необязательно, так как все файлы, включая домашний каталог и почтовый ящик уже помечены на удаление параметром --remove-all-files.

Если необходимо сделать резервную копию всех файлов перед их удалением, то можно указать параметр --backup, при котором будет создан файл имя_пользователя.tar(.gz|.bz2), в каталоге, заданном параметром --backup-to (по умолчанию используется текущий рабочий каталог). Параметры удаления и резервного копирования также можно задать как действия по умолчанию в файле настройки /etc/deluser.conf.

Если необходимо удалить учётную запись root (uid 0), можно воспользоваться параметром --force; его указание подтверждает, что удаление пользователя root не является случайной ошибкой.

Если файл /usr/local/sbin/deluser.local существует, то он будет выполнен после удаления учётной записи пользователя, чтобы выполнить все локальные очистки. Аргументы, передаваемые deluser.local: имя_пользователя uid gid домашний_каталог

Параметры команды userdel:

* --conf файл - использовать файл вместо файлов по умолчанию /etc/deluser.conf и /etc/adduser.conf.;

* --help - показать краткую инструкцию;

* --quiet - не выводить сообщения о ходе работы;

* --system - выполнить удаление, только если пользователь является системным. Это помогает избежать случайного удаления не системного пользователя. Также, если пользователь не существует, то значение ошибки не возвращается. Этот параметр чаще всего используется в сценариях сопровождения пакетов Debian;

* --backup - выполнить резервное копирования всех файлов домашнего каталога и почтовое хранилище (mailspool-file) в файл с именем /$user.tar.bz2 или /$user.tar.gz.;

* --backup-to - помещать файлы резервных копий не в /, а в каталог, заданный этим параметром;

* --remove-home - удалить домашний каталог пользователя и его почтовое хранилище. Если указан --backup, то файлы будут удалены после создания резервной копии;

* --remove-all-files - удалить все файлы из системы, принадлежащие этому пользователю. Замечание: указывать ещё и --remove-home не имеет смысла. Если указан --backup, то файлы будут удалены после создания резервной копии;

* --version - показать номер версии и информацию об авторском праве.

Команда userdel завершая работу, возвращает следующие значения:

* 0 - действие успешно выполнено;

* 1 - удаляемый пользователь не является системным. Действие не выполнено;

* 2 - пользователь не существует. Действие не выполнено;

* 4 - внутренняя ошибка. Действие не выполнено;

* 9 - для удаления учётной записи root требуется указание параметра "--force". Действие не было выполнено.

3) usermod - изменяет системные файлы учётных записей согласно переданным в командной строке параметрам.

Синтаксис: usermod [параметры] LOGIN.

Параметры команды usermod:

* a, --append - добавить пользователя в дополнительную группу;

* c, --comment - новое значение поля комментария в файле пользовательских паролей. Обычно его изменяют с помощью программы;

* d, --home - новый домашний каталог пользователя. Если указан параметр -m, то содержимое текущего домашнего каталога будет перемещено в новый домашний каталог, который будет создан, если он ещё не существует;

* e, --expiredate - дата, когда учётная запись пользователя будет заблокирована. Дата задаётся в формате ГГГГ-ММ-ДД;

* f, --inactive - число дней, которые должны пройти после устаревания пароля, чтобы учётная запись заблокировалась навсегда. Если указано значение 0, то учётная запись блокируется сразу после устаревания пароля, а при значении -1 данная возможность не используется. По умолчанию используется значение -1;

* g, --gid - имя или числовой идентификатор новой начальной группы пользователя. Группа с таким именем должна существовать. Идентификатор группы должен указывать на уже существующую группу. По умолчанию идентификатор группы установлен в 1;

* G, --groups - список дополнительных групп, в которых числится пользователь. Перечисление групп осуществляется через запятую, без промежуточных пробелов. На указанные группы действуют те же ограничения, что и для группы указанной в параметре -g. Если пользователь член группы, которой в указанном списке нет, то пользователь удаляется из этой группы. Такое поведение можно изменить с помощью параметра -a, при указании которого к уже имеющемуся списку групп пользователя добавляется список указанных дополнительных групп;