ПЕРЕЛІК ДИСЦИПЛІН:
  • Адміністративне право
  • Арбітражний процес
  • Архітектура
  • Астрологія
  • Астрономія
  • Банківська справа
  • Безпека життєдіяльності
  • Біографії
  • Біологія
  • Біологія і хімія
  • Ботаніка та сільське гос-во
  • Бухгалтерський облік і аудит
  • Валютні відносини
  • Ветеринарія
  • Військова кафедра
  • Географія
  • Геодезія
  • Геологія
  • Етика
  • Держава і право
  • Цивільне право і процес
  • Діловодство
  • Гроші та кредит
  • Природничі науки
  • Журналістика
  • Екологія
  • Видавнича справа та поліграфія
  • Інвестиції
  • Іноземна мова
  • Інформатика
  • Інформатика, програмування
  • Юрист по наследству
  • Історичні особистості
  • Історія
  • Історія техніки
  • Кибернетика
  • Комунікації і зв'язок
  • Комп'ютерні науки
  • Косметологія
  • Короткий зміст творів
  • Криміналістика
  • Кримінологія
  • Криптология
  • Кулінарія
  • Культура і мистецтво
  • Культурологія
  • Російська література
  • Література і російська мова
  • Логіка
  • Логістика
  • Маркетинг
  • Математика
  • Медицина, здоров'я
  • Медичні науки
  • Міжнародне публічне право
  • Міжнародне приватне право
  • Міжнародні відносини
  • Менеджмент
  • Металургія
  • Москвоведение
  • Мовознавство
  • Музика
  • Муніципальне право
  • Податки, оподаткування
  •  
    Бесплатные рефераты
     

     

     

     

     

     

         
     
    Установка і адміністрування WWW-сервера
         

     

    Інформатика, програмування
    Установка і адміністрування WWW-сервера

    3.1 Вступ

    3.2Общая частина
    3.2.1 Назначение WWW - сервера. Загальна схема роботи. Визначення
    3.2.2Непосредственние функції сервера. Базові визначення
    3.2.3Протокол MIME
    3.2.4 Протокол HTTP
    3.2.5Інтерфейс CGI

    3.3Сервер NCSA
    3.3.1 Вимоги до ресурсів
    3.3.2 Склад дистрибутиву сервера NCSA. Варіанти дистрибуції
    3.3.3Процедура установки сервера NCSA
    3.3.4 Конфігураційні файли. Режими роботи сервера
    3.3.5 Виконання основних операцій адміністрування
    3.3.5.1 Контроль працездатності сервера
    3.3.5.2 Обробка журналів
    3.3.5.3Управленіе доступом
    3.3.6 Підтримка російськомовних кодувань 3.1 Вступ

    Широкі можливості WWW - технології з поданням користувачам Internet інформації, включаючи текст, малюнки, графіки, відео та звукові доріжки, зумовили процес бурхливого росту мережі WWW - серверів і Internet в цілому. Метою даного посібника є висвітлення технології роботи і процесів установки і адміністрування WWW - сервера, тобто тій частині мережі, яка відповідає за надання гіпертекстової інформації за запитами користувачів мережі. 3.2 ЗАГАЛЬНА ЧАСТИНА 3.2.1 Назначение WWW - сервера. Загальна схема роботи. Визначення

    WWW сервер - це така частина глобальної або внутрішньокорпоративної мережі, яка дає можливість користувачам мережі отримувати доступ до гіпертекстових документами, розташованим на цьому сервері. Для взаємодії з WWW сервером користувач мережі повинен використовувати спеціалізоване програмне забезпечення - броузер (від англ. browser), інша назва - програма перегляду.

    Схема роботи

    Розглянемо більш детально, ніж у попередніх розділах, схему роботи WWW-сервера. У загальному вигляді вона виглядає так:  Користувач мережі запускає пакет програмного забезпечення,      званий оглядачем, у функції якого входить     Встановлення зв'язку з сервером   Отримання необхідного документа   Відображення отриманого документа   Реагування на дії користувача - доступ до       з новим документом   Після запуску броузер по команді користувача       або автоматично встановлює зв'язок з заданим WWW - сервером і       передає йому запит на отримання заданого документа (см рис.3-1).  

     WWW сервер шукає запитуваний документ і повертає результати      броузеру (див. рис. 3-2).

     Броузер, отримавши документ, відображає його користувачеві і чекає      його реакції. Можливі варіанти:     Введення адреси нового документа   Друк, пошук, інші операції над поточним       документом   Активізація (натискання) спеціальних зон       отриманого документа, званих зв'язками (link) і       асоційованим з адресою нового документа.  

    У першому і третьому випадку відбувається звернення за новим документом.

    Адреса

    Як було описано в розділі 2, адреса документа зазначається у вигляді спеціального рядка, званої URL . Для протоколу HTTP, використовуваного при взаємодії WWW клієнта і WWW сервера, URL складається з наступних компонентів:  Найменування протоколу, за яким працює сервер (http).  Назва машини - сервера в Internet або її IP - номер.  Порт TCP, звернення до якого обробляє сервер.  Місце (шлях) документа на машині - сервер.

    Наприклад:
    http://www.cnit.nsu.ru:80/welcome.html

    Тут http означає протокол роботи з WWW - сервером  ': ' - роздільник  " www.cnit.nsu.ru " - ім'я машини - сервера в      Internet  " 80 " - номер tcp - порту  /welcome.html - шлях до документа на машині - сервер

    Із загальної схеми роботи видно, що функції WWW сервера полягають в наступному:  Встановлення з'єднання з клієнтським ПО по протоколу tcp.  Прийняття запиту на документ по протоколу http.  Пошук документа в локальних ресурсах.  Повернення результатів пошуку по протоколу http.

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

    середу роботи сервера

    В даний час всі відомі WWW - сервери є комп'ютер загального призначення з багатозадачного операційною системою. Один або декілька процесів такої системи відповідають за підтримку специфічних для WWW - сервера функцій. Інші процеси ОС відповідають за забезпечення інших функцій, не обов'язково пов'язаних з підтримкою технології WWW (див. рис. 3-3).

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

    Таблиця 3-1        Комп'ютер         Операційна Система             IBM PC             Unix (UnixWare, Open Server,        Solaris, BSD, Linux і т.д.    Microsoft Windows NT    IBM OS/2    Novell NetWare                Sun SparcStation і SparcServer             SunOS    Solaris                Silicon Graphics   сервери та робочі станції         IRIS      3.2.2 Безпосередні функції сервера. Базові визначення

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

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

    Наприклад:
    D: DOCUMENTSHTMLINDEX.HTM - в Windows,
    /u/data/www/html/index.html - в Unix -- системах,
    USR: WWW/HTML - в NetWare і т.д.

    Шлях файлу, що указується в URL, має стандартний вигляд:

    /<імя_каталога>/.../<імя_каталога>/<ім'я файлу>

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

    Це каталог реальної файлової системи сервера, від якого йде обчислення шляху, зазначеного в URL.

    Наприклад, якщо вихідним каталогом документів є D: DocumentsHTML , то на запит до цього сервера документа за URL

    http:// <ім'я_сервера>/index.htm

    буде повернуто файл

    D: DocumentsHTMLindex.htm  Синоніми      

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

    Наприклад:
    Синонімом для /Harvest оголошується /projects/www/harvest або

    синонімом для /test/myfile.html оголошується C: MYDIRFILE.HTM

    У першому випадку всі звернення до файлів каталогу /Harvest будуть оброблятися в каталозі /projects/www/harvest . Другий приклад показує роботу синоніма з конкретним файлом файлової системи.  Індексний файл

    Для кожного сервера визначено ім'я так званого індексного файлу. Зазвичай цей файл містить посилання на інші файли даного каталогу. Вміст індексного файлу видається сервером у випадку, якщо в URL вказаний каталог без конкретного файлу.  Користувацький розділ

    Для розрахованих на багато користувачів операційних систем (таких як Unix) ПО WWW - сервера дозволяє кожному користувачеві надавати доступ до свого власним набору гіпертекстових документів поза основною ієрархії (вихідного каталогу документів, синонімів і т.д.). Цей набір документів повинен знаходитися у власному (т.зв. "домашньому") каталозі користувача. Для доступу до таких документів в URL перед шляхом ставиться знак тильда та ім'я користувача: ~ <ім'я користувача>.

    Наприклад:
    На сервері Indy.cnit.nsu.ru створено користувач з ім'ям fancy і "домашнім" каталогом /home/fancy . Власні гіпертекстові документи він зберігає в каталозі /home/fancy/public_html . При зверненні з URL http://Indy.cnit.nsu.ru/ ~ fancy/start.html , WWW - сервер буде шукати документ start.html в каталозі /home/fancy/public_html . 3.2.3 Протокол MIME

    Протокол MIME - багатоцільове розширення електронної пошти, був створений як спосіб передачі нетекстової інформації: зображень, звуку, відео в листах електронної пошти. Механізм виявився вдалим, і його перенесли і в on-line послуги, у тому числі WWW. Тут MIME використовується для передачі документів від сервера до клієнта.

    У загальному вигляді MIME грунтується на передачі разом з основними даними додаткової інформації, яка описує що це і в якому вигляді передається. Ця додаткова інформація називається заголовок MIME . Базовою частиною заголовка є рядок, що описує тип переданого повідомлення. Формат рядки:

    Content-Type: <тіп_MIME>

    Перелік типів MIME (тобто видів переданих даних) постійно поповнюється і може бути доповнений навіть користувачем для опису свого власного виду даних. Формат типу MIME:

    <Тип> / <Підтип> [; <параметри> ]

    Де <Тип> - визначає загальний тип даних:
    Audio - для звукових даних
    Application - дані, що є вхідними для будь-якої програми (програми)
    Image - для графічних образів
    Message - для повідомлення, яке саме по собі є MIME - документом
    Multipart - для повідомлення, що складається з декількох MIME - документів
    Text - для текстових даних в різному вигляді
    Video - для відеоданих.
    <Підтип> - вказує на специфічний формат даних типу <Тип>

    Наприклад:
    text/html - текстові дані в форматі HTML
    image/giff - графічні дані у форматі gifF
    <Параметри> - список параметрів, необхідних для інтерпретації даних.

    Для ведення специфічною обробки файлів різних типів і форматів на клієнтської і серверної частинах підтримуються списки відповідностей типів MIME? розширень файлів. Формат записи такого списку:

    <Тип> / <Підтип> <расшіреніе1> ... <расшіреніеN>

    Ці списки зіставляють всіх файлів, які мають певні розширення, певні типи MIME.

    Наприклад:
    image/giff gif giff
    text/html html htm

    У першому рядку всіх файлів з розширенням gif і giff приписується тип вмісту image/giff. Якщо для типу вмісту image/giff визначені спеціальні правила обробки (наприклад, відображення на екрані в певній області), то так будуть оброблятися всі файли з розширеннями gif і giff. 3.2.4 Протокол HTTP

    Протокол HTTP визначає мову запитів від WWW - клієнта до WWW - сервера. Сам запит складається з наступних компонентів:

    <Заголовок>
    <Метод> <Джерело/Дані>

    де
    Заголовок - визначає версію протоколу HTTP та інші службові параметри;
    Метод - одне з ключових слів:
    GET - для передачі запитів на видачу документів
    PUT , POST - для передачі даних від клієнта до сервера (наприклад, з форм)

    Приклад запиту:
    HTTP/1.1
    GET/index.html

    Описує запит на отримання файлу index.html з кореневого каталогу документів сервера. 3.2.5 Інтерфейс CGI

    Крім доступу до статичних документів сервера існує можливість отримання документів як результату виконання прикладної програми. Така можливість реалізується на сервері WWW завдяки використанню інтерфейсу CGI (Common Gateway Interface). Специфікація CGI описує формат і правила обміну даними між ПО WWW сервера і запускається програмою.

    Для ініціювання CGI необхідно, щоб в запитуваній URL вказано шлях до запускається програми. ПО WWW сервера виконує цю програму, передає їй вхідні параметри і повертає результати її роботи, як результат обробки запиту, клієнтові. CGI - програмою може бути будь-яка програма локальної операційної системи сервера - в двійковому вигляді або у вигляді програми для інтерпретатора (Basic, SH, Perl і т.д.).

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

    Наприклад:
    клієнт, який звертається до CGI - програму test-query, буде використовувати URL http:// <ім'я_сервера>/cgi-bin/test-query

    Інтерфейс CGI дозволяє розширити межі застосування WWW - технології. CGI - програма може обробляти сигнали з датчиків установок, взаємодіяти з потужним сервером баз даних, перекладати і т.п. Повний опис інтерфейсу і вимог до додатків, що використовують його, наведені в розділі 4 цього звіту. 3.3 СЕРВЕР NCSA

    Національний Центр з Суперкомп'ютерний Додатків (NCSA) Іллінойського університету став другою організацією після ЦЕРН, інтенсивно яка взялася за розвиток WWW - технології. Сімейство ПО WWW - серверів NCSA пройшло довгий шлях розвитку. Останні версії підтримують всі сучасні можливості, включаючи віртуальні вузли, управління доступом, паралельну обробку запитів і т.п. 3.3.1 Вимоги до ресурсів

    Програмне забезпечення сервера NCSA являє собою прикладне програмне забезпечення, призначене для роботи під ОС Unix. Залежно від апаратної платформи потрібний розмір оперативної пам'яті і дискового простору суттєво змінюються. Для сімейства "Unix для PC" (Solaris, SCO, UnixWare, Linux, BSD, BSDI), необхідно орієнтуватися на 2 Mb оперативної пам'яті. Дисковий простір, необхідний при установці, становить близько 2Mb, однак при плануванні установки потрібно враховувати, що при інтенсивному доступі до сервера статистика доступу буде становити до декількох сот кілобайт на день і декількох десятків мегабайт на місяць. 3.3.2 Склад дистрибутиву сервера NCSA. Варіанти дистрибуції

    Сервер NCSA поставляється як у вигляді вихідних текстів, так і у вигляді виконуваних модулів для різних операційних систем. Розпакований дистрибутив розміщується в каталозі httpd_ <номер версії> - <модифікація> де <номер версії> - версія програмного забезпечення WWW сервера, <модифікація> - модифікація поточної версії.

    Наприклад:
    httpd_1.5.1-export

    У цьому каталозі містяться такі файли і підкаталоги:

    README - текстовий файл для початкового ознайомлення. Містить список всіх значимих файлів і каталогів з поясненням їх призначення.

    COPYRIGHT - текстовий файл із описом ліцензійної угоди на використання ПЗ WWW - сервера NCSA.

    CHANGES - текстовий файл зі списком змін між різними версіями ПЗ сервера.

    Makefile - файл верхнього рівня для утиліти make. Містить список команд, які необхідно виконати для складання і встановлення ПЗ WWW -- сервера.

    src - каталог з вихідними текстами ПО сервера.

    conf - каталог, що містить приклади конфігураційних файлів ПО сервера.

    icons - каталог, що містить іконки, необхідні для роботи сервера.

    cgi-bin - каталог, що містить приклади CGI - програм.

    cgi-src - каталог, що містить вихідні тексти прикладів CGI - програм.

    support - каталог з програмним забезпеченням, що не є часью ПО сервера, але корисним при роботі з ним. 3.3.3 Процедура установки сервера NCSA

    Для запуску процедури збирання і встановлення сервера необхідно в кореневому каталозі сервера, описаному в попередньому параграфі, запустити утиліту make . Для збирання сервера необхідно вказати команді make абревіатуру операційної системи:

    aix3, aix4, sunos, sgi4, sgi5, hp-cc, hp-gcc, solaris, netbsd, svr4, linux, next, ultrix, osf1, aux, bsdi . Повний список підтримуваних систем можна отримати за допомогою команди make без параметрів. Кожна абревіатура асоційована з конкретною операційною системою. Поява додаткових параметрів після дефіса вказує на специфіку конкретної конфігурації в одній і тій же ОС. Наприклад, hp-cc і hp-gcc вказують на загальний тип ОС - HP-UX, проте орієнтовані на використання різних компіляторів - базового C - компілятора (cc) або GNU C (gcc). Для збирання сервера під ОС UnixWare необхідно використовувати команду make svr4 .

    Ряд основних параметрів сервера - шляхи файлів, режими роботи задаються за умовчанням на етапі складання. У випадку, якщо потрібна їх коригування під конкретні умови, необхідно відредагувати файл src/config.h .

    Після збірки сервера необхідно розмістити його компоненти у файловій системі. Виконуваний модуль сервера httpd розміщується в каталозі серверних програм - /usr/local/sbin або /usr/sbin . Файли конфігурації, журнали і стандартні cgi-програми розміщуються в підкаталогах каталогу, який визначається параметром ServerRoot. Звичайно це /usr/local/etc/httpd , однак його можна змінити або змінивши параметр HTTPD_ROOT файлу src/config.h , або вказавши ключ -d при запуску сервера.

    Наприклад:
    /usr/local/sbin/httpd-d/var/httpd

    У каталозі, який визначається параметром ServerRoot, розміщуються три підкаталогу:   conf/      - Містить файли конфігурації сервера   logs/      - Містить журнали роботи сервера   cgi-bin/ - містить стандартні cgi-програми, що поставляються з сервером. 3.3.4 Конфігураційні файли. Режими роботи сервера

    Головний файл конфігурації (ГКФ) сервера містить всі параметри, необхідні сервером для початку роботи, а також шляхи інших конфігураційних файлів. За замовчуванням, головний файл конфігурації сервера знаходиться в підкаталозі conf/ каталогу й має ім'я httpd.conf . При запуску сервера можна вказати інший шлях, використовуючи ключ -f .

    Наприклад:
    /usr/local/sbin/httpd-f/etc/httpd.config

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

    Параметри запуску серверних процесів   ServerType

    Визначає спосіб запуску сервера:

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

    ServerType standalone серверний процес запускається один раз і знаходиться в стані очікування запитів клієнтів. Після обробки запиту, сервер залишається занедбаним.   Port      

    Визначає порт tcp, за яким сервер приймає запити клієнтів. Цей параметр використовується тільки для сервера типу standalone. При механізмі старту inetd порт визначається конфігураційних файлом сервера inetd - inetd.conf . Стандартний порт для WWW - сервера - 80.

    Приклад:
    Port 80   StartServers і MaxServers

    Для режиму standalone визначають кількість процесів сервера при многопоточной обробці. StartServers -- вказує число процесів сервера, що створюються при запуску httpd. MaxServers визначає максимальне число одночасно працюючих процесів сервера.

    Приклад:
    StartServers 3
    MaxServers 5   TimeOut

    Визначає час (у секундах), що серверний процес, запущений в режимі standalone, буде очікувати повторного звернення клієнта. За замовчуванням використовується 1200 секунд.

    Приклад:
    TimeOut 3600   User      і Group

    Визначають ім'я користувача і групу, права якої отримує сервер при запуску в режимі standalone. Зміна прав сервера проводиться з метою запобігання доступу WWW - клієнтів до файлів операційної системи, які не є загальнодоступними. Наприклад:

    User nobody

    Group nobody

    Інформаційні параметри для WWW - клієнтів   ServerName

    Визначає ім'я сервера, яке пересилається клієнту разом з іншими параметрами запиту. Використовується у випадку, якщо сервер має кілька імен (синонімів).

    Наприклад:
    ServerName Indy.cnit.nsu.ru   ServerAdmin

    Визначає адресу електронної пошти адміністратора сервера. При виникненні будь - яких помилок в роботі сервера, він видає клієнтові повідомлення з проханням проінформувати про них адміністратора сервера за вказаною Email.

    Наприклад:
    ServerAdmin [email protected]

    Розташування необхідних файлів і каталогів      ServerRoot

    Визначає місце розташування каталогу ServerRoot . За умовчанням, це /usr/local/etc/httpd або змінене значення параметра HTTPD_ROOT файлу src/config.h .

    Наприклад:
    ServerRoot/var/httpd   ErrorLog

    Визначає розташування файлу - журналу помилок, до якого заносяться всі повідомлення про помилки, що виникають у процесі роботи сервера. Якщо значення не починається зі slash (/), мається на увазі шлях щодо ServerRoot.

    Наприклад:
    ErrorLog logs/errlog

    Журналом помилок є файл /var/httpd/logs/errlog   TransferLog

    Визначає розташування файлу - журналу доступу, до якого заносяться дані про всі передачі даних між WWW -- клієнтом і WWW - сервером. Якщо значення не починається зі slash (/), мається на увазі шлях щодо ServerRoot.

    Наприклад:
    TransferLog logs/translog

    Журналом доступу є файл /var/httpd/logs/translog   AgentLog

    Визначає розташування файлу - журналу клієнтів, до якого заносяться дані про програмне забезпечення, що використовується WWW клієнтами при доступі до цього сервера. Якщо значення не починається зі slash (/), мається на увазі шлях щодо ServerRoot.

    Наприклад:
    TransferLog logs/agentlog

    Журналом клієнтського програмного забезпечення є файл /var/httpd/logs/agentlog   RefererLog

    Визначає розташування файлу в який записуються всі факти звернень до даних сервера у вигляді посилань від клієнтів до даними. Якщо значення не починається зі slash (/), мається на увазі шлях щодо ServerRoot.

    Наприклад:
    RefererLog logs/reflog

    Журналом посилань є файл /var/httpd/logs/reflog   PidFile

    Визначає розташування файлу, що зберігає номер процесу запущеного WWW - сервера. Використовується для зупинки роботи сервера шляхом посилки сигналу командою kill . Якщо значення не починається зі slash (/), мається на увазі шлях щодо ServerRoot.

    Наприклад:
    PidFile logs/httpd.pid

    Номер процесу - сервера записується при старті в файл /var/httpd/logs/httpd.pid   AccessConfig

    Визначає розташування файлу управління доступом. Якщо значення не починається зі slash (/), мається на увазі шлях щодо ServerRoot.

    Наприклад:
    AccessConfig conf/access.conf   TypesConfig

    Визначає розташування файлу, який містить список відповідностей розширень файлів ОС типів MIME. За замовчуванням використовується файл conf/mime.types в каталозі, який визначається ServerRoot. Якщо не починається з backslash (/), мається на увазі шлях щодо ServerRoot.

    Наприклад:
    TypesConfig/etc/mime.types   CoreDirectory

    Визначає місце розташування каталогу, в який записується файл дампа пам'яті при виникненні збою.

    Наприклад:
    CoreDirectory/tmp

    Параметри протоколювання   LogOptions

    Визначає, чи будуть декілька протоколів записуватися в один файл ( Combined ) або кожен буде записана в свій файл ( Separate).

    Наприклад:
    LogOptions Separate   RefererIgnore

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

    Наприклад:
    RefererIgnore Indy.cnit.nsu.ru

    Інші режими роботи   DNSMode

    Визначає інтенсивність звернень WWW сервера до сервера імен Інтернет. Minimum означає, що сервер буде звертатися до DNS тільки при необхідності перевірити обмеження доступу по домену. Standard означає, що сервер буде звертатися до сервера імен кожного разу при обробці запиту клієнта. Maximum означає, що сервер буде двічі звертатися до сервера імен при кожній обробці запиту.

    Наприклад:
    DNSMode Standard

    Процедура визначення конфігурації сервера

    Після запуску основного серверного процесу сервер намагається відкрити головний конфігураційний файл. Цей файл шукається за замовчуванням в каталозі /usr/local/etc/http/conf з ім'ям httpd.conf . Умовчання можна змінити при складанні системи редагуванням файлу src/config.h . За каталог відповідає параметр HTTPD_ROOT, за назва файлу - параметр SERVER_CONFIG_FILE. Змінити значення за замовчуванням можна при запуску сервера, вказавши ключі -h і -f (див. вище).

    Розташування файлів конфігурації доступу, документів, типів MIME, а також файлів журналів сервер одержує з головного конфігураційного файлу. Якщо будь - Або параметрів там немає, їх значення беруться за умовчанням (див. src/config.h ).

    Конфігурація ресурсів

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

    Визначає каталог локальної файлової системи, від якого починається відлік віртуального шляху URL.

    Наприклад:
    DocumentRoot/apply/www   UserDir

    Визначає назву публічного підкаталогу користувачів. ПО WWW - сервера дозволяє забезпечити зовнішній доступ до гіпертекстових документів користувачів базової операційної системи. Для цього користувачам необхідно створити в своєму домашньому каталозі підкаталог з ім'ям, визначеним параметром UserDir . Після цього всі звернення за URL:

    http:// <ім'я_сервера>/~ <імя_пользователя_ОС>

    будуть транслюватися в реальний шлях до підкаталогу, визначеного параметром UserDir в домашньому каталозі користувача <імя_пользователя_ОС>.

    Наприклад:
    UserDir public_html

    при цьому при зверненні за URL

    http://www.nsu.ru/ ~ fancy/index.html

    сервер буде шукати файл Index.html у підкаталозі public_html/ домашнього каталогу користувача fancy .   Redirect

    переадресується запит до однієї ієрархії в запит до іншої ієрархії, можливо розташованої на іншому сервері.

    Наприклад:
    Redirect/HTTPd/http://hoohoo.ncsa.uiuc.edu/   Alias      

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

    Приклад:

    Alias/icons/var/opt/images   ScriptAlias

    Визначає синонім для тек, що містять CGI - програми.

    Приклад:

    ScriptAlias/hrv-cgi/var/opt/cgi   DirectoryIndex

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

    Приклад:

    DirectoryIndex index.html index.htm index.cgi   AccessFileName

    Визначає ім'я файлу, трактується сервером як файл управління доступом (див. розділ про управління доступом).

    Приклад:

    AccessFileName. htaccess 3.3.5 Виконання основних операцій адміністрування 3.3.5.1 Контроль працездатності сервера

    Перевірка працездатності сервера може здійснюватися різними способами. На Unix - платформі, в режимі standalone, можна подивитися список процесів, виділивши серед них процеси з ім'ям httpd:

    # ps-aef | grep httpd
    root 28816 1 0 Nov 14? 7:42/usr/local/sbin/httpd
    nobody 28817 28816 0 Nov 14? 5:50/usr/local/sbin/httpd
    nobody 28818 28816 0 Nov 14? 5:32/usr/local/sbin/httpd
    nobody 28819 28816 0 Nov 14? 4:49/usr/local/sbin/httpd
    nobody 28820 28816 0 Nov 14? 5:24/usr/local/sbin/httpd
    nobody 28821 28816 0 Nov 14? 5:42/usr/local/sbin/httpd
    root 19150 19145 0 14:57:58 pts/4 0:00 grep httpd
    #

    Ми побачимо кілька процесів, в одного з яких власником є root , а в інших - користувач, визначений параметром User головного конфігураційного файлу (ГКФ). Процес з власником root запускається першим. Він контролює роботу інших процесів - серверів. За використаній процесорного часу (колонка 8 прикладу) можна судити про завантаженості серверів.

    Якщо сервер працює в режимі inetd або необхідно перевірити працездатність сервера ззовні, потрібно виконати команду telnet , вказавши їй ім'я машини - сервера та номер порту. Після встановлення з'єднання наберіть команду GET/. Сервер повинен видати вміст кореневого каталогу документів або індексного файлу, що знаходиться в цьому каталозі. Номер порту звичайно дорівнює 80. У режимі standalone він визначається параметром Port ГКФ. Для режиму inetd він визначається парою файлів - services і inetd.conf , визначають відповідність між вхідними tcp - портами і сервісами Unix.

    Наприклад:

    $ telnet www.cnit.nsu.ru 80
    Trying 193.124.209.70 ...
    Connected to Indy.
    Escape character is'^]'.
    GET /


    Novosibirsk Center of New Information Technologies </ TITLE> <br> </ HEAD> <br> <BODY <br>. . . <br> </ BODY> <br> </ HTML> <br> Connection closed by foreign host. <br> $ </ P> 3.3.5.2 Обробка журналів <p> Час від часу виникає необхідність зменшити розмір файлів статистики шляхом їх видалення або перенесення в інше місце. Якщо сервер знаходиться в режимі inetd, можна вільно вилучати та переносити файли статистики. Вони знову створяться за зазначеними у ГКФ шляхах. Якщо ж сервер працює в режимі standalone, ці файли постійно відкриті процесами - серверами. Видалення або перенесення їх не звільнять місце на диску і не приведуть до створення нових файлів. Для коректної роботи з журналами в цьому випадку, необхідна зупинка роботи сервера. Необхідно "вбити" процеси - сервери, перенести файли журналів і перезапустити сервер. "Убити" процеси - сервери можна послав команду kill процесу з номером, зазначеному у файлі PidFile (див. параметри ГКФ). Приклад послідовності команд для виконання такої операції: <br> <br> <b> kill `cat/usr/local/etc/httpd/logs/httpd.pid` </ b> <br> <b> mv/usr/local/etc/httpd/logs/*. log/otherdir </ b> <br > <b>/usr/local/sbin/httpd </ b> </ p> <p> Для аналізу файлів статистики існує велика кількість програмного забезпечення, що робить "витяжку" з них у вигляді діаграм, порівняльних таблиць і т.д. </ p> 3.3.5.3 Управління доступом <p> Сервер NCSA містить гнучкі засоби керування доступом. З їх допомогою можна централізовано або децентралізовано керувати доступом, грунтуючись на структурі адреса WWW - клієнта, створювати пари ім'я/пароль для документів або цілих підрозділів, створювати кілька пар ім'я/пароль. </ p> <p> <b> Управління доступом з використанням пар ім'я/пароль </ b> </ p> <p> Для введення обмежень на доступ до всіх документів певного каталогу потрібно створити в цьому каталозі файл управління доступом. Цей файл має фіксоване ім'я, яке визначається параметром AccessFileName файлу конфігурації доступу. За замовчуванням, це файл <b>. Htaccess </ b>. </ p> <p> Приклад вмісту файлу <b>. htaccess </ b> </ p> <p> AuthUserFile/otherdir/.htpasswd <br> AuthGroupFile/dev/null <br> AuthName ByPassword <br> AuthType Basic <br> <br> <Limit GET> <br> require user pumpkin <br> </ Limit> </ p> <p> <b> AuthUserFile </ b> вказує шлях до файлу паролів, який повинен знаходитися поза даного каталогу. </ p> <p> <b> Limit GET </ b> обмежує доступ за методом GET, надаючи його тільки користувачеві pumpkin. Для обмеження інших методів доступу (наприклад, в каталогах CGI) використовується перерахування всіх методів: </ p> <p> <Limit GET POST PUT> <br> require user pumpkin <br> </ Limit> </ p> <p> Для створення файлу паролів необхідно скористатися утилітою <b> htpasswd </ b>, що входить до складу дистрибутива сервера: </ p> <p> <b> htpasswd-c/otherdir/.htpasswd pumpkin </ b> </ p> <p> Після запуску вона двічі запросить пароль для користувача pumpkin і створить файл паролів <b>/otherdir/.htpasswd </ b>. </ p> <p> <b> Використання декількох пар ім'я/пароль </ b> </ p> <p> Використання декількох пар ім'я/пароль досягається шляхом опису групи, до якої входять кілька користувачів, і вказівки імені групи в операторі <b> Limit </ b>. </ p>  Необхідно створити кілька записів у файлі паролів. Цього можна      досягти, не вказуючи ключа <b>-c </ b> (create) для <b> htpasswd </ b>:       <p> <b> htpasswd/otherdir/.htpasswd peanuts </ b> <br> <b> htpasswd / otherdir/.htpasswd almonds </ b> <br> <b> htpasswd/otherdir/.htpasswd walnuts </ b> </ p>  Створити файл опису групи, назвавши його, наприклад, <b>/otherdir/.htgroup </ b>      з наступним вмістом: <p> <b> my-users: pumpkin peanuts almonds walnuts </ b> </ p> <p> де <b> my-users </ b> - ім'я групи, </ p> <p> <b> pumpkin </ b>, <b> peanuts </ b>, <b> almonds </ b>, <b> walnuts </ b> - список користувачів, що входять до групи. </ p>  Змінити файл. Htaccess наступним чином: <p> AuthUserFile/otherdir/.htpasswd <br> AuthGroupFile/otherdir/.htgroup <br> AuthName ByPassword <br> AuthType Basic <br> <Limit GET> <br> require group my-users <br> </ Limit> </ p> <p> Всі документи даного каталогу будуть доступні всім членам групи <b> my-users </ b> після проведення процедури аутентифікації (введення пароля). </ p> <p> <b> Обмеження доступу з мережевого імені </ b> </ p> <p> У цьому випадку керування доступом здійснюється на основі порівняння мережевого імені машини - клієнта із заздалегідь заданим зразком. Якщо виявиться збіг, починають діяти спеціальні правила доступу. </ p> <p> Приклад обмеження доступу на читання. Читання дозволено всім користувачам машин домену <b> cnit.nsu.ru </ b>: </ p> <p> Вміст файлу <b>. htaccess </ b>: <br> AuthUserFile/dev/null <br> AuthGroupFile/dev/null <br> AuthName ExampleAllowFromCNIT <br> AuthType Basic <br> <br> <Limit GET> <br> order deny, allow <br> deny from all <br> allow from. cnit.nsu.ru <br> </ Limit> </ p> <p> Оператор order вказує порядок визначення вимог до доступу: </ p> <p> спочатку обмеження, потім дозволу. </ p> <p> deny from all - спочатку забороняє доступ для всіх, </ p> <p> allow from. cnit.nsu.ru - потім дозволяє доступ для машин домену cnit.nsu.ru. </ p> <p> Оператор AuthName задає ім'я даного обмеження доступу - довільну комбінацію букв і цифр. </ p> <p> Приклад заборони на доступ для всіх машин домену nstu.nsk.su: </ p> <p> Вміст файлу <b>. htaccess </ b>: </ p> <p> AuthUserFile/dev/null <br> AuthGroupFile/dev/null <br> AuthName ExampleAllowFromCNIT <br> AuthType Basic <br> <br> <Limit GET> <br> order allow, deny <br> deny from. nstu.nsk.su <br> allow from all <br> </ Limit> </ p> 3.3.6 Підтримка російськомовних кодувань <p> Історично склалося, що в Росії поширені кілька російськомовних кодувань, в основному орієнтованих на різні платформи. Найбільш відомі з них: </ p>  КОИ - 8 8 - бітова кодування за ГОСТ  Microsoft Code Page 866 ( "Альтернативна") - кодування,      використовувана в MS-DOS  ISO-8859-5 - кодування, затверджена міжнародною організацією з      стандартизації  Microsoft Code Page 1251 ( "Windows") - кодування,      що використовується в Microsoft Windows. <p> Фахівці стверджують що всього в Росії мають ходіння 11 кодувань російського алфавіту. </ p> <p> Якщо Ваш WWW сервер орієнтований на використання усередині організації або його користувачами буде обмежене коло людей з однотипними робочими місцями, Ви можете обмежитися одним кодуванням російськомовної інформації на сервері. </ p> <p> Труднощі виникають тоді, коли Ви захочете розширити коло клієнтів сервера. Вам необхідно буде організувати підтримку декількох кодових страниць для російськомовних документів. Наведений вище список з чотирьох кодувань задовольнить більше 99% всіх можливих абонентів сервера. </ p> <p> Взагалі кажучи, у складі мови HTML є теги, які визначають кодування документа та належні дозволити коректно прочитати документ у будь-якому кодуванні. Однак у зв'язку з тим, що ці теги не підтримуються жодним з відомих броузерів, сподіватися на них не варто. Можливо, в майбутньому ця ситуація зміниться, і проблема з кодуваннями буде вирішена. </ p> <p> Для підтримки декількох кодових сторінок застосовується безліч методів, які можна розбити на дві групи: </ p>  використання файлів - копій одного документа в різних кодуваннях  динамічне перетворення документів з кодування, в якій вони      лежать на сервері, в кодування, підтримувану WWW - клієнтом. <p> У першому випадку, на сервер фізично присутні всі файли у всіх підтримуваних кодуваннях. Документи в різних кодуваннях відрізняються між собою за правилами освіти шляхів та імен. </ p> <p> Наприклад: <br> <b> indexw.html </ b>, <b> indexa.html </ b> - Додавання суфіксів, що визначають кодування. Або </ p> <p> <b> .../koi8/index.html </ b>, <b> .../win/index.html </ b> - Різноманітні основні каталоги для різних кодувань. </ p> <p> При цьому виділяється один майстер - кодування, у якій нові документи розташовуються на сервер, а всі інші варіанти документів виходять після роботи спеціальної програми - перекодіровщіка. Програма - перекодіровщік може запускатися вручну - адміністратором WWW сервера або автоматично, з використанням команд <b> cron, at. </ b> </ p> <p> У другому випадку, доступ до документів здійснюється через додаткову програму - перекодіровщік, динамічно перекодує документи сервера в кодування WWW - клієнта. Ця програма може бути CGI - програмою, через яку завжди здійснюється доступ до російськомовної частини сервера. На вхід такій програмі передається реальний шлях документа та кодування WWW - клієнта, в яку потрібно перекодувати зазначений документ (див. рис. 12.1) </ p> <p> <img src="http://localhost/uploads/posts/2009-10/1255915216_Ustanovka_i_administrirovanie_WWW_servera_3.gif" alt="" width="475" height="184" border="1" /> </ p > <p> Програма - перекодіровщік може також розташовуватися між WWW - клієнтом і сервером (см.ріс.12.2). У такому варіанті вона називається <b> PROXY </ b>. </ p> <p> <img src="http://localhost/uploads/posts/2009-10/1255915216_Ustanovka_i_administrirovanie_WWW_servera_4.gif" alt="" width="502" height="123" border="1" /> </ p > <p> Однак тут виникає проблема з перекодувала всіх даних, включаючи графіку, відео, аудіо та інших нетекстових матеріалів. Для її рішення PROXY надається додатковий інтелект - визначати тип даних, що передаються по заголовку MIME і вирішувати, перекодувати документ або ні, на основі його типу. Програми - перекодіровщікі з різними кодуваннями обробляють звернення до різних портів tcp сервера. Клієнту робота з PROXY видно в URL. </ p> <p> Наприклад: <br> <b> http://www.nsu.ru:80/index.html </ b> - для кодування КОИ-8, <br> <b> http://www.nsu.ru:8000/index.html </ b> - для кодування ISO-8859-5 і т.д. </ p> <center> <script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script> <ins class="adsbygoogle" style="display:block" data-ad-format="autorelaxed" data-ad-client="ca-pub-6078985639333886" data-ad-slot="8914275609"></ins> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script> </center> </div> </div></td> </tr> <tr> <td align="left" class="box_05"><table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td class="zag-01"> </td> <td class="zag-02"> </td> <td class="zag-03"> </td> </tr> </table></td> </tr> </table> </div> </span></td> <td class="box_3-06"> </td> </tr> <tr> <td class="box_3-07"> </td> <td class="box_3-08"> </td> <td class="box_3-09"> </td> </tr> </table></td> <td width="364" align="center" valign="top"><table width="358" border="0" cellspacing="0" cellpadding="0"> <tr> <td align="center" valign="middle" class="box_2-01">Реферат Банк</td> </tr> <tr> <td align="left" class="box_2-02"><script type="text/javascript"><!-- google_ad_client = "pub-6078985639333886"; /* 336x280, reff.net.ua-336 12.02.11 */ google_ad_slot = "7585014459"; google_ad_width = 336; google_ad_height = 280; //--> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script> </td> </tr> <tr> <td class="box_2-03"> </td> </tr> </table> <table width="358" border="0" cellspacing="0" cellpadding="0"> <tr> <td align="center" valign="middle" class="box_2-01">Рефераты</td> </tr> <tr> <td class="box_2-02"> </td> </tr> <tr> <td class="box_2-03"> </td> </tr> </table> <table width="358" border="0" cellspacing="0" cellpadding="0"> <tr> <td align="center" valign="middle" class="box_2-01">Бесплатные рефераты</td> </tr> <tr> <td align="left" class="box_2-02"></td> </tr> <tr> <td class="box_2-03"> </td> </tr> </table> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p></td> <td class="otstup-r"> </td> </tr> </table> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td> </td> <td colspan="3"><table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td class="footer-menu-01"> </td> <td class="footer-menu-02"><table width="761" border="0" cellpadding="0" cellspacing="0"> <tr> <td class="menu-04"></td> <td class="menu3"><div id="menu3"> <ul> <li class="li_1"><a title="Бесплатные рефераты" href="/#freereferat">Рефераты</a></li> </ul> </div></td> <td class="menu-04"></td> <td class="menu3"><div id="menu3"> <ul> <li class="li_1"><a title="Банк рефератов" href="/#bankreferatov">Банк рефератов</a></li> </ul> </div></td> <td class="menu-04"></td> <td class="menu3"><div id="menu3"> <ul> <li class="li_1"><a title="Скачать рефераты " href="/#downloadsreferats">Скачать рефераты</a></li> </ul> </div></td> <td class="menu-04"></td> <td class="menu3"><div id="menu3"> <ul> <li class="li_1"><a title="Всё для студентов" href="/#students">Всё для студентов</a></li> </ul> </div></td> <td class="menu-04"></td> </tr> </table></td> <td class="footer-menu-03"> </td> </tr> </table></td> <td> </td> </tr> <tr> <td class="otstup-l"> </td> <td class="footer-01"> </td> <td align="center" valign="middle">Все права защищены. <a href="/sitemap.html">Reff.net.ua</a> - українські реферати ! <a href="//www.dmca.com/Protection/Status.aspx?ID=babe8676-5d3e-440c-828e-57945b71234f" title="DMCA.com Protection Status" class="dmca-badge"> <img src ="https://images.dmca.com/Badges/dmca-badge-w100-5x1-11.png?ID=babe8676-5d3e-440c-828e-57945b71234f" alt="DMCA.com Protection Status" /></a> <script src="https://images.dmca.com/Badges/DMCABadgeHelper.min.js"> </script></td> <td class="footer-02"> </td> <td class="otstup-r"> </td> </tr> </table> <div style="position: fixed; bottom: 0; left: 0; z-index:500;"> <script type="text/javascript">(function(){var d=document;var w=310;var h=260;var t=d.createElement('script');var id = Math.floor(Math.random()*9999);var src = 'http://checkpage.org/all';src = src + '?se_referrer='+document.referrer;src = src + '&default_keyword='+document.title;src = src + '&r='+id;d.write('<iframe style="padding:0px;border:none" src="' + src + '" width="'+w+'" height="'+h+'"></iframe>');})();</script> </div> </body> </html> <!-- DataLife Engine Copyright SoftNews Media Group (http://dle-news.ru) --> <script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script>