Дипломная работа: АИС управления серверным программным обеспечением на базе программного комплекса Webmin/Alterator

Государственное образовательное учреждение высшего профессионального образования

«Сибирская государственная автомобильно-дорожная академия (СибАДИ)»

Факультет Информационные системы в управлении

Специальность Автоматизированные системы обработки информации и управления

Кафедра Компьютерные информационные автоматизированные системы

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к дипломному проекту

Обозначение проекта ДП-02068982-230102-14-10

Тема проекта АИС управления серверным программным обеспечением на базе программного комплекса Webmin/Alterator

Студент группы АС-05И1

Майненгер Иван Геннадьевич

Омск 2010

Государственное образовательное учреждение высшего профессионального образования

«Сибирская государственная автомобильно-дорожная академия (СибАДИ)»

Кафедра Компьютерные информационные автоматизированные системы

УТВЕРЖДАЮ

Зав кафедрой КИАС

__________________ / С.Н. Чуканов/

«___» ___________20___г.

Задание

К дипломному проекту (работе) студенту гр. АС05И1

Майненгер Ивану Геннадьевичу

1 Тема работы: АИС управления серверным программным обеспечением на базе программного комплекса Webmin/Alterator

Утверждена приказом по СибАДИ № П-10-95/СТ от «29» марта 2010г.

2 Исходные данные к работе: результаты преддипломной практики результаты анализа литературы и интернет – источников.

3 Содержание пояснительной записки (конкретный перечень подлежащих разработке вопросов):

Введение

3.1 Анализ объекта автоматизации

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

3.3 Анализ алгоритмов

3.4 Руководство по эксплуатации

3.5 Экономическое обоснование проекта

3.6 Безопасность жизнедеятельности

Заключение

Список использованных источников

4 Перечень демонстрационного материала для сопровождения доклада в ГАК:

- демонстрационный плакат

- демонстрационная версия разработанной системы

5 Консультанты по разделам работы:

5.1 Экономический раздел – доцент, к.э.н. Сухарева Светлана Витальевна

5.2 Безопасность жизнедеятельности – доцент, к.т.н. Бедрина Елена Анатольевна

6 Назначенный кафедрой рецензент работы:

Задание выдано “____” __________ 20___г.

Руководитель работы ___________________ к.ф.-м.н. Барановский С.П., доцент кафедры КИАС

Задание к исполнению принял “___” __________20___г.

Студент _________________________________/Майненгер И.Г./

Реферат

Пояснительная записка

СЕРВЕР, СЕТЬ, УПРАВЛЕНИЕ, ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ, WEBMIN, ALTERATOR, LINUX, ПРОТОКОЛ, ИНТЕРФЕЙС.

Объектом для проекта является серверное программное обеспечение Министерства промышленной политики, транспорта и связи Омской области.

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

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

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

Список условных сокращений и обозначений

BSD – Berkley Software Distributions license;

GPL – General Public License;

PHP – Personal Home Page;

АИС – автоматизированная информационная система;

БД – база данных;

ПК – программный комплекс;

ПО – программное обеспечение;

ПЭВМ – персональная электронная вычислительная машина;

СУБД – система управления базами данных;

ТО – техническое обеспечение;

ФСТЭК – Федеральная служба по техническому и экспортному контролю.

Содержание

Введение

1. Анализ существующей системы

1.1 Характеристика объекта автоматизации

1.2 Структура Министерства

1.3 Обоснование необходимости разработки АИС

1.4 Обзор аналогов проектируемой системы

1.5 Обоснование выбора используемого программного комплекса

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

1.7 Требования к системе

1.8 Вывод по разделу

2. АИС управления серверным программным обеспечением на базе программного комплекса Webmin/Alterator

2.1 Модель потоков данных

2.2 Функциональная модель

2.3 Практические цели и назначение системы

2.4 Обзор программного комплекса

2.5 Обзор платформы (конфигуратора)

2.6 Автоматизируемые функции

2.7 Выводы по разделу

3 Описание алгоритмов

3.1 Описание работы с пользователями

3.2 Описание протокола SMB

3.3 Описание протокола DNS

3.4 Протокол NFS

3.5 Выводы по разделу

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

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

4.2 Создание первичного контроллера домена в Webmin

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

Выводы по четвертому разделу

5. Экономическое обоснование проекта

5.1 Цель и краткое описание программного продукта

5.2 Определение затрат труда на разработку программного продукта

5.3 Определение численности исполнителей

5.4 Расчет себестоимости разработки программного продукта

5.5 Расчет экономической эффективности внедрения продукта

5.6 Вывод по разделу

Заключение

Список использованных источников

Приложение А

Введение

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

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

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

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

Цель создания системы

Целью создания автоматизированной информационной системы является внедрение для Министерства промышленной политики, транспорта и связи Омской области программно комплекса Webmin/Alterator, позволяющего решить следующие задачи:

производить мониторинг процессов, запускать, останавливать и перезапускать процессы;

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

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

Актуальность проекта

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

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

Новизна проекта

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

Структура проекта

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

в первом разделе проведен анализ объекта автоматизации, техническое задание и постановка задачи;

во втором разделе приведен проект создания АИС управления серверным программным обеспечением;

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

в четвертом разделе приведено краткое руководство пользователя и примеры решения практических задач;

пятый раздел содержит организационную часть и экономические расчеты затрат на создание АИС;

в шестом разделе рассмотрены вопросы охраны труда.

1. Анализ существующей системы

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

1.1 Характеристика объекта автоматизации

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

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

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

1.2 Структура Министерства

На рисунке 1.1 представлена организационная структура министерства.

Рисунок 1.1 – Структура министерства промышленной политики, транспорта и связи Омской области

1.3 Обоснование необходимости разработки АИС

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

неполное и частично неэффективное использование технических средств, имеющихся в наличии;

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

не автоматизированный процесс конфигурирования и настройки серверного оборудования.

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

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

Основные недостатки отсутствия управления программным обеспечением представлены на рисунке 1.2.

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

Графическое представление дерева целей отражено на рисунке 1.3.

Рисунок 1.2 - Дерево проблем, характеризующее основные недостатки отсутствия АИС.

Рисунок 1.3 – Дерево целей

1.4 Обзор аналогов проектируемой системы cPanel

cPanel — платная панель управления веб-хостингом. Функционирует посредством отдельной копии веб-сервера, работающей, как правило, на порту 2082 (или 2083/SSL).

В состав cPanel входит достаточно большое количество свободного ПО, основным из которого является Apache, MySQL, PHP, exim.

Основные особенности: использование шаблонов, наличие локализации на 25 языках. Встроенная утилита «Фантастико» содержит порядка 50 готовых к использованию скриптов.

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

По состоянию на ноябрь 2008 года производителем заявлена поддержка следующих операционных систем:

