Державна освітня установа вищої професійної освіти
«Сибірська державна автомобільно-дорожня академія (СібАДІ) »
Факультет Інформаційні системи в управлінні
Спеціальність Автоматизовані системи обробки інформації та управління
Кафедра Комп'ютерні інформаційні автоматизовані системи
ПОЯСНЮВАЛЬНА ЗАПИСКА
до дипломного проекту
Позначення проекту ДП-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 - платна панель управління веб-хостингом. Функціонує допомогою окремої копії веб-сервера, що працює, як правило, на порту 2 082 (або 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
Поле | Розмір (байти) | Опис |
0xFF 'SMB' | 1 | Ідентифікатор протоколу |
COM | 1 | Код команди, від 0x00 до 0xFF |
RCLS | 1 | Клас помилки |
REH | 1 | Зарезервований |
ERR | 2 | Код помилки |
REB | 1 | Зарезервований |
RES | 14 | Зарезервований |
TID | 2 | ID Дерева; унікальне ID для ресурсу, ісп. клієнтом |
PID | 2 | ID викликаючий процес |
UID | 2 | Ідентифікатор користувача |
MID | 2 | Мультиплексний ID; використовуваний для передачі запитів всередині процесу |
Формат команди SMB
Після того, як заголовок представлений певною кількістю байт, відбувається виконання команди SMB. Будь-яка команда, наприклад така, як відкрити файл (ID поля COM: SMBopen) або отримати запит на друк (SMBsplretq), має свій набір параметрів і дані. Як і в полі заголовка SMB, тут також можуть бути заповнені не всі командні поля, все залежить від команди. Наприклад, команда GetServerAttributes (SMBdskattr) встановлює поля WCT BCC в 0. Поля командних сегментів показані в Таблиці 3.2.
Таблиця 3.2 - Зміст команди SMB
Поле | Розмір в байтах | Опис |
WCT | 1 | Лічильник слів |
VWV | Мінлива | Параметр слів (розмір, який визначається WCT) |
BCC | 2 | Параметр лічильника байт |
DATA | Мінлива | Дані (розмір, який визначається BCC) |
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-Оцінка трудомісткості окремих з усіх видів робіт
Вид робіт | Оцінка трудомісткості | Розрахункові величини | ||
а (ч.) | b (ч.) | t (осіб / год) | D | |
1. Вивчення та аналіз предметної області | 120 | 150 | 132 | 6 |
2. Вивчення структури серверів | 180 | 200 | 188 | 4 |
3. Вивчення алгоритму віддаленого управління | 180 | 200 | 188 | 4 |
4. Розгортання системи | 220 | 250 | 232 | 6 |
5. Налагодження | 50 | 70 | 58 | 4 |
6. Підготовка документації | 70 | 100 | 82 | 6 |
Підсумок: | ||||
820 | 970 | 880 | 12,49 |
Загальна трудомісткість роботи становить 880 людино-годин або 5 місяців (по 22 робочих дні в кожному місяці). Стандартне відхилення складає менше 5%, тобто ступінь вірогідності того, що робота буде виконана в строк, велика.
5.3 Визначення чисельності виконавців
Період розробки програми - 5 місяців, з 1 січня по 1 червня 2010 року.
Кількість робочих днів у кожному місяці дорівнює 22. Робочий день дорівнює 8 години. Звідси отримуємо дійсний фонд часу за період розробки програми:
ч.
Чисельність виконавців, необхідна для виконання робіт визначається як відношення трудомісткості всієї розробки до дійсного фонду часу за весь період розробки програми.
Таким чином, отримуємо:
чол.
Звідси випливає, що розробником буде один виконавець - технік.
У таблиці 5.2 представлено розподіл трудомісткості за стадіями розробки і виконавцям.
Таблиця 5.2 - Розподіл трудомісткості за стадіями розробки
Вид роботи | Трудомісткість етапу, ч. | Посада виконавця |
1. Вивчення та аналіз предметної області | 64 | Технік |
2. Вивчення структури БД | 44 | Технік |
3.Изучение алгоритму | 49 | Технік |
4. Розгортання системи | 220 | Технік |
5. Налагодження | 71 | Технік |
6. Підготовка документації | 88 | Технік |
Разом: | 536 |
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 = одна тисяча двісті сорок два руб.
Сотч = 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 = 57 500 * 1,2 = 34500 руб.
Собівартість розробки
Собівартість розробки програмного продукту наведена у таблиці 5.3.
Таблиця 5.3-Собівартість розробки програмного продукту
Витрати на розробку та впровадження системи
Стаття витрат
Сума
Основна заробітна плата розробника
57500,00
Додаткова заробітна плата розробника
6900,00
Збір на соціальні потреби
16744,00
Витрати по налагодженню програмного продукту
14219,04
Накладні витрати
34500,00
Підсумок:
129863,04
Таким чином, собівартість розробки програмного продукту становить 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.
Розроблена система, що включає в себе практичні розробки, дозволяє:
піти від необхідності пошуку потрібних параметрів у конфігураційних файлах, використовувати зручний інтерфейс;
підвищити оперативність і об'єктивність у роботі з серверним програмним забезпеченням;
автоматизувати рутинні функції управління серверним програмним забезпеченням;
створити умови для швидкого і надійного усунення помилок і збоїв у роботі програмної частини мережі.
Список використаних джерел
Стіхановская Л.М., Семенова І.І. Методичні вказівки по оформленню текстових документів при виконанні дипломних, курсових робіт, звітів і рефератів студентами факультету "інформаційні системи в управлінні" - Омськ: Изд-во СібАДІ, 2010. - 35 с.
Осипов В.Г. Підсумкова атестація фахівця АСОІУ. Методичні вказівки для студентів спеціальності 230102 «Автоматизовані системи обробки інформації та управління» / В.Г. Осипов. - Омськ: СібАДІ, 2008. - 27с.
Фролов А., Фролов Р. Практика застосування PERL, PHP, APACHE і MySQL для активних WEB-сайтів. - Москва: Російська редакція, 2002. - 534 с.
Річард Петерсен. LINUX: керівництво по операційній системі. - Київ: BHV, 1998. - 1000 с.
Андрій Робачевскій. Операційна система UNIX. - Спб: BHV-Санкт-Петербург, 1997. - 500 с. Бедрин Є.А. Методичні вказівки щодо виконання розділу «Безпека життєдіяльності» у дипломних проектах випускників СібАДІ всіх спеціальностей факультету «Інформаційні системи в управлінні» - Омськ: СібАДІ, 2007. - 12 с.
СанПіН 2.2.2./2.41340-03. Гігієнічні вимоги до персональних електронно-обчислювальних машин та організації роботи.
СанПіН 2.2.4.548-96. Гігієнічні вимоги до мікроклімату виробничих приміщень.
ГОСТ 12.2.032-78 ССБТ. Робоче місце при виконанні робіт сидячи. Загальні ергономічні вимоги.
Девісілов В, Ільницька А., Белов С. Безпека життєдіяльності - Вища школа, 2009 р. - 616 с.
Кукін П. П., Лапін В. Л., Пономарьов М. Л., Сердюк Н. І. Безпека життєдіяльності. Безпека технологічних процесів і виробництв. Охорона праці - Вища школа, 2007 р. - 336 с.
СанНіП 41-01-03. Опалення, вентиляція і кондиціонування.
ГОСТ 12.0.003 - 74 ССБТ. Небезпечні і шкідливі виробничі фактори. Класифікація.
ГОСТ 12.1.038-82 ЕЛЕКТРОБЕЗПЕКА. Гранично допустимі значення напруг дотику і струмів.
СанПіН 2.2.4.1294-03.Санітарно-гігієнічні норми допустимих рівнів іонізації повітря.
СанПіН 2.2.4.1191-03. Електромагнітні поля у виробничих умовах.
ГОСТ 12.4.154-85. ССБТ. Пристрої екранують для захисту від електричних полів промислової частоти. Загальні технічні вимоги, основні параметри і розміри.
ГОСТ Р 50571.3-94. Вимоги щодо забезпечення безпеки. Захист від ураження електричним струмом.
ГОСТ Р 50571.21-2000 Заземлюючі пристрої та системи зрівнювання електричних потенціалів в електроустановках, що містять обладнання обробки інформації.
ГОСТ 12.0.003-74 (1999). ССБТ. Небезпечні і шкідливі виробничі фактори. Класифікації.
ГОСТ 12.1.002-84 (1999). ССБТ. Електричні поля промислової частоти. Допустимі рівні напруженості і вимоги до проведення контролю на робочих місцях.
ГОСТ 12.1.004-91 ССБТ. Пожежна безпека. Загальні вимоги.
ГОСТ 12.2.2006-05. Безпека апаратури електронної мережевої і подібних з нею пристроїв, призначених для побутового та аналогічного загального застосування.
Колісниченко Д.М. Linux-сервер своїми руками. - Наука і техніка, 2008 .- 624 с.
Таненбаум Е. Комп'ютерні мережі. - Пітер, 2007 .- 992 с.
Samba - первинний контролер домену [Електрон. ресурс] http://domaintimes.net/forum/showthread.php?t=3015
Документація спільноти до програмного комплексу 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 = wxyz
# 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