Програмна реалізація менеджера процесів як компоненти системи графічного адміністрування Ajenti

ВИПУСКНА КВАЛІФІКАЦІЙНА РОБОТА БАКАЛАВРА

Програмна реалізація менеджера процесів як компоненти системи графічного адміністрування Ajenti

ЗМІСТ

• Перелік умовних скорочень
• Вступ
• 1 Аналіз предметної галузі
• 1.1 Структура ядра gnu/linux
• 1.2 Процеси в ос gnu/linux
• 1.2.1 Створення процесу
• 1.2.2 Переривання процесів
• 1.2.3 Здійснення сигналів процесами
• 1.3 Опис мови програмування python
• 1.4 Огляд веб-орієнтованих систем віддаленого адміністрування для linux
• 1.5 Постановка задачі
• 2 Проектування та реалізація
• 2.1 Відомості про середовище розробки
• 3 Опис програмної реалізації
• 4 Аналіз дослідної експлуатації
• Висновки

ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ

OC — Операційна система ПЗ — Програмне забезпечення ОЗП — Оперативно запам’ятовувальний пристрій

ISO — International Standartisation Organisation — Міжнародна організація стандартизації

DOM — Document object model — Об'єктна модель документа

AJAX — Asynchronous Javascript and XML — асинхронный JavaScript и XML

XSLT — eXtensible Stylesheet Language Transformations — мова перетворення XML-документів

GUI — Graphical user interface — графічний користувальницький інтерфейс

DD-WRT — вільна безкоштовна прошивка для багатьох бездротових маршрутизаторів

ВСТУП Засоби мережного і системного адміністрування ніколи не займали домінуючих позицій у корпоративних інформаційних системах. Традиційно допоміжна роль, що їм відводилась, призвела до того, що структура і функції ПЗ даного класу виявилися в прямої залежності від архітектури обчислювальних систем і еволюціонували разом із ними.

Тим часом корпоративні користувачі інформаційних технологій поступово усвідомлюють, яке значення відіграє адміністрування для бізнес-процесів. Цей факт, з одного боку, змушує суворіше ставитися до формулювання критеріїв, котрим повинне відповідати керуюче ПЗ, а з іншого, дозволяє припустити, що вже незабаром йому може бути відведене більш почесне місце в структурі інформаційної системи.

Щодо самого адміністрування то функціональна область управління, що відносяться до цієї сфери, чітко визначені в специфікаціях ISO [1]:

— рішення проблемних ситуацій (діагностика, локалізація й усунення несправностей, реєстрація помилок, тестування);

— управління ресурсами (врахування, контроль використання ресурсів, виставляння рахунків за використані ресурси й обмеження доступу до них);

— управління конфігурацією, спрямоване на забезпечення надійного й ефективного функціонування всіх компонентів інформаційної системи;

— контроль продуктивності (збір і аналіз інформації про роботу окремих ресурсів, прогнозування ступеню задоволення потреб користувачів/додатків, заходи для збільшення продуктивності);

— захист даних (управління доступом користувачів до ресурсів, забезпечення цілісності даних і управління їхнім шифруванням).

Віддалене адміністрування відіграє значну роль серед інших сфер адміністрування. Багато часу та грошей витрачаються на доставку послуг адміністрування до місця знаходження обладнання, ця проблема гарно вирішується за допомогою віддаленого адміністрування обладнання. Так наприклад якщо ви орендували сервер в Австралії а живете в Україні то вам не потрібно нікуди їхати, бо за допомогою таких програмних продуктів, які забезпечують керування віддаленим робочим столом, або керування через web-сторінку ви маєте змогу керувати обладнанням так, наче воно біля вас. Таким чином теперішні адміністратори не мають прив’язки до якогось конкретного місця роботи бо за допомогою інструментів віддаленого доступу вони можуть безпосередньо зі свого домашнього комп’ютера отримати доступ до свого робочого місця, а звідти і виконувати свої функції.

На даний момент системи віддаленого web-орієнтованого адміністрування мають широкий попит. Головною перевагою цієї галузі програм є відсутність необхідності мати допоміжне ПЗ на комп’ютері з якого відбувається робота адміністратора. Класичним прикладом такої програми є програма RamoteApp, яка включена до базового пакету в ОС Windows починаючи з XP, в ній для того щоб підключитись до віддаленого робочого стола, необхідно щоб ця програма також була встановлена і на комп’ютері, який ініціює підключення.

Тому розробка для пакету віддаленого адміністрування Ajenti[2], що керує процесами у віддаленій ОС є актуальною. Так як такий модуль допоможе знизити вимоги до кваліфікації користувача що керує або слідкує за процесами в системі.

1 АНАЛІЗ ПРЕДМЕТНОЇ ГАЛУЗІ

1.1 Структура ядра GNU/Linux

Оскільки система GNU/Linux є представником виду Unix-подібних ОС то основні віхи, такі як структура ядра у них однакові. GNU/Linux легше за все уявити у вигляді двох рівнів (див. рис. 1.1). Першим є ядро. Воно безпосередньо взаємодіє з залізом та забезпечує переносимість всього іншого ПЗ на комп’ютери з різним апаратним забезпеченням. Ядро надає програмам певний набір системних API за допомогою яких виконується створення процесів керування ними та взаємодія і синхронізація, а також файловий ввід/вивід. Другим рівнем є програмне забезпечення прикладне чи системне: командний інтерпретатор, графічний інтерфейс тощо.

Рисунок 1.1 — Cхема структури ОС GNU/Linux

Зазирнемо глибше до ядра системи. Воно дозволяє всім іншим програмам спілкуватися з перефірійними пристроями, регулює доступ до файлів, керує пам’яттю і процесами. Ядро — це зв’язковий, до якого звертаються за допомогою системних викликів (викликаючи якусь послугу). Зв’язок не односторонній: ядро може и повертати у випадку необхідності якісь дані. Головною перевагою ядра є сувора стандартизація системних API. За рахунок цього багато в чому досягається переносимість коду між різними версіями GNU/ Linux і абсолютно різним апаратним забезпеченням див. рис. 1.2.