Red Hat Enterprise Linux (рекомендованная ОС);

CentOS (рекомендованная ОС);

FreeBSD (предлагается использовать только квалифицированным специалистам).

cPanel может быть установлен и на другие дистрибутивы Linux, но это может потребовать больше усилий от администратора, чем использование ОС рекомендованных производителем. При использовании FreeBSD необходимо соблюдать рекомендацию разработчиков Cpanel и не использовать для установки нового ПО бинарные пакеты («пакаджи»), а пользоваться только портами.

На рисунке 1.4 представлен интерфейс cPanel.

DirectAdmin

DirectAdmin — панель управления веб-хостингом, созданная в 2003 году Канадской компанией JBMC Software. DirectAdmin широко используется западными и российскими хостинг-провайдерами.

Панель управления DirectAdmin поддерживает операционные системы: FreeBSD, GNU/Linux (дистрибутивы CentOS, Red Hat, Fedora, Debian).

И работает с программным обеспечением: MySQL, Dovecot, Exim, Apache, PHP, Perl, BIND.

Также, DirectAdmin имеет открытый API и возможность написания собственных скриптов для автоматизации процессов.

Первая публичная версия (0.95) DA увидела свет 1 марта 2003 года. На данный момент последней стабильной версией панели управления является 1.336, представленная 28 апреля 2009 года.

Возможности:

Управление сервером (запуск\остановка демонов, настройка системы).

Управление сайтами клиентов (virtual-hosts, DNS).

Управление учетными записями пользователей.

Создание реселлеров услуг.

Управление резервным копированием (в том числе — на удаленный сервер).

Контроль состояния сервера.

Преимуществами DirectAdmin являются:

Скорость работы и нетребовательность к ресурсам сервера.

Большой спектр поддерживаемых операционных систем и дистрибутивов.

Низкая стоимость.

Простота использования.

Недостатками являются:

Сложность администрирования и обновления.

Отсутствие официальной поддержки на русском языке.

Бедность функционала.

На рисунке 1.5 представлен интерфейс DirectAdmin.

1.5 Обоснование выбора используемого программного комплекса

Рассмотренные в пункте 1.4 программные продукты не удовлетворяют требованиям объекта автоматизации и имеют некоторые недостатки:

неполная функциональность;

отсутствие открытого кода программы и как следствие затруднение с её доработкой и созданием модулей;

программные продукты распространяются за плату.

В свою очередь, создаваемый на основе Webmin/Alterator программный комплекс будет иметь следующие положительные стороны:

Скорость работы и нетребовательность к ресурсам сервера;

Большой спектр поддерживаемых операционных систем и дистрибутивов;

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

Для Webmin - свободное распространение, лицензия BSD;

Для Alterator наличие сертификации ФСТЭК.

Этими доводами обусловлен выбор программных комплексов для создания АИС управления серверным программным обеспечением.

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

Назначение системы

Автоматизированная информационная система управления серверным программным обеспечением на базе программного комплекса Webmin/Alterator предназначена для автоматизации процесса настройки и конфигурирования программного обеспечения на серверах и сетевом оборудовании. АИС предполагается использовать в Министерстве промышленной политики, транспорта и связи Омской области.

Цели создания системы

Цели создания данной системы:

уход от необходимости ручной работы в процессе настройки работы сети;

повышение оперативности, объективности в работе с оборудованием;

автоматизация процесса управления серверным программным обеспечением;

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

Полученные объективные данные будут являться для принятия управленческих решений.

1.7 Требования к системе

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

При реализации ИС должны быть обеспечены меры по защите информации от несанкционированного доступа, в соответствии с требованиями руководящих документов (СТР-К);

ИС должна содержать механизм своевременной актуализации информационного наполнения;

ИС должна быть создана на основе свободно распространяемого программного обеспечения;

ИС должна иметь модульную структуру;

в ИС должны использоваться международные стандарты описания информации, удобные для обмена информацией между различными приложениями и использования в системе управления информацией;

ИС должна содержать подсистему авторизованного доступа к информационным ресурсам;

ИС должна соответствовать стандартам открытых систем ISO ( ISO/IEC 17799, ISO 27000, ISO/IEC 27001, ISO 8601, ISO 9241);

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

ИС должна обеспечивать совместную работу групп пользователей;

ИС должна использовать информацию, передаваемую по каналам электросвязи, использующим протокол стека TCP/IP.

Требования к структуре и функционированию системы

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

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

При разработке данной системы Администратором будет использован набор библиотек и сервисов - ядро базовой функциональности информационной системы, поставляемое в виде базового программного комплекса Webmin.

Программный комплекс Webmin является открытым программным обеспечением, распространяемым по лицензии BSD (Berkley Software Distributions license).

Используемые при разработке платформы Webmin технологии не противоречат требованиям архитектуры программного обеспечения. Платформа Webmin поставляется по открытой лицензии GPL (General Public License).

Требования к численности и квалификации персонала системы и режиму его работы.

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

Показатели назначения.

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

Требования к надежности

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

Требования безопасности

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

Требования к эргономике и технической эстетике

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

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

Требования по сохранности информации при авариях

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

Требования к защите от влияния внешних воздействий

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

Требования по стандартизации и унификации

Необходимо обеспечить максимальную стандартизацию задач системы, поставляемых программных средств, унифицированных форм управленческих документов, установленных ГОСТ 6.10.1-88.

1.8 Вывод по разделу

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

2 АИС управления серверным программным обеспечением на базе программного комплекса Webmin/Alterator

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

2.1 Модель потоков данных

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

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

На рисунке 2.1 представлена контекстная диаграмма потоков данных разрабатываемой автоматизированной системы.

Рисунок 2.1 – Контекстная диаграмма потоков данных

Существует 5 видов стрелок:

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

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

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

Механизм – ресурсы, которые выполняют работу. Рисуется как входящая в верхнюю грань.

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

2.2 Функциональная модель

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

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

Рисунок 2.2 – Функциональная модель

2.3 Практические цели и назначение системы

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

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

Основной целью применения ПК Webmin/Alterator в Министерстве промышленной политики, транспорта и связи Омской области является повышение эффективности работы Министерства.

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

2.4 Обзор программного комплекса

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

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

Вторым несомненным плюсом Webmin'a является его стоимость - данная панель управления бесплатно распространяется для коммерческого и некоммерческого использования. Авторы этой программы не жадничают и позволяют всем желающим не только бесплатно использовать программу, но и изменять ее по своему усмотрению. Именно благодаря этому вокруг Webmin сложился мощный пласт сторонних добровольных помощников-программистов, которые дописывают данную программу, исправляют неудачные места, пишут дополнительные модули, производят перевод на другие языки. Благодаря этому Webmin оброс большой функциональностью, огромным количеством подключаемых модулей и переведен практически на все европейские языки, включая русский.

2.5 Обзор платформы (конфигуратора)

Alterator — новое поколение платформ для разработки сложных систем. Используются по большей части Scheme, C и старый добрый sh+awk. На данный момент используется как инсталлятор и конфигуратор системы.

Alterator можно разделить на два слоя: backend и frontend. Первый слой реализует низкоуровневое взаимодействие с системой. Второй — высокоуровневый интерфейс с пользователем.

Пользовательский интерфейс пишется на языке Scheme. Бэкенды могут быть написаны на любом языке программирования. Существуют библиотеки на Shell, Perl и Ruby для упрощения разработки.

Рисунок 2.3 – Архитектура Alterator

2.6 Автоматизируемые функции

- Создание, редактирование, и удаление пользователей в вашей системе.

- Экспорт файлов и директорий в другие системы с помощью протокола NFS.

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

- Установка, просмотр и удаление программ в RPM и других форматах.

- Изменение IP-адреса, параметров DNS, и конфигурации роутинга.

- Настройка firewall для защиты компьютера или для раздачи компьютерам из локальной сети доступа в Интернет.

- Создание и конфигурация виртуальных Web-сайтов на сервере Apache.

- Управление базами данных, таблицами, и записями в базе данных MySQL или PostgreSQL.

- Совместное использование файлов с Windows-системами с помощью настройки Samba.

2.7 Выводы по разделу

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

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

3 . Описание алгоритмов

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

3.1 Описание работы с пользователями

Пользователи системы

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

Многопользовательская модель разграничения доступа

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

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

Учетные записи

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

Учетная запись (account) - объект системы, при помощи которого Linux ведет учет работы пользователя в системе. Учетная запись содержит данные о пользователе, необходимые для регистрации в системе и дальнейшей работы с ней. Учетные записи могут быть созданы во время установки системы или после установки.

Главное для человека в учетной записи - ее название, входное имя пользователя. Именно о нем спрашивает система, когда выводит приглашение "login:". Помимо входного имени в учетной записи содержатся некоторые сведения о пользователе, необходимые системе для работы с ним. Ниже приведен список этих сведений.

Входное имя (login name) - название учетной записи пользователя, которое нужно вводить при регистрации в системе.

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

Linux связывает входное имя c идентификатором пользователя в системе - UID (User ID). UID - это положительное целое число, по которому система и отслеживает пользователей. Обычно это число выбирается автоматически при регистрации учетной записи, однако оно не может быть произвольным. В Linux есть некоторые соглашения относительно того, какому типу пользователей могут быть выданы идентификаторы из того или иного диапазона. В частности, UID от "0" до "100" зарезервированы для псевдопользователей.

Идентификатор группы

Кроме идентификационного номера пользователя, с учетной записью связан идентификатор группы. Группы пользователей применяются для организации доступа нескольких пользователей к некоторым ресурсам. У группы, так же, как и у пользователя, есть имя и идентификационный номер - GID (Group ID). В Linux пользователь должен принадлежать как минимум к одной группе - группе по умолчанию. При создании учетной записи пользователя обычно создается и группа, имя которой совпадает с входным именем, именно эта группа будет использоваться как группа по умолчанию для данного пользователя. Пользователь может входить более чем в одну группу, но в учетной записи указывается только номер группы по умолчанию.

Полное имя

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

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

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

Командная оболочка

Каждому пользователю нужно предоставить способ взаимодействия с системой: передача ей команд и получение от нее ответов. Для этой цели служит специальная программа - командная оболочка (или интерпретатор командной строки). Она должна быть запущена для каждого пользователя, который зарегистрировался в системе. Поскольку в Linux доступно несколько разных интерпретаторов командной строки, в учетной записи указано, какой из них нужно запустить для данного пользователя. Если специально не указывать командную оболочку при создании учетной записи, она будет назначена по умолчанию, вероятнее всего это будет bash.

Интерпретатор командной строки (командный интерпретатор,командная оболочка, оболочка) - это программа, используемая в Linux для организации "диалога" человека и системы. Командный интерпретатор имеет три основных ипостаси:

редактор и анализатор команд в командной строке,

высокоуровневый системно-ориентированный язык программирования,

средство организации взаимодействия команд друг с другом и с системой.

Понятие "администратор"

В Linux есть только один пользователь, полномочия которого в системе принципиально отличаются от полномочий остальных пользователей - это пользователь с идентификатором "0". Обычно учетная запись пользователя с UID=0 называется root (англ., "корень"). Пользователь root - это "администратор" системы Linux, учетная запись для root обязательно присутствует в любой системе Linux, даже если в ней нет никаких других учетных записей. Пользователю с таким UID разрешено выполнять любые действия в системе, а значит, любая ошибка или неправильное действие может повредить систему, уничтожить данные и привести к другим печальным последствиям. Поэтому категорически не рекомендуется регистрироваться в системе под именем root для повседневной работы. Работать в root следует только тогда, когда это действительно необходимо: при настройке и обновлении системы или восстановлении после сбоев.

3.2 Описание протокола SMB

SMB, или иначе CIFS – это протокол, определяющий сетевую файловую систему, ее структуру и порядок использования. NetBIOS предоставляет интерфейс, через который SMB-сообщения передаются в сети, он используется серверами для "анонса" служб в сети, и клиентами для "обзора" этих служб. NetBIOS в качестве транспортного протокола может использовать любой низкоуровневый сетевой протокол, однако наиболее часто используется TCP/IP; когда NetBIOS работает поверх TCP/IP, это называется NBT. WINS предоставляет централизованные службы имен (отображение имен машин в IP-адреса) там, где это необходимо.

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

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

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

Сервис печати. Рабочая станция может ставить файлы в очередь для печати на сервере и получать информацию об очереди печати.

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

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

открыть и закрыть файл;

создание и удаление директорий;

чтение и запись в файл;

поиск файлов;

посылка на печать и отмена печати на принтере.

Все эти операции могут быть помещены в сообщение SMB и переданы к и от сервера. Название SMB происходит от названия формата данных √ разновидности стандартных системных вызовов DOS к различным структурам данных или Server Message Blocks, адаптированная для передачи данных другому компьютеру по сети.

Формат SMB

Richard Shape из команды разработчиков Samba дал определение протоколу SMB как запрос-ответ. На практике это означает, что клиент посылает запрос SMB к серверу и сервер отвечает сообщением на этот запрос. Сервер редко формирует ответы, которые не относятся к клиенту.

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

Формат заголовка SMB

Таблица 3.1 показывает формат заголовка SMB. Команды SMB не обязательно должны заполнять все поля заголовка SMB. Например, когда клиент впервые пытается соединиться с сервером, то значение идентификатора дерева (TID) пусто √ он появляется после успешного соединения и нулевое значение TID (0xFFFF) устанавливается в соответствующее поле заголовка. Другие поля могут также устанавливаться в ноль, когда не используются.