Маю відмітити те, що ядро системи Linux є динамічним, тобто підтримує такі функції як додавання та видалення програмних компонентів без зупинення системи. Ці компоненти мають назву динамічно завантажувані модулі ядра. Їх можна вводити в систему про необхідності, як під час завантаження (якщо знайдено нове обладнання для якого необхідний такий модуль), так і в будь який момент часу за бажанням користувача.

Рисунок 1.2 — Структура ядра GNU/Linux

Усі звернення до ядра системи можна розділити на дві категорії: програма викликає підсистему управління файлами або підсистему управління процесами. Перша відповідає за все, що пов’язано з файлами: управління, розміщення, доступ. Процеси ж — це, в загальному випадку, будь-які запущені програми. Тому підсистема управління процесами служить для їх життєздатності, синхронізації і управління.

Важливо також і те, що файлова підсистема і підсистема управління процесів можуть спілкуватися одна з одною: будь-який процес може викликати системні API для роботи з файлами. Принадність GNU/Linux полягає в тому, що ці API універсальні (та й в Windows спостерігається та ж картина). Ось найголовніші з них: open, close, read, write, stat, chown, chmod (суть майже всіх викликів інтуїтивно зрозуміла з назви, окрім, хіба що, останніх трьох, тому поясню — вони служать для управління атрибутами файлів, інформації про власника і прав доступу) тощо.

Більш докладно розглянемо підсистему управління процесами. Вона відповідає за синхронізацію та взаємодія процесів, розподіл пам’яті і планування виконання процесів. Для всіх цих цілей в підсистему управління процесами включені три модулі, які наочно продемонстровано на схемі. Гарним прикладом взаємодії підсистем управління файлами і процесами є завантаження файлу на виконання. У цьому випадку підсистемі управління процесів потрібно звернутися до колеги, щоб вважати виконувані файли.

Трохи вище я перерахував системні API для керування файлами. Тепер розглянемо виклики, служб для роботи з процесами: fork (створює новий процес), exec (виконує процес), exit (завершує виконання процесу), wait (один із способів синхронізації), brk (управляє пам’яттю, виділеного процесу), signal (обробники вийнятових ситуацій) тощо. На рисунку 1.3 зображена структура роботи будь якого процесу в операційній системі GNU/Linux.

Наступні два модулі є дуже важливими в розумінні всієї підсистеми управління процесами. Перший — модуль розподілу пам’яті, дозволяє уникнути брак оперативної пам’яті. Хоча механізм свопінгу і файлів підкачки (або його ще називають віртуальною пам’яттю) вже ні для кого не секрет, в тіні залишається інший факт: операційна система (в особі описуваної підсистеми) може або скидати всі дані, які стосуються конкретного процесу, на диск, або скидати сторінки пам’яті (сторінкове заміщення). Таким чином, модуль розподілу пам’яті виконує дуже важливу функцію — він визначає якому процесу скільки виділити пам’яті.

Віртуальна пам’ять була винайдена в 1962 році, в Англії при створенні суперкомп’ютера Atlas. У більшості сучасних комп’ютерів оперативна пам’ять менша, ніж адресний простір що використовується процесором. Розмір ОЗП типового персонального комп’ютера варіюється від десятків до тисяч мегабайт. При запуску програма завантажується з будь-якого накопичувача в оперативну пам’ять. Якщо ж програма не поміщається в ОЗП, то ті її частини, які в даний момент не виконуються, зберігаються у вторинному запам’ятовуючому пристрої, найчастіше вінчестері, і така пам’ять називається віртуальною. Безумовно, перед виконанням необхідна частина програми повинна бути переміщена в оперативну пам’ять. Дані функції виконує ядро ОС, а саме диспетчер віртуальної пам’яті, що у мікроядрі. І для програми і для користувача ці дії прозорі. Природно, на запити до віртуальної пам’яті йде набагато більший час, ніж до ОЗП.

Рисунок 1.3 — Структура роботи будь якого процесу в операційній системі GNU/Linux

Другий модуль — планувальник. Його завдання не менш важлива. GNU/ Linux — багатозадачна ОС, тобто одночасно може виконуватися безліч процесів. Ми, однак, знаємо, що у фіксований момент часу на одному процесорі може виконуватися тільки одна команда. Саме тому потрібен віртуальний рефері, який буде визначати, якому процесу виконуватися зараз, а якому — через секунду. На практиці ж планувальник переключає контекст, тобто перед тим, як зупинити виконання якогось процесу, він запам’ятовує стан регістрів, пам’яті і т. д., а вже після цього запускає інший процес у його власному адресному просторі. І ще один тонкий момент: кожний запущений процес «думає», що він єдиний. Додатково існує механізм пріоритетів. Очевидно, чим вищий пріоритет, тим швидше почне виконуватися процес. Процеси можуть також обмінюватися між собою інформацією. У разі їх синхронного взаємодії синхронізацію здійснює модуль взаємодії (наприклад, функція wait).

Останнім але не менш важливим рівнем є рівень апаратного контролю. На даному рівні відбувається обробка переривань і зв’язок ядра з апаратною складовою комп’ютера. Тут слід зазначити лише пару моментів, по-перше, переривання можуть «переривати» роботу процесора і вимагати уваги до себе (після цього процесор без проблем повертається до виконання надісланих процесів), а, по-друге, обробку переривань здійснюють спеціальні функції ядра.

Що таке процес? Розберемося спочатку з визначенням терміну «процес». Так що ж він представляє собою з боку ОС? Для того щоб відповісти на це питання, розглянемо загальний алгоритм створення будь-якої програми. Припустимо, що ти написав програму на якомусь популярному мовою програмування (наприклад, C++). Для того щоб забезпечити її виконання у певній операційній системі, тобі необхідно її скомпілювати, скориставшись компілятором для даної ОС (наприклад, gcc). Потім у тебе виходить остаточний продукт, званий «виконуваним кодом». Власне, це і є програма, яка може бути запущена в ОС. Щоб вона могла бути виконана, її потрібно завантажити в оперативну пам’ять, визначити апаратні компоненти, забезпечити місце на жорсткому диску і т.д. — Загалом, виділити необхідні системні ресурси. Так ось, сукупність цих ресурсів для певної програми і називається — процесом. У багатозадачній системі, як відомо, можуть виконуватися відразу кілька програм, і якщо кожна буде намагатися хаотично забрати якомога більше ресурсів без будь-якого контролю, то невідомо, до чого це може призвести, а так, за допомогою створення процесу для кожної програми, ОС здатна контролювати її звернення до ресурсів системи. У підсумку виходить, що процес — це деякий абстрактний об'єкт, що є частиною ОС, який представляє собою образ виконуваної програми, написаної на якійсь мові програмування. Функції щодо забезпечення контролю над процесами і бере на себе одна з підсистем ОС. Розглянемо її основні функції.

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

Також підсистема управління процесами бере на себе такі обов’язки:

— розподіл фізичної пам’яті між процесами;

— здійснення доступу процесів до системних ресурсів (файлам, принтеру, модему і т.д.);

— захист адресного простору процесу та інших виділених ресурсів від посягань з боку інших процесів;

— у разі необхідності, вміння організувати канал взаємодії між процесами;

— оптимізація роботи планувальника.

1.2 Процеси в ОС GNU/Linux

1.2.1 Створення процесу

Єдиним способом створення користувачем нового процесу в операційній системі GNU/Linux є виконання системної функції fork. Процес, що викликає функцію fork, називається батьківським (процес-батько), новостворюваний процес називається породжених (процес-нащадок). Синтаксис виклику функції fork:

pid = fork ();

В результаті виконання функції fork користувальницький контекст і того, й іншого процесів збігається у всьому, крім повертається змінної pid. Для батьківського процесу в pid повертається ідентифікатор породженого процесу, для породженого — pid має нульове значення. Нульовий процес, що виникає всередині ядра при завантаженні системи, є єдиним процесом, не створюваним за допомогою функції fork.

У ході виконання функції fork ядро?? виконує наступну послідовність дій:

1. Відводить місце в таблиці процесів під новий процес;

2. присвоює породжуваному процесу унікальний код ідентифікації;

3. робить логічну копію контексту батьківського процесу. Оскільки ті чи інші складові процесу, такі як область команд, можуть розділятися іншими процесами, ядро?? може іноді замість копіювання області в новий фізичний ділянку пам’яті просто збільшити значення лічильника посилань на область;

4. збільшує значення лічильника числа файлів, пов’язаних з процесом, як у таблиці файлів, так і в таблиці індексів;

5. повертає батьківського процесу код ідентифікації породженого процесу, а породженому процесу — нульове значення.

Реалізацію системної функції fork, мабуть, не можна назвати тривіальною, так як породжений процес починає своє виконання, виникаючи як би з повітря. Алгоритм реалізації функції для систем із заміщенням сторінок за запитом та для систем з підкачкою процесів має лише незначні відмінності; все викладене нижче щодо цього алгоритму стосується в першу чергу традиційних систем з підкачкою процесів, але з неодмінним акцентуванням уваги на тих моментах, які в системах із заміщенням сторінок за запитом реалізуються інакше. Крім того, звичайно, передбачається, що в системі є вільна оперативна пам’ять, достатня для розміщення породженого процесу. У розділі 9 буде окремо розглянуто випадок, коли для породженого процесу не вистачає пам’яті, і там же будуть дані роз’яснення щодо реалізації алгоритму fork в системах із заміщенням сторінок.

При створенні процесу спочатку ядро?? повинно упевнитися в тому, що для успішного виконання алгоритму fork є всі необхідні ресурси. У системі з підкачкою процесів для розміщення породжуваного процесу потрібно місце або в пам’яті, або на диску; в системі з заміщенням сторінок слід виділити пам’ять для допоміжних таблиць (зокрема, таблиць сторінок). Якщо вільних ресурсів немає, алгоритм fork завершується невдало. Ядро шукає місце в таблиці процесів для конструювання контексту породжуваного процесу і перевіряє, чи не перевищив користувач, виконує fork, обмеження на максимально-допустима кількість паралельно запущених процесів. Ядро також підбирає для нового процесу унікальний ідентифікатор, значення якого перевищує на одиницю максимальний з існуючих ідентифікаторів. Якщо запропонований ідентифікатор вже присвоєний іншому процесу, ядро обирає ідентифікатор, наступний за порядковим номером. Як тільки буде досягнуто максимально-допустиме значення, відлік ідентифікаторів знову почнеться з 0. Оскільки більшість процесів має короткий час життя, при переході до початку відліку значна частина ідентифікаторів виявляється вільною.

На кількість процесів, що одночасно виконуються накладається обмеження (вони можуть бути змінені в конфігах системи), жоден з користувачів не може займати в таблиці процесів занадто багато місця, заважаючи тим самим іншим користувачам створювати нові процеси. Крім того, простим користувачам не дозволяється створювати процес, що займає останнє вільне місце в таблиці процесів, в іншому випадку система зайшла б у глухий кут. Іншими словами, оскільки в таблиці процесів немає вільного місця, то ядро не може гарантувати, що всі існуючі процеси завершаться природним чином, тому нові процеси створюватися не будуть. З іншого боку, суперкористувачеві потрібно дати можливість виконувати стільки процесів, скільки йому потрібно, звичайно, враховуючи розмір таблиці процесів, при цьому процес, що виконується суперкористувачем, може зайняти в таблиці і останнє вільне місце. Передбачається, що суперкористувач може вдаватися до рішучих заходів і запускати процес, що спонукає інші процеси до завершення, якщо це викликається необхідністю.

Потім ядро привласнює початкові значення різним полям запису таблиці процесів, відповідної породженому процесу, копіюючи в них значення полів із запису батьківського процесу. Наприклад, породжений процес «успадковує» у батьківського процесу коди ідентифікації користувача (реальний і той, під яким виповнюється процес), групу процесів, керовану батьківським процесом, а також значення, задане батьківським процесом у функції nice і використовується при обчисленні пріоритету планування. У наступних розділах ми поговоримо про призначення цих полів. Ядро передає значення поля ідентифікатора батьківського процесу до запису породженого, включаючи останній в деревоподібну структуру процесів, і присвоює початкові значення різними параметрами планування, таким як пріоритет планування, використання ресурсів центрального процесора й інші значення полів синхронізації. Початковим станом процесу є стан «створення» див. рис. 1.3.

Наступною дією ядро встановлює значення лічильників посилань на файли, з якими автоматично зв’язується породжуваний процес. По-перше, породжений процес розміщується в поточному каталозі батьківського процесу. Число процесів, що звертаються в даний момент до каталогу, збільшується на 1 і, відповідно, збільшується значення лічильника посилань на його індекс. По-друге, якщо батьківський процес або один з його предків вже виконував зміну кореневого каталогу з допомогою функції chroot, породжений процес успадковує і новий корінь з відповідним збільшенням значення лічильника посилань на індекс кореня. Нарешті, ядро переглядає таблицю користувальницьких дескрипторів для батьківського процесу в пошуках відкритих файлів, відомих процесу, і збільшує значення лічильника посилань, асоційованого з кожним з відкритих файлів, у глобальній таблиці файлів. Породжений процес не просто успадковує права доступу до відкритих файлів, але і розділяє доступ до файлів з батьківським процесом, тому що обидва процеси звертаються в таблиці файлів до одних і тих же записів. Дія fork щодо відкритих файлів подібно до дії алгоритму dup: новий запис в таблиці користувацьких дескрипторів файлу вказує на запис в глобальній таблиці файлів, відповідну відкритого файлу. Для dup, однак, записи в таблиці користувацьких дескрипторів файлу відносяться до одного процесу; для fork — до різних процесів.

Після завершення всіх цих дій ядро готове до створення для породженого процесу користувацького контексту. Ядро виділяє пам’ять для адресного простору процесу, його областей і таблиць сторінок, створює за допомогою алгоритму dupreg копії всіх областей батьківського процесу і приєднує за допомогою алгоритму attachreg кожну область до породженому процесу. У системі з підкачкою процесів ядро копіює вміст областей, які не є областями розділяється пам’яті, в нову зону оперативної пам’яті. Згадаймо про те, що в просторі процесу зберігається покажчик на відповідний запис у таблиці процесів. За винятком цього поля, в усьому іншому вміст адресного простору породженого процесу на початку збігається з вмістом простору батьківського процесу, але може розходитися після завершення алгоритму fork. Батьківський процес, наприклад, після виконання fork може відкрити новий файл, до якого породжений процес вже не отримає доступ автоматично.

Отже, ядро закінчило створення статичної частини контексту породженого процесу див. рис. 1.4; тепер воно приступає до створення динамічної частини. Ядро копіює в неї перший контекстний рівень батьківського процесу, що включає в себе збережений регістровий контекст завдання і стек ядра в момент виклику функції fork. Якщо в даній реалізації стек ядра є частиною простору процесу, ядро в момент створення простору породженого процесу автоматично створює і системний стек для нього. В іншому випадку батьківського процесу доведеться скопіювати в простір пам’яті, асоційоване з породженим процесом, свій системний стек. У будь-якому випадку стек ядра для породженого процесу збігається із системним стеком його батька. Далі ядро створює для породженого процесу фіктивний контекстний рівень (2), в якому міститься збережений регістровий контекст з першого контекстного рівня. Значення лічильника команд (регістр PC) та інших регістрів, які зберігаються в регістровому контексті, встановлюються таким чином, щоб з їх допомогою можна було «відновлювати» контекст породженого процесу, нехай навіть останній ще жодного разу не виконувався, і щоб цей процес при запуску завжди пам’ятав про те, що він породжений. Наприклад, якщо програма ядра перевіряє значення, що зберігається в регістрі 0, для того, щоб з’ясувати, чи є даний процес батьківським або ж породженим, то це значення переписується в регістровий контекст породженого процесу, збережений у складі першого рівня. Механізм збереження використовується той же, що і при перемиканні контексту.

Рисунок 1.4 — Створення контексту нового процесу при виконанні функції fork

Якщо контекст породженого процесу готовий, батьківський процес завершує свою роль у виконанні алгоритму fork, переводячи породжений процес в стан «готовності до запуску, перебуваючи в пам’яті» та повертаючи користувачеві його ідентифікатор. Потім, використовуючи звичайний алгоритм планування, ядро?? вибирає породжений процес для виконання і той «дограє» свою роль в алгоритмі fork. Контекст породженого процесу був заданий батьківським процесом; з точки зору ядра здається, що породжений процес відновлюється після призупинив в очікуванні ресурсу. Породжений процес при виконанні функції fork реалізує ту частину програми, на яку вказує лічильник команд, відновлюваний ядром з збереженого на рівні 2 реєстрового контексту, і по виході з функції повертає нульове значення.

На рисунку 1.4 представлена?? логічна схема взаємодії батьківського і породженого процесів з іншими структурами даних ядра відразу після завершення системної функції fork. Отже, обидва процеси спільно користуються файлами, які були відкриті батьківським процесом до моменту виконання функції fork, при цьому значення лічильника посилань на кожен з цих файлів у таблиці файлів на одиницю більше, ніж до виклику функції. Породжений процес має ті ж, що й батьківський процес, поточний і кореневої каталоги, значення ж лічильника посилань на індекс кожного з цих каталогів так само стає на одиницю більше, ніж до виклику функції. Вміст областей команд, даних і стека (завдання) в обох процесів збігається; за типом області і версії системної реалізації можна встановити, чи можуть процеси розділяти саму область команд у фізичних адресах.

Батьківський і породжений процеси незалежно один від одного, звичайно, викликають функцію rdwrt і в циклі зчитують по одному байту інформацію з вихідного файлу і переписують її в файл виводу. Функція rdwrt повертає управління, коли при зчитуванні виявляється кінець файлу. Ядро перед тим вже збільшило значення лічильників посилань на вихідний і результуючий файли в таблиці файлів, і дескриптори, які використовуються в обох процесах, адресують до одних і тих же рядках у таблиці. Таким чином, дескриптори fdrd в тому і в іншому процесах вказують на запис в таблиці файлів, відповідну вихідного файлу, а дескриптори, підставляються в якості fdwt, — на запис, що відповідає результуючому файлу (файлу виводу). Тому обидва процеси ніколи не звернуться разом на читання або запис до одного й того ж адресою, обчислюваному за допомогою зміщення всередині файлу, оскільки ядро зміщує внутріфайловие покажчики після кожної операції читання або запису. Незважаючи на те, що, здавалося б, із-за того, що процеси розподіляють між собою робоче навантаження, вони копіюють вихідний файл в два рази швидше, вміст результуючого файлу залежить від черговості, в якій ядро запускає процеси. Якщо ядро запускає процеси так, що вони виконують системні функції поперемінно (чергуючи і спарені виклики функцій read-write), вміст результуючого файлу буде збігатися з вмістом вихідного файлу. Розглянемо випадок, коли процеси збираються зчитати з вихідного файлу послідовність з двох символів «ab». Припустимо, що батьківський процес зчитав символ «a», але не встиг записати його, бо ядро перемкнулося на контекст породженого процесу. Якщо породжений процес зчитує символ «b» і записує його в результуючий файл до відновлення батьківського процесу, рядок «ab» в результуючому файлі буде мати вигляд «ba». Ядро не гарантує узгодження темпів виконання процесів.

1.2.2 Переривання процесів Система відповідає за обробку всіх переривань, що надійшли від апаратури (наприклад, від таймера або від периферійних пристроїв), від програм (у зв’язку з виконанням інструкцій, що викликають виникнення «програмних переривань») або з’явилися результатом особливих ситуацій (таких як звернення до відсутньої сторінці). Якщо центральний процесор веде обробку на більш низькому рівні в порівнянні з рівнем надійшов переривання, то перед виконанням наступної інструкції його робота переривається, а рівень переривання процесора підвищується, щоб інші переривання з тим же (або більш низьким) рівнем не могли мати місця до тих пір, поки ядро не обробить поточне переривання, завдяки чому забезпечується збереження цілісності структур даних ядра. У процесі обробки переривання ядро виконує наступну послідовність дій:

1. Зберігає поточний регістровий контекст виконується процесу і створює в стеку (поміщає в стек) новий контекстний рівень.

2. Встановлює «джерело» переривання, ідентифікуючи тип переривання (наприклад, переривання по таймеру або від диска) і номер пристрою, що викликало переривання (наприклад, якщо переривання викликане жорстким диском). При виникненні переривання система отримує від машини число, яке використовує як зміщення в таблиці векторів переривання. Вміст векторів переривання в різних машинах різному, але, як правило, в них зберігається адресу програми обробки переривання, відповідної джерела переривання, і вказується шлях пошуку параметра для програми. Як приклад розглянемо таблицю векторів переривання, наведену у Таблиці 1.1. Якщо джерелом переривання з’явився термінал, апаратура передає ядру номер переривання, рівний 2, і викликає програму обробки переривань від терміналу ttyintr.

Таблиця 1.1 — Приклад векторів переривання

3. Виклик програми обробки переривання. Стек ядра для нового контекстного рівня, якщо міркувати логічно, повинен відрізнятися від стека ядра попереднього контекстного рівня. У деяких розробках стек ядра поточного процесу використовується для зберігання елементів, що відповідають програмам обробки переривань, в інших розробках ці елементи зберігаються в глобальному стеку переривань, завдяки чому забезпечується повернення з програми без перемикання контексту.

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

За допомогою використання в окремих випадках послідовності машинних операцій або мікрокоманд на деяких машинах досягається більший ефектів порівнянні з тим, коли всі операції виконуються програмним забезпеченням, проте є вузькі місця, пов’язані з числом зберігаються контекстних рівнів і швидкістю виконання машинних команд, що реалізують збереження контексту. З цієї причини певні операції, виконання яких вимагає реалізація UNIX-подібної системи, є машинно-залежними.

1.2.3 Здійснення сигналів процесами Для посилання сигналів процеси використовують системну функцію kill. Синтаксис виклику функції:

kill (pid, signum)

Де в pid вказується адресат посилається сигналу (область дії сигналу), а в signum — номер посилається сигналу. Зв’язок між значенням pid і сукупністю виконуються процесів наступна:

— Якщо pid — позитивне ціле число, ядро?? посилає сигнал процесу з заданим ідентифікатором pid;

— Якщо значення pid дорівнює 0, сигнал посилається всім процесам, що входять в одну групу з процесом, що викликав функцію kill.

— Якщо значення pid дорівнює -1, сигнал посилається всім процесам, у яких реальний код ідентифікації користувача збігається з тим, під яким виповнюється процес, що викликав функцію kill (про ці кодах більш детально див 7.6). Якщо процес, що послав сигнал, виконується під кодом ідентифікації суперкористувача, сигнал розсилається всім процесам, крім процесів з ідентифікаторами 0 і 1.

— Якщо pid — негативне ціле число, але не -1, сигнал посилається всім процесам, що входять у групу з номером, рівним абсолютним значенням pid.

У всіх випадках, якщо процес, що послав сигнал, виконується під кодом ідентифікації користувача, який не є суперкористувачем, або якщо коди ідентифікації користувача (реальний і виконавчий) у цього процесу не збігаються з відповідними кодами процесу, що приймає сигнал, kill завершується невдало.

В UNIX-подібних системах процес завершує своє виконання, запускаючи системну функцію exit. Після цього процес переходить у стан «припинення існування» див. рис. 1.3, звільняє ресурси і ліквідує свій контекст. Синтаксис виклику функції:

exit (status);

Де status — значення, що повертається функцією батьківського процесу. Процеси можуть викликати функцію exit як в явному, так і в неявному вигляді (по закінченні виконання програми: початкова процедура (startup), компонованих з усіма програмами на мові Сі, викликає функцію exit на вихід програми з функції main, що є загальною точкою входу для всіх програм). З іншого боку, ядро може викликати функцію exit за своєю ініціативою, якщо процес не прийняв посланий йому сигнал (про це ми вже говорили вище). У цьому випадку значення параметра status дорівнює номеру сигналу.

Система не накладає ніякого обмеження на тривалість виконання процесу, і часто процеси існують протягом досить тривалого часу. Нульовий процес (програма підкачки) і процес 1 (init), наприклад, існують протягом усього часу життя системи. Тривалими процесами є також getty-процеси, які контролюють роботу термінальної лінії, чекаючи реєстрації користувачів, і процеси загального призначення, що виконуються під керівництвом адміністратора.

При виконнанні функції exit. Спочатку ядро скасовує обробку всіх сигналів, що посилаються процесу, оскільки продовження їх обробки стає безглуздим. Якщо процес, що викликає функцію exit, очолює групу процесів, асоційовану з операторським терміналом, ядро робить припущення про те, що користувач припиняє роботу, і посилає всіх процесів в групі сигнал про «зависанні». Таким чином, якщо користувач в реєстраційному shell’е натисне послідовність клавіш, що означає «кінець файлу» (Ctrl-d), при цьому з терміналом залишилися пов’язаними деякі з існуючих процесів, процес, що виконує функцію exit, пошле їм усім сигнал про «зависання». Крім того, ядроскидає в нуль значення коду групи процесів для всіх процесів, що входять до групи, оскільки не виключена можливість того, що пізніше поточний код ідентифікації процесу (процесу, який викликав функцію exit) буде присвоєний іншому процесу і тоді останній очолить групу з зазначеним кодом. Процеси, що входили в стару групу, до нової групи входити не будуть. Після цього ядро переглядає дескриптори відкритих файлів, закриває кожен з цих файлів за алгоритмом close і звільняє за алгоритмом iput індекси поточного каталогу і кореня (якщо він змінювався).

Нарешті, ядро звільняє всю виділену завданню пам’ять разом з відповідними областями (за алгоритмом detachreg) і переводить процес в стан припинення існування. Ядро зберігає в таблиці процесів код повернення функції exit (status), а також сумарний час виконання процесу та його нащадків у режимі ядра та режимі завдання. Ядро також створює в глобальному обліковому файлі запис, який містить різну статистичну інформацію про виконання процесу, таку як код ідентифікації користувача, використання ресурсів центрального процесора і пам’яті, обсяг потоків вводу-виводу, пов’язаних з процесом. Користувальницькі програми можуть у будь-який момент звернутися до облікової файлу за статистичними даними, що представляють інтерес з точки зору стеження за функціонуванням системи та організації розрахунків з користувачами. Ядро видаляє процес з дерева процесів, а його нащадків передає процесу 1 (init). Таким чином, процес 1 стає законним батьком всіх продовжують існування нащадків завершується процесу. Якщо хто-небудь з нащадків припиняє існування, що завершується процес посилає процесу init сигнал «загибель нащадка» для того, щоб процес початкового завантаження міг видалити запис про нащадку з таблиці процесів; крім того, що завершується процес посилає цей сигнал своєму батьку. У типовій ситуації батьківський процес синхронізує своє виконання з завершується нащадком за допомогою системної функції wait. Припиняючи існування, процес перемикає контекст і ядро може тепер вибирати для виконання наступний процес.

1.3 Опис мови програмування Python

Треба звернути увагу на те що вся система Ajenti написана на мові програмування Python.

Python — це універсальна мова програмування має свої переваги і недоліки, а також сфери застосування. Python має велику стандартну бібліотеку для вирішення широкого кола завдань. В Інтернеті доступні якісні бібліотеки в різних предметних галузях: засоби обробки текстів і технології Інтернет, обробка зображень, інструменти для створення додатків, механізми доступу до баз даних, пакети для наукових обчислень, бібліотеки побудови графічного інтерфейсу і т.п. Крім того, Python має досить прості засоби для інтеграції з мовами C, C + + (і Java) як шляхом вбудовування (embedding) інтерпретатора в програми на цих мовах, так і навпаки, за допомогою використання бібліотек, написаних на цих мовах, в Python-програмах. Мова Python підтримує кілька парадигм програмування: імперативне (процедурний, структурний, модульний підходи), об'єктно-орієнтоване і функціональне програмування.

Можна вважати, що Python — це ціла технологія для створення програмних продуктів (і їх прототипів). Вона доступна майже на всіх сучасних платформах (як 32-бітових, так і на 64-бітових) з компілятором C і на платформі Java. Перевагою Python було те що навіть у різних платформах типи даних її займають рівну кількість місця що неможна сказати про таку відому мову програмування як С.

Автор визнає що навіть така передова мова програмування як Python має свій недолік. Основний і мабуть єдиний недолік у Python — це швидкість виконання яка в порівнянні з мовами програмування які компілюються є надто низькою, це зумовлене тим зо Python є інтерпретованою мовою програмування.

Може здатися, що, в програмної індустрії немає місця для чогось іншого, окрім C / C + +, Java, Visual Basic, C #. Однак це не так.

Python має безпосередні переваги:

— Відносно основних мов програмування таких як Pascal, C + +, Java, і т.д. в яких реалізована сувора статична типізація Python має динамічну типізацію що дозволяє не оголошувати змінні перед тим як їх використовуєш, а просто присвоювати змінній якийсь результат, що і зумовлює її тип;

— в Python відсутнє неявне приведення до типів данних що в деяких мовах зумовлює можливість втрати даних.

— у відношенні до С Python має так званий смітте-збирач

— також по відношенню до С в Python присутня реалізація блоків try/catch та finaly

— в Python можливо використовувати такі типи та структури даних як кортежі, списки порівнянь, цілі числа будьякої довжини

— Python не має реалізації покажчиків завдяки чому він схожий на Java, а як відомо саме покажчики мають властивість формувати дуже важкі у відловлюванні виключення.

1.4 Огляд веб-орієнтованих систем віддаленого адміністрування для Linux

За час існування Linux було розроблено декілька систем віддаленого адміністрування я вважаю за потрібне розглянути и порівняти деякі з них бо кожна система має свої специфічні характеристики та можливості.

Однією з таких систем є Zentyal яка являє собою сукупність програм які мають вже задані налаштування, всі програми пов’язані між собою в єдиній логіці. Цей комплекс програм має зручний і простий веб-інтерфейс (див. рис. 1.5) для управління основними параметрами.

На підприємстві Zentyal може бути в ролі шлюзу, чи сервера загальної інфраструктури підприємства, забезпечувати роль сервера безпеки, або офісного сервера, об`єднань комунікаційного сервера або комбінації перерахованих серверів. Ця система не має потреби у інших програмних продуктах, вона забезпечує управління всіма мережевими засобами.

Ліцензія GNU (General Public License) надає можливість доступу до вихідний коду проекту. Компанія eBox Technologies SL, яка є власником авторського права на код Zentyal надає гроші на подальшу розробку та піар цієї системи.

Другою системою яку треба розглянути є система Webmin, вона являє собою програмний комплекс, який дозволяє адмініструвати unix-подібну операційну систему, не прибігаючи до використання командного рядку і не запам’ятовуючи жодної команди. Все управління сервером відбувається через веб-інтерфейс. Використовуючи будь-який браузер, адміністратор сервера може заводити нові аккаунти, поштові скриньки, змінювати налаштування веб-сервера Apache, виправляти і доповнювати записи [DNS], налаштовувати сайти, поштові ящики і т.д. Webmin складається з простого веб-сервера і невеликої кількості скриптів, які власне і здійснюють зв’язок між командами адміністратора через веб-інтерфейс і їх виконанням на рівні операційної системи і прикладних програм. Webmin написаний повністю на мові Perl і не використовує ніяких додаткових нестандартних модулів. Простота, легкість і швидкість виконання команд — одне з найбільших переваг цієї панелі управління. Дана панель управління безкоштовно розповсюджується для комерційного та некомерційного використання. Автори цієї програми дозволяють всім охочим не тільки безкоштовно використовувати програму, але і змінювати її на свій розсуд. Працювати з Webmin досить просто — потрібно запустити браузер, набирати http://імя_домена.com:10 000/ і потрапити на сторінку адміністрування.

Рисунок 1.5 — Загальний вигляд інтерфейсу системи віддаленого адміністрування Zentyal

Недоліками системи є те що не всі можливості операційної системи і не всі програми можна конфігурувати через інтерфейс Webmin, наприклад nginx поки що не входить у базовий набір.

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

Рисунок 1.6 — Загальний вигляд інтерфейсу системи віддаленого адміністрування Webmin

Третьою є сама система до якої виконувалося написання додатку Ajenti, вона являє собою набір інструментів для управління Linux-серверами, націлений на простоту і стабільність. Перша публікація про даний проект з’явились 12 березня 2010 року [3], в ній головний розробник закликав приєднатися до нього при розробці цього інструменту адміністрування, саме після цього проект став швидкими темпами набирати обертів у швидкості розробки. Так за якийсь рік було реалізовано чималий шматок того що було заплановано.

Проект надає платформу для написання додатків для управління різноманітним серверним програмним забезпеченням, практично повноцінний UI-тулкіт (на AJAX) для управління через веб-інтерфейс див. рис. 1.7.

Одніею з переваг цієї системи є те, що всі вже написані плагіни підтримують (а нові - повинні підтримувати) валідність і акуратність відповідних конфігів сервера.

В системі зараз реалізовані плагіни:

— для керування мережею;

— для керування UPS і моніторингу живлення;

— для керування пакетними менеджерами (APT, Zypper, Pacman);

— для керування користувачами (passwd);

— для керування cron;

— для керування fstab;

— для керування сервісами (Upstart, rc. d, init. d);

— для керування файрволлом (iptables);

— для керування apache 2 (модулі, хости);

— для керування samba;

— для керування squid (+SARG);

— для виконання команд shell;

— переглядач логів;

— найпростіший SQL-клієнт (MySQL, pgSQL).

Рисунок 1.7 — Загальний вигляд інтерфейсу Ajenti

Тепер ми можемо з готовністю сказати що користувач має важкий вибір між такими системами як Webmin, Zentyal та Ajenti та серед усіх можливостей перших двох систем знаходиться і їхній недолік — мова на якій вони написані (Perl) має надто великий поріг для розробника щоб стало можливим пересічному програмісту зі старту розробити додаток до цієї системи. Python на якому написана Ajenti на відміну від Perl таких проблем не має, навпаки парадигми Python наполягають на тому що розробка має бути легкою та швидкою, крім того для людини яка знає хоча б одну мову програмування буде дуже легко перейти до написання програм на Python.

Другим але не менш важливим чинником при виборі такої системи є підтримка AJAX. Хоча ця функціональність не є вирішальною, але безперечно є перевагою Ajenti.

Таким чином, підсумком є те, що Ajenti є досить молодою системою, що динамічно розвивається. Webmin та Zentyal мають ширший спектр функцій, але внаслідок того що технології швидко змінюються, вже потроху починають втрачати свою актуальність.

1.5 Постановка задачі

Ґрунтуючись на тому що адміністрування сервера або віддаленого комп’ютера вимагає від користувача застосування великих обсягів додаткових знань, та витрат часу, це суттєво обмежує кількість спеціалістів що засвоїло таке вміння. Тому на сьогодні дуже важливо розробити прості інтуїтивно зрозумілі середовища що забезпечить виконання дій з адміністрування. Це потребує формування переліку дій що підлягають автоматизації:

— перегляд списку процесів;

— сортування процесів по їх характеристикам;

— виведення процесів у вигляді дерева;

— видалення процесу або під-дерева процесів.

Вони можуть бути реалізовані в додатку до Agenti. Це суттєво покращить умови роботи адміністратора системи.

Виходячи з цього треба розробити додаток до системи віддаленого адміністрування Ajenti та виконати його тестування робочих умовах.

Також в інтерфейсі модуля мають бути відображені такі важливі параметри як:

— PID — ідентифікатор процесу;

— PPID — ідентифікатор батьківського процесу;

— LWP — ідентифікатор легковажного процесу або потоку;

— C — відсоток процесорного часу використаного процесом за весь час існування;

— NLWP — кількість легковажних процесів або потоків;

— SZ — кількість сторінок фізичної пам’яті ядра процесу (це містить текст, дані і місце у стеку);

— RSS — розмір оперативної пам’яті не включаючи кешованої, що займає процес, в КБ;

— STIME — час запуску;

— TTY — керуючий термінал;

— TIME — час виконання на процесорі;

— CMD — команда яка виконується процесом.

При всьому цьому інтерфейс модуля має бути не перевантажений та інтуїтивно зрозумілий.

Для реалізації проекту треба обрати мову програмування Python (version 2.7), оскільки сама система Ajenti підтримує тільки модулі написані на Python.

2 ПРОЕКТУВАННЯ ТА РЕАЛІЗАЦІЯ

2.1 Відомості про середовище розробки Додаток який було написано у ході написання даної дипломної роботи був розроблений на високорівневій мові програмування Python. Для цієї мови програмування є кілька різних редакторів з під світкою синтаксису та найпростішою підстановкою, але повноцінних IDE не так багато. Найрозвинутішими представниками є PyCharm — дуже потужна IDE від розробників IntellJ IDEA — JetBrains, PyDev створена на основі Eclipse, а також PythonToolkit (PTK). Нажаль найкраща IDE PyCharm виявилася платною тому вибір був зроблений серед ыншими двома середовищами розробки.

Обидва середовища виконані у вигляді плагінів до середовища програмування Eclipse. За результатами огляду функцій цих середовищ дану бакалаврську роботу було вирішено розробляти в інтегрованому середовищі розробки PyDev. PyDev — це вільне інтегроване середовище розробки на основі Eclipse. Розвивається і підтримується Eclipse Foundation. Найвідоміші програми на основі Eclipse Platform — різні «Eclipse IDE» для розробки ПЗ на багатьох мовах (наприклад, найбільш популярний «Java IDE», підтримувався з самого початку, не покладається на будь-які закриті розширення, використовує стандартний відкритий API для доступу до Eclipse Platform).

Мовою програмування як вказано в розділі 1.3 було обрано Python. Серед інших причин для цього вибору було те, що сама система Ajenti написана на Python, і там нема підтримки плагінізації з використанням інших мов програмування. На Python можна писати кросплатформові додатки. Кросплатформові додатки — це додатки, які працють більш ніж на одній апаратній платформі та/або операційній системі.

На Python пишеться і підтримується велика кількість безкоштовних бібліотек. За допомогою цих бібліотек розробникам не потрібно придумувати свої рішення і витрачати на це час та сили, а можна відразу використовувати готове рішення написане професіоналами.

2.2 Архітектура підсистеми управління процесами

Процесом називається послідовність операцій при виконанні програми, які представляють собою набори байтів, що інтерпретуються центральним процесором як машинні інструкції (т. зв. «Текст»), дані і стекові структури. Створюється враження, що одночасно виконується безліч процесів, оскільки їх виконання планується ядром, і, крім того, декілька процесів можуть бути екземплярами однієї програми. Виконання процесу полягає в точному проходженні набору інструкцій, який є замкнутим і не передає управління набору інструкцій іншого процесу; він зчитує і записує інформацію в розділ даних і в стек, але йому недоступні дані і стеки інших процесів. Одні процеси взаємодіють з іншими процесами та з рештою світу за допомогою звернень до операційної системи.

З практичної точки зору процес в системі UNIX-подібної системи є об'єктом, що створюються в результаті виконання системної операції fork. Кожен процес, за винятком нульового, породжується в результаті запуску іншим процесом операції fork. Процес, що запустив операцію fork, називається батьківським, а новостворений процес — породженим. Кожен процес має одного батька, але може породити багато процесів. Ядро системи ідентифікує кожен процес по його номеру, який називається ідентифікатором процесу (PID). Нульовий процес є особливим процесом, який створюється «вручну» в результаті завантаження системи; після породження нового процесу (процес 1) нульовий процес стає процесом підкачки. Процес 1, відомий під ім'ям init, є предком якого іншого процесу в системі і пов’язаний з кожним процесом особливим чином.

Користувач, транслюючи вихідний текст програми, створює виконуваний файл, який складається з декількох частин:

— набору «заголовків», що описують атрибути файлу;

— тексту програми;

— подання на машинній мові даних, що мають початкові значення при запуску програми на виконання, і вказівки на те, скільки простору пам’яті ядро системи виділить під неініціалізовані дані, так звані bss (ядро встановлює їх в 0 в момент запуску);

— інших секцій, таких як інформація символічних таблиць.

Ядро завантажує виконуваний файл в пам’ять при виконанні системної операції exec, при цьому завантажений процес складається щонайменше з трьох частин, так званих областей: тексту, даних і стека. Області тексту і даних кореспондують з секціями тексту і bss-даних виконуваного файлу, а область стека створюється автоматично і її розмір динамічно встановлюється ядром системи під час виконання. Стек складається з логічних записів активації, які розміщені в стек при виклику функції і виштовхує з стека при поверненні управління в викликала процедуру; спеціальний реєстр, іменований покажчиком вершини стека, показує поточну глибину стека. Запис активації включає параметри передаються функції, її локальні змінні, а також дані, необхідні для відновлення попереднього запису активації, у тому числі значення лічильника команд і покажчика вершини стека в момент виклику функції. Текст програми включає послідовності команд, що керують збільшенням стека, а ядро?? системи виділяє, якщо потрібно, місце під стек. У програмі на рисенку 1.3 параметри argc і argv, а також змінні fdold і fdnew, що містяться у виклику функції main, поміщаються в стек, як тільки зустрілося звернення до функції main (один раз в кожній програмі, за умовою), так само і параметри old і new і змінна count, що містяться у виклику функції copy, поміщаються в стек у момент звернення до зазначеної функції.