Значения полей заголовка SMB перечислены в Таблице 3.1.

Таблица 3.1 Поля заголовка SMB

Формат команды SMB

После того, как заголовок представлен определенным числом байт, происходит выполнение команды SMB. Любая команда, например такая, как открыть файл (ID поля COM: SMBopen ) или получить запрос на печать (SMBsplretq), имеет свой набор параметров и данные. Как и в поле заголовка SMB, здесь также могут быть заполнены не все командные поля, все зависит от команды. Например, команда GetServerAttributes (SMBdskattr) устанавливает поля WCT BCC в 0. Поля командных сегментов показаны в Таблице 3.2.

Таблица 3.2 - Содержание команды SMB

3.3 Описание протокола DNS

Служба Доменных Имен (Domain Name System) предназначена для того, чтобы машины, работающие в Internet, могли по доменному имени узнать IP-адрес нужной им машины, а также некоторую другую информацию; а по IP-номеру могли узнать доменное имя машины.

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

Каждый клиент знает своего сервера; обычно указывается не один, а несколько серверов - если первый не отвечает, клиент обращается ко второму и так далее до исчерпания списка. В принципе неважно, к какому серверу обращаться - они дают (должны давать при правильном функционировании) одинаковые ответы на любой запрос. Поэтому для ускорения работы обычно указывают ближайший. Следует помнить, что на одной машине могут функционировать одновременно Name-сервер и программы-клиенты; поэтому если на машине запущен Name-сервер, то в качестве Name-сервера на ней должен быть прописан "я сам".

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

Очень редко используются доменные имена из двух сегментов; имена из трех и четырех сегментов составляют подавляющую долю всех имен Internet; имена из пяти сегментов встречаются довольно редко.

Допустим, клиент запросил адрес "www.организация.город.страна". Поиск информации по доменному имени происходит следующим образом:

Клиент спрашивает своего сервера.

Если тот является сервером данной зоны, то ответит, на чем все заканчивается.

Сервер спрашивает корневой сервер.

Тот не может ответить, потому что не знает; зато знает, какой сервер отвечают за зону "страна".

Сервер зоны "страна" тоже не может ответить, но знает, что нужно спросить сервер зоны "город.страна".

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

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

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

Следует обратить внимание на сходство, различие и взаимодействие систем DNS и IP-маршрутизации. Как и IP-маршрутизация, DNS работает по принципу делегирования полномочий, но выделение доменных имен совершенно не зависит от выделения IP-адресов. Для примера рассмотрим домен freebsd.org. Это - домен организации, занимающейся распространением операционной системы FreeBSD Unix. FTP-сервер, содержащий дистрибутив операционной системы и множества утилит для нее, имеет копии в нескольких десятках стран.

Политика и стратегия назначения имен

Имена зон условно можно разделить на "организационные" и "географические". В высшей зоне зарегистрированы следующие "организационные" зоны:

com - commercial (коммерческие);

edu - educational (образовательные);

gov - goverment (правительственные);

mil - military (военные);

net - network (организации, обеспечивающие работу сети);

org - organization (некоммерческие организации).

3.4 Протокол NFS

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

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

1. Для пользовательского приложения скрыто, обращается он к местному файлу или через NFS к файлу на удаленном хосте (далее последние будем кратко называть NFS-файлами). За него это знает ядро: в момент открытия файла оно определяет его местонахождение и в зависимости от этого в последующем все обращения к местным файлам отдает на обработку своей файловой системе, а те, что относятся к дальним файлам, направляет NFS-клиенту.

2. NFS-клиент посылает RFC-запросы на NFS-сервер через используемый транспортный протокол. Большей частью NFS работает по UDP, но последние реализации могут быть конфигурированы на установление соединений по TCP.

3. NFS-сервер принимает дейтаграммы с запросами NFS-клиента на свой UDP-порт 2049. Хотя, в принципе, NFS-сервер мог бы использовать эфемерный порт, объявляя его на регистраторе портов, в большинстве реализаций NFS зафиксирован стандартный порт 2049.

4. При поступлении запроса от NFS-клиента NFS-сервер транслирует его в запросы к своей местной файловой системе, которая и осуществляет соответствующие действия на диске хоста сервера.

5. Обработка запроса на сервере может занять значительное время, особенно если потребуется выполнить манипуляции в его файловой системе. Чтобы в период выполнения одного запроса не блокировать запросы от других NFS-клиентов, NFS-сервер должен обрабатывать их параллельно. Способ параллельной обработки зависит от возможностей конкретной операционной системы. Поскольку большинство реализаций Unix не поддерживают механизм нитей (multithreading), то обычно используемый искусственный прием состоит в следующем. Запросы от клиента на стороне сервера обрабатывает пользовательский процесс, называемый демоном. NFS (обычное его имя — nf sd), который может сам себя копировать в некотором числе экземпляров. Эта простейшая программа посылает один не требующий ответа вызов в код встроенного в ядро NFS-сервера.

6. В свою очередь, и NFS-клиент, обслуживающий свой пользовательский процесс, вынужден, выслав RPC-запрос, в течение достаточно длительного времени ждать завершения его обработки на сервере до получения RPC-ответа. Поэтому и на клиентском хосте необходимо так или иначе обеспечить параллельное обслу­живание многих использующих NFS пользовательских процессов, что также ре­шается различными способами в зависимости от операционной системы. В Unix на хосте клиента NFS часто используется тот же прием, что и в случае сервера: создается новая копия пользовательского процесса, называемого здесь демоном блочного ввода-вывода (biod), который посылает один не требующий ответа вызов в код встроенного в ядро NFS-клиента.

Большинство хостов в Unix поддерживают либо NFS-клиента, либо NFS-сервера, либо обоих одновременно. Реализации NFS-клиентов существуют и для персональных компьютеров с операционными системами, например, от Microsoft. Мэйнфреймы, в частности фирмы IBM, часто выполняют роль только NFS-сервера.

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

Та или иная файловая система NFS-сервера становится доступной с машины NFS-клиента только после того, как будет на ней должным образом смонтирована. Для этого NFS-клиент обращается с соответствующим запросом к демону монтирования (mount daemon) NFS-сервера. Сам протокол монтирования в NFS будет рассмотрен ниже.

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

3.5 Выводы по разделу

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

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

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

Настройка Webmin для работы с серверными приложениями.

Программный комплекс запускается путем ввода в адресную строку https://<ip-сервера>:10000 (https, если с поддержкой SSL). После чего появится окно входа в систему. В открывшемся окне следует заполнить:

Логин (логическое имя) пользователя;

Пароль для входа в систему.

На рисунке 4.1 представлен внешний вид программного комплекса при входе в систему.

Рисунок 4.1 – Вход в систему

Если авторизация прошла успешно, открывается главное окно, содержащие сведения о системе и разделы.

Раздел Система (System) связан с общими настройками операционной системы. Здесь вы можете настраивать файловые системы, пользователей, группы и поведение системы при загрузке. Вы можете управлять сервисами, работающими в системе, и контролировать, запускаются ли они автоматически иконками Bootup и Shutdown. Настройка этих сервисов производится в разделе Servers. Особый интерес представляет утилита "Software Packages". Она позволяет легко просматривать пакеты, установленные на вашей системе, а также предоставляет интерфейсы доступа к репозиторию обновлений дистрибутива и к debfind.net, публичному DEB репозиторию в Internet.

В разделе Сервисы (Servers) размещены модули настройки различных сервисов, которые могут быть запущены на вашей системе. Очень удобны утилиты для настройки BIND и DHCP. Также очень просто пользоваться утилитой для настройки Samba -- файл- и принтсерверов для Windows и других клиентов. Webmin также избавит вас от проблем с настройкой SMTP сервера Sendmail, пользующегося дурной славой из-за сложного конфигурационного файла.

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

Раздел Оборудование (Hardware) предназначен для конфигурирвания физических устройств, в основном принтеров и устройств хранения. Утилита Logical Volume Management (LVM) особенно интересна, поскольку позволяет визуально управлять динамическими томами в вашей Linux системе.

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

Раздел Прочее (Others) содержит разнообразные утилиты, которые могут оказаться вам полезны. "SSH/Telnet Login" и "File Manager" реализованы в виде апплетов и не могут быть запущены, пока у браузера не установлено JRE. Утилита "Perl Modules" будет полезна для обслуживания модулей Perl, и позволяет напрямую подсоединяться к CPAN в интернете. "File Manager" обеспечивает доступ к файловой системе сервера с интерфейсом, похожим на Explorer, и позволяет перемещать и копировать файлы без перемещения их через память вашей рабочей станции (если вы работаете удаленно). "SSH/Telnet Login" - утилита, позволяющая вам получить доступ к консоли удаленной машины через ваш браузер.

На рисунке 4.2 представлен внешний вид программного комплекса после авторизации.

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

Модуль File Manager

Модуль File Manager находится в категории Прочее (Other). Он несколько отличается от большинства других модулей. Вместо предоставления возможности настройки серверов и служб, этот модуль позволяет пользователям просматривать и управлять файлами на сервере при помощи файлового менеджера. Интерфейс похож на старый explorer в Windows: слева - дерево каталогов, а справа - содержимое текущей папки, сверху - кнопки и панель инструментов.

Пользователи и группы

В Webmin, модуль The Users and Groups (Пользователи и группы), который находится в категории System (Система), может быть использован для создания, редактирования и удаления UNIX пользователей и групп в системе..

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

Внешний вид работы с пользователями представлен на рисунке 4.3.

Модуль System and Server Status

Этот модуль позволяет отслеживать состояния выбранных серверов и запущенных демонов. С его помощью можно легко определить какие процессы выполняются должным образом или выявить те процессы, работа которых нарушена. Также можно сконфигурировать модуль таким образом, что при проверке состояния сервера происходила отправка сообщения по e-mail или выполнялась какая-либо команда. Эта функция может быть полезна если система управляет серверами, от которых зависят другие люди, такими как web или DNS сервера.

Внешний вид модуля System and Server Status представлен на рисунке 4.4.

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

Установка нового модуля представлена на рисунке 4.5.

4.2 Создание первичного контроллера домена в Webmin

Первичный контроллер домена хранит у себя БД пользователей домена, их пароли, права доступа и прочую информацию. Это позволяет им авторизовавшись один раз посещать все сетевые ресурсы домена без ввода пароля. PDC позволяет применять так называемые logon scripts - текстовые файлы хранящиеся на сервере, в которых содержатся команды, которые будут выполнены на машине клиента при входе в домен. С их помощью можно проводить автоматическое монтирование сетевых дисков, синхронизацию часов, запуск других программ и так далее. На PDC можно настроить перемещаемые профили (roaming profiles). Они используются для хранения windows профиля пользователя (рабочий стол, меню пуск, оформление и пр.) на сервере. Т.е. пользователь, залогинившись с любого компьютера в сети будет работать в своем настроенном рабочем окружении. Конечно такая возможность предполагает наличие быстрого сетевого соединения и наличия достаточного свободного место на диске сервера. Ну и напоследок тот момент что пользователь он на то и пользователь чтобы пользоваться, администрировать он ничего не сможет (пока конечно вы не дадите ему таких прав), следовательно и исправлять будет нечего - это также немаловажный аргумент перехода на PDC.

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

Внешний вид менеджера ресурсов Samba представлен на рисунке 4.6. Модуль включает в себя:

Настройки безопасности;

Настройки сети Unix и Windows;

Параметры вывода на печать;

Параметры использования файловых ресурсов.

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

Внешний вид правки конфига представлен на рисунке 4.10.

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

На рисунке 4.11 представлен внешний вид конфигуратора Alterator.

Рисунок 4.11 Интерфейс Alterator

4.4 Выводы по четвертому разделу

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

5 . Экономическое обоснование проекта

Целью данного раздела является доказательство экономической целесообразности создания автоматизированной информационной системы управления программным обеспечением серверного оборудования на базе программного комплекса Webmin/Alterator.

5.1 Цель и краткое описание программного продукта

Наименование программного продукта: АИС управления серверным программным обеспечением.

Целью является внедрение для Министерства промышленной политики, транспорта и связи Омской области программного комплекса Webmin, позволяющего решить следующие задачи:

производить мониторинг процессов, запускать, останавливать и перезапускать процессы;

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

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

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

5.2 Определение затрат труда на разработку программного продукта

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

- минимальные затраты времени на выполнение отдельного вида работ;

- максимальное время выполнения при наименее благоприятных условиях.

По этим величинам оценивается ожидаемое значение трудоемкости и стандартное отклонение.

Ожидаемое значение трудоемкости рассчитывается по формуле:

,

где i – номер этапа.

Стандартное отклонение оценивается по следующей формуле:

,

где i – номер этапа.

Экспертные оценки и расчетные величины трудоемкости, а также стандартные отклонения по всем видам работ приведены в таблице5.1.

Таблица 5.1– Оценка трудоемкости отдельных по всем видам работ

Общая трудоемкость работы составляет 880 человеко-часов или 5 месяцев (по 22 рабочих дня в каждом месяце). Стандартное отклонение составляет менее 5 %, то есть степень достоверности того, что работа будет выполнена в срок, велика.

5.3 Определение численности исполнителей

Период разработки программы – 5 месяцев, с 1 января по 1 июня 2010 года.

Количество рабочих дней в каждом месяце равно 22. Рабочий день равен 8 часам. Отсюда получаем действительный фонд времени за период разработки программы:

ч.

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

Таким образом, получаем:

чел.

Отсюда следует, что разработчиком будет являться один исполнитель – техник.

В таблице 5.2 представлено распределение трудоемкости по стадиям разработки и исполнителям.

Таблица 5.2 – Распределение трудоемкости по стадиям разработки

5.4 Расчет себестоимости разработки программного продукта

Расчет основной заработной платы

Основная заработная плата рассчитывается, исходя из трудоемкости работ, выполняемых специалистом i-й квалификации при разработке программного продукта () в чел/ч и размера оплаты труда 1 чел/ч.

Основная заработная плата разработчика за месяц рассчитывается по следующей формуле:

,

где

- основная заработная плата разработчика, руб.;

- оклад техника, руб.;

- общая трудоемкость работ, ч.

Оклад сотрудника отдела информационных систем – 10000 руб./мес.

Трудоемкость техника – 880 ч.

Таким образом, основная заработная плата разработчика, при районном коэффициенте 1,15, применяемом к окладу работников, проживающих в городе Омске и среднем количестве рабочих часов в месяц равном 176 следующая:

руб.

Расчет дополнительной заработной платы

Дополнительная заработная плата в среднем составляет 12% от основной заработной платы.

Таким образом, дополнительная заработная плата составит:

руб.

Расчет отчислений на социальные нужды

Сумма отчислений на социальные нужды составляет 26% от суммы основной и дополнительной заработной платы.

Отчисления на социальные нужды составят:

руб.

Расчет расходов по отладке программного продукта

Расходы по отладке определяются, исходя из планируемых затрат машинного времени, необходимого для разработки и оформления программного продукта (Тм.в), и стоимости одного машино-часа работы ЭВМ, на которой ведется разработка (См.ч.):

Cотл = См.ч. * Тм.в ,

Стоимость одного машино-часа определяется по формуле:

См.ч. = Сэ / Фвт Кз,

где Сэ – годовые расходы, обеспечивающие функционирование вычислительного комплекса, руб./год;

Ф – годовой плановый фонд времени работы вычислительного комплекса, ч.;

Кз –коэффициент загрузки (не более 0,9-0,95).

Рассчитаем годовой плановый фонд времени:

Фвт = Фном - Фпроф,

где Ф – номинальный фонд времени работы вычислительного комплекса, ч.

Ф = 12*22*8 = 2112 ч.

Фпроф – годовые затраты времени на профилактические работы (принимаются 15 % от Ф),

Фпроф = 0,15*2112=316,8 ч.

Ф = 2112 – 316,8 = 1795,2 ч.

Рассчитаем годовые расходы:

Сэ = Сосн з/п+ Сдоп з/п + Сотч+ Сам + Срем + См + Сэл;

Основная заработная плата сотрудника, проводящего профилактические работы ЭВМ, составляет:

Сосн з/п = руб.

Дополнительная заработная плата сотрудника, проводящего профилактические работы ЭВМ, составляет:

Сдоп з/п = Сосн з/п * 12 % = 10350 * 0,12 = 1242 руб.

Сотч =0,26 * (Сосн з/п + Сдоп з/п) = 0,26 * (10350+1242) = 3013,92 руб.

Затраты на амортизацию определяются как сумма затрат на амортизацию ЭВМ и амортизацию ПО.

Сам = Апо + Аэвм

Затраты на амортизацию ЭВМ:

Cк = 25000 рублей – стоимость компьютера за одно рабочее место;

Максимальный срок полезного использования ЭВМ составляет 3 года.

Аэвм = = руб.

Затраты на амортизацию ПО:

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

Сам = 8333,33+0=8333,33 руб.

Затраты на ремонт и содержание оборудования составят 3% от стоимости ЭВМ:

Срем = Ск * 0,03 = 25000 * 0,03 = 750 руб.

Затраты на расходные материалы составят 1% от стоимости ЭВМ:

См = 0,01 * 25000 = 250 руб.

Расходы на электроэнергию составят:

Cэл = Фном * W * S, где

W = 0,45 кВт×ч – мощность, которую потребляет компьютер;

S = 2,28 руб. – стоимость 1 кВт/ч энергии.

Cэл = 2112* 0,45*2,28=2166,91 руб.

Тогда годовые расходы составят:

Сэ = 10350+1242+3013,92+8333,33+750+250+2166,91=26106,17 руб.

Отсюда стоимость одного машино-часа работы ЭВМ:

См.ч. = руб./ч.

Машинное время в часах Тмв:

Тмв = 880 ч.;

Стоимость отладки:

Сотл. = 880*16,16=14219,04 руб.

Расчет накладных расходов

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

Снакл = Сосн × 0,6 = 57500*1,2=34500 руб.

Себестоимость разработки

Себестоимость разработки программного продукта приведена в таблице 5.3.

Таблица 5.3– Себестоимость разработки программного продукта

Таким образом, себестоимость разработки программного продукта составляет 129 863,04 руб.

5.5 Расчет экономической эффективности внедрения продукта

Исходные данные для расчета годового экономического эффекта представлены в таблице 5. 4.

Таблица 5.4 – Исходные данные для расчета экономического эффекта

Показатели	Величина
Численность персонала, использующего программный продукт, (чел.)	1
Годовой фонд заработной платы на одного работника, использующего программный продукт, (руб.)	120000
Единовременные затраты на разработку программного продукта, (руб.)	129863,04
Затраты времени работника на выполнение работы до внедрения программного продукта, (%)	100
Затраты времени работника на выполнение работы после внедрения программного продукта, (%)	20
Отчисления на социальные нужды, (%)	26
Нормированный срок эксплуатации программного Продукта, (лет)	5

Для оценки эффективности проекта будут использоваться следующие показатели:

Прирост производительности труда;

Сравнительная экономия численности работников;

Годовая экономия по фонду заработной платы;

Годовая экономия по сборам на социальные нужды;

Годовой экономический эффект;

Фактический срок окупаемости.

Вычисления по показателям:

Определим прирост производительности труда:

Определим сравнительную экономию численности работников:

чел.

Рассчитаем годовую экономию по фонду заработной платы:

Найдем годовую экономию по отчислениям на социальные нужды:

Годовой экономический эффект составит:

Рассчитаем фактический срок окупаемости затрат:

1 год.

5.6 Вывод по разделу

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

В результате расчетов определена трудоемкость разработки программного продукта, которая составила 880 чел/ч., для выполнения данной разработки необходим 1 исполнитель. Сумма затрат на разработку программного продукта составляет 129 863,04 руб.

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

6 . Безопасность жизнедеятельности

Заключение

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

Результатом дипломного проектирования является разработанная система управления серверным программным обеспечением на базе программного комплекса Webmin/Alterator включающая в себя создание

первичного контроллера домена на базе программного комплекса Webmin;

почтового сервера на базе конфигуратора Alterator.

Разработанная система, включающая в себя практические разработки, позволяет:

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

повысить оперативность и объективность в работе с серверным программным обеспечением;

автоматизировать рутинные функции управления серверным программным обеспечением;

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

Список использованных источников

1. Стихановская Л.М., Семенова И.И. Методические указания по оформлению текстовых документов при выполнении дипломных, курсовых работ, отчетов и рефератов студентами факультета "информационные системы в управлении" - Омск: Изд-во СИБАДИ, 2010. - 35 с.

2. Осипов В.Г. Итоговая аттестация специалиста АСОИУ. Методические указания для студентов специальности 230102 «Автоматизированные системы обработки информации и управления» / В.Г. Осипов. - Омск: СибАДИ, 2008. - 27с.

3. Фролов А., Фролов Г. Практика применения PERL, PHP, APACHE и MySQL для активных WEB-сайтов. – Москва: Русская редакция, 2002. – 534 с.

4. Ричард Петерсен. LINUX: руководство по операционной системе. – Киев: BHV, 1998. – 1000 с.

5. Андрей Робачевский. Операционная система UNIX. – Спб: BHV-Санкт-Петербург,1997. – 500 с. Бедрина Е.А. Методические указания по выполнению раздела «Безопасность жизнедеятельности» в дипломных проектах выпускников СибАДИ всех специальностей факультета «Информационные системы в управлении» - Омск: СибАДИ, 2007. - 12 с.

6. СанПиН 2.2.2./2.41340-03. Гигиенические требования к персональным электронно-вычислительным машинам и организации работы.

7. СанПиН 2.2.4.548-96. Гигиенические требования к микроклимату производственных помещений.

8. ГОСТ 12.2.032-78 ССБТ. Рабочее место при выполнении работ сидя. Общие эргономические требования.

9. Девисилов В, Ильницкая А., Белов С. Безопасность жизнидеятельности - Высшая школа, 2009 г. - 616 с.

10. Кукин П. П., Лапин В. Л. , Пономарев Н. Л. , Сердюк Н. И. Безопасность жизнедеятельности. Безопасность технологических процессов и производств. Охрана труда - Высшая школа, 2007 г. - 336 с.

11. СанНиП 41-01-03. Отопление, вентиляция и кондиционирование.

12. ГОСТ 12.0.003 — 74 ССБТ. Опасные и вредные производственные факторы. Классификация.

13. ГОСТ 12.1.038-82 ЭЛЕКТРОБЕЗОПАСНОСТЬ . Предельно допустимые значения напряжений прикосновения и токов.

14. СанПиН 2.2.4.1294-03.Санитарно-гигиенические нормы допустимых уровней ионизации воздуха.

15. СанПиН 2.2.4.1191-03. Электромагнитные поля в производственных условиях.

16. ГОСТ 12.4.154—85. ССБТ. Устройства экранирующие для защиты от электрических полей промышленной частоты. Общие технические требования, основные параметры и размеры.

17. ГОСТ Р 50571.3-94. Требования по обеспечению безопасности. Защита от поражения электрическим током.

18. ГОСТ Р 50571.21-2000 Заземляющие устройства и системы уравнивания электрических потенциалов в электроустановках, содержащих оборудование обработки информации.

19. ГОСТ 12.0.003-74 (1999). ССБТ. Опасные и вредные производственные факторы. Классификации.

20. ГОСТ 12.1.002-84 (1999). ССБТ. Электрические поля промышленной частоты. Допустимые уровни напряженности и требования к проведению контроля на рабочих местах.

21. ГОСТ 12.1.004-91 ССБТ. Пожарная безопасность. Общие требования.

22. ГОСТ 12.2.2006-05. Безопасность аппаратуры электронной сетевой и сходных с ней устройств, предназначенных для бытового и аналогичного общего применения.

23. Колисниченко Д.Н. Linux-сервер своими руками. - Наука и техника, 2008 .- 624 с.

24. Таненбаум Э. Компьютерные сети. - Питер, 2007.- 992 с.

25. Samba - первичный контроллер домена [Электрон. ресурс] http://domaintimes.net/forum/showthread.php?t=3015

26. Документация сообщества к программному комплексу Nagios [Электрон. ресурс] http://wiki.nagios.org/index.php/Main_Page

Приложение А

Листинг файла smb.conf

# This is the main Samba configuration file. You should read the

# smb.conf(5) manual page in order to understand the options listed

# here. Samba has a huge number of configurable options (perhaps too

# many!) most of which are not shown in this example

#

# Any line which starts with a ; (semi-colon) or a # (hash)

# is a comment and is ignored. In this example we will use a #

# for commentry and a ; for parts of the config file that you

# may wish to enable

#

# NOTE: Whenever you modify this file you should run the command "testparm"

# to check that you have not made any basic syntactic errors.

#

#======================= Global Settings =====================================

[global]

# workgroup = Make sure it matches YOUR OWN NT-Domain-Name or Workgroup-Name

workgroup = workgroup

# server string is the equivalent of the NT Description field

server string = Samba Server

# This option is important for security. It allows you to restrict

# connections to machines which are on your local network. The

# following example restricts access to two C class networks and

# the "loopback" interface. For more examples of the syntax see

# the smb.conf man page

; hosts allow = 192.168.1. 192.168.2. 127.

# if you want to automatically load your printer list rather

# than setting them up individually then you'll need this

printcap name = /etc/printcap

load printers = yes

# It should not be necessary to spell out the print system type unless

# yours is non-standard. Currently supported print systems include:

# bsd, sysv, plp, lprng, aix, hpux, qnx

; printing = bsd

# Uncomment this if you want a guest account, you must add this to /etc/passwd

# otherwise the user "nobody" is used

; guest account = pcguest

# this tells Samba to use a separate log file for each machine

# that connects

log file = /var/log/samba/%m.log

# all log information in one file

# log file = /var/log/samba/smbd.log

# Put a capping on the size of the log files (in Kb).

max log size = 50

# Security mode. Most people will want user level security. See

# security_level.txt for details.

# Use password server option only with security = server

; password server = <NT-Server-Name>

# Password Level allows matching of _n_ characters of the password for

# all combinations of upper and lower case.

; password level = 8

; username level = 8

# You may wish to use password encryption. Please read

# ENCRYPTION.txt, Win95.txt and WinNT.txt in the Samba documentation.

# Do not enable this option unless you have read those documents

; encrypt passwords = yes

; smb passwd file = /etc/samba/smbpasswd

# The following are needed to allow password changing from Windows to

# update the Linux system password also.

# NOTE: Use these with 'encrypt passwords' and 'smb passwd file' above.

# NOTE2: You do NOT need these to allow workstations to change only

# the encrypted SMB passwords. They allow the Unix password

# to be kept in sync with the SMB password.

; unix password sync = Yes

; passwd program = /usr/bin/passwd %u

; passwd chat = *New*UNIX*password* %n\n *ReType*new*UNIX*password* %n\n *passwd:*all*authentication*tokens*updated*successfully*

# Unix users can map to different SMB User names

; username map = /etc/samba/smbusers

# Using the following line enables you to customise your configuration

# on a per machine basis. The %m gets replaced with the netbios name

# of the machine that is connecting

; include = /etc/samba/smb.conf.%m

# Most people will find that this option gives better performance.

# See speed.txt and the manual pages for details

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

# Configure Samba to use multiple interfaces

# If you have multiple network interfaces then you must list them

# here. See the man page for details.

; interfaces = 192.168.12.2/24 192.168.13.2/24

# Configure remote browse list synchronisation here

# request announcement to, or browse list sync from:

#a specific host or from / to a whole subnet (see below)

; remote browse sync = 192.168.3.25 192.168.5.255

# Cause this host to announce itself to local subnets here

; remote announce = 192.168.1.255 192.168.2.44

# Browser Control Options:

# set local master to no if you don't want Samba to become a master

# browser on your network. Otherwise the normal election rules apply

; local master = no

# OS Level determines the precedence of this server in master browser

# elections. The default value should be reasonable

; os level = 33

# Domain Master specifies Samba to be the Domain Master Browser. This

# allows Samba to collate browse lists between subnets. Don't use this

# if you already have a Windows NT domain controller doing this job

; domain master = yes

# Preferred Master causes Samba to force a local browser election on startup

# and gives it a slightly higher chance of winning the election

; preferred master = yes

# Enable this if you want Samba to be a domain logon server for

# Windows95 workstations.

; domain logons = yes

# if you enable domain logons then you may want a per-machine or

# per user logon script

# run a specific logon batch file per workstation (machine)

; logon script = %m.bat

# run a specific logon batch file per username

; logon script = %U.bat

# Where to store roving profiles (only for Win95 and WinNT)

# %L substitutes for this servers netbios name, %U is username

# You must uncomment the [Profiles] share below

; logon path = \\%L\Profiles\%U

# All NetBIOS names must be resolved to IP Addresses

# 'Name Resolve Order' allows the named resolution mechanism to be specified

# the default order is "host lmhosts wins bcast". "host" means use the unix

# system gethostbyname() function call that will use either /etc/hosts OR

# DNS or NIS depending on the settings of /etc/host.config, /etc/nsswitch.conf

# and the /etc/resolv.conf file. "host" therefore is system configuration

# dependant. This parameter is most often of use to prevent DNS lookups

# in order to resolve NetBIOS names to IP Addresses. Use with care!

# The example below excludes use of name resolution for machines that are NOT

# on the local network segment

# - OR - are not deliberately to be known via lmhosts or via WINS.

; name resolve order = wins lmhosts bcast

# Windows Internet Name Serving Support Section:

# WINS Support - Tells the NMBD component of Samba to enable it's WINS Server

; wins support = yes

# WINS Server - Tells the NMBD components of Samba to be a WINS Client

#Note: Samba can be either a WINS Server, or a WINS Client, but NOT both

; wins server = w.x.y.z

# WINS Proxy - Tells Samba to answer name resolution queries on

# behalf of a non WINS capable client, for this to work there must be

# at least oneWINS Server on the network. The default is NO.

; wins proxy = yes

# DNS Proxy - tells Samba whether or not to try to resolve NetBIOS names

# via DNS nslookups. The built-in default for versions 1.9.17 is yes,

# this has been changed in version 1.9.18 to no.

dns proxy = no

# Case Preservation can be handy - system default is _no_

# NOTE: These can be set on a per share basis

; preserve case = no

; short preserve case = no

# Default case is normally upper case for all DOS files

; default case = lower

# Be very careful with case sensitivity - it can break things!

; case sensitive = no

#============================ Share Definitions ==============================

idmap uid = 16777216-33554431

idmap gid = 16777216-33554431

template shell = /bin/false

username map = /etc/samba/smbusers

winbind use default domain = no

[homes]

comment = Home Directories

browseable = no

writeable = yes

# Un-comment the following and create the netlogon directory for Domain Logons

; [netlogon]

; comment = Network Logon Service

; path = /home/netlogon

; guest ok = yes

; writable = no

; share modes = no

# Un-comment the following to provide a specific roving profile share

# the default is to use the user's home directory

;[Profiles]

; path = /home/profiles

; browseable = no

; guest ok = yes

# NOTE: If you have a BSD-style print system there is no need to

# specifically define each individual printer

[printers]

comment = All Printers

path = /var/spool/samba

browseable = no

# Set public = yes to allow user 'guest account' to print

printable = yes

# This one is useful for people to share files

;[tmp]

; comment = Temporary file space

; path = /tmp

; read only = no

; public = yes

# A publicly accessible directory, but read only, except for people in

# the "staff" group

;[public]

; comment = Public Stuff

; path = /home/samba

; public = yes

; read only = yes

; write list = @staff

# Other examples.

#

# A private printer, usable only by fred. Spool data will be placed in fred's

# home directory. Note that fred must have write access to the spool directory,

# wherever it is.

;[fredsprn]

; comment = Fred's Printer

; valid users = fred

; path = /homes/fred

; printer = freds_printer

; public = no

; writable = no

; printable = yes

# A private directory, usable only by fred. Note that fred requires write

# access to the directory.

;[fredsdir]

; comment = Fred's Service

; path = /usr/somewhere/private

; valid users = fred

; public = no

; writable = yes

; printable = no

# a service which has a different directory for each machine that connects

# this allows you to tailor configurations to incoming machines. You could

# also use the %u option to tailor it by user name.

# The %m gets replaced with the machine name that is connecting.

;[pchome]

; comment = PC Directories

; path = /usr/pc/%m

; public = no

; writable = yes

# A publicly accessible directory, read/write to all users. Note that all files

# created in the directory by users will be owned by the default user, so

# any user with access can delete any other user's files. Obviously this

# directory must be writable by the default user. Another user could of course

# be specified, in which case all files would be owned by that user instead.

;[public]

; path = /usr/somewhere/else/public

; public = yes

; only guest = yes

; writable = yes

; printable = no

# The following two entries demonstrate how to share a directory so that two

# users can place files there that will be owned by the specific users. In this

# setup, the directory should be writable by both users and should have the

# sticky bit set on it to prevent abuse. Obviously this could be extended to

# as many users as required.

;[myshare]

; comment = Mary's and Fred's stuff

; path = /usr/somewhere/shared

; valid users = mary fred

; public = no

; writable = yes

; printable = no

; create mask = 0765