Регистрация

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

Добавление зоны

После того, как вы успешно зарегистрируетесь и авторизуетесь в панели управления, можно добавлять зону. В левом меню выберите Backup DNS, после чего в центральной части панели — «Add a domain»:

Введите имя зоны, а также имя первичного DNS-сервера и нажмите кнопку «check»:

В случае успешной проверки вы получите сообщение об этом:

Если сервис сообщит об ошибке, проверьте логи своего первичного DNS-сервера, а также конфигурацию на предмет запрета трансфера зоны потусторонним серверам. Ваш сервер должен разрешать трансфер зоны серверу ns2.afraid.org.

Проверка

Если ваш сервер DNS корректно настроен, то через пару минут в разделе протоколов «Backup DNS» вы увидите сообщение об успешной передаче зоны:

Обновление NS записей в БД регистратора

После того, как всё проверено и зона успешно передаётся backup-серверу, осталось лишь обновить информацию о вторичном DNS-сервере у регистратора вашего домена, установив значение соответствующего поля равным ns2.afraid.org:

ЗЫЖ

Заметка не рекламная.

В данной статье описывается настройка TLS в Apache с использованием self-signed сертификата, что не годится для public-ресурсов, но вполне подойдёт для организации работы с вашим личным/командным сервером.

При написании заметки в качестве тестовой площадки использовался сервер под управлением Debian 6.0 и Apache 2.2.16.

Установка OpenSSL

Прежде чем приступать к настройке SSL-сайта в Apache, необходимо создать ключ шифрования, а также self-signed сертификат этого ключа. Данные действия выполняются утилитами, которые не входят в состав Apache и должны быть установлены отдельно, если их нет в вашей системе. В Debian/Ubuntu всё ставится одной командой:

# apt-get install openssl

В других дистрибутивах название пакета скорее всего будет таким же.

Генерация закрытого ключа и сертификата

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

Создайте каталог, в котором вы намереваетесь хранить закрытый ключ и сертификат сервера:

# mkdir -p /etc/apache2/ssl

Теперь можно сгенерировать закрытый ключ и self-signed сертификат для него:

# cd /etc/apache2/ssl
# openssl req -new -x509 -nodes -out server.crt -keyout server.key

где server.key — имя файла закрытого ключа, а server.crt — имя файла сертификата.

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

Generating a 1024 bit RSA private key
..............++++++
..............................................................++++++
writing new private key to '/etc/apache2/ssl/server.key'
-----
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:
Email Address []:

После того, как ключ и сертификат будут готовы, не забудьте ограничить доступ к файлу закрытого ключа:

# chmod 0600 /etc/apache2/ssl/server.key

Включение mod_ssl

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

# a2enmod ssl

а также включить работу виртуальных хостов на порту 443, отредактировав соответствующий участок файла /etc/apache2/ports.conf:

<IfModule mod_ssl.c>
 Listen 443
 NameVirtualHost *:443
</IfModule>

Настройка сайта Apache

Теперь, когда ключ и сертификат готовы, а поддержка SSL в Apache включена, можно приступать к настройке сайта. Создайте конфигурацию виртуального хоста для вашего защищённого сайта (предположим, что вы расположили его в каталоге /var/www/secure) в файле /etc/apache2/site-available/secure:

<IfModule mod_ssl.c>
<VirtualHost *:443>
 ServerName secure.localdomain
 ServerAdmin webmaster@localhost
 DocumentRoot /var/www/secure
 SSLEngine on
 SSLCertificateKeyFile /etc/apache2/ssl/server.key
 SSLCertificateFile    /etc/apache2/ssl/server.crt
</VirtualHost>
</IfModule>

Обратите внимание на директивы SSL:

• SSLEngine включает или отключает работу модуля mod_ssl;
• SSLCertificateKeyFile определяет путь к файлу закрытого ключа сервера;
• SSLCertificateFile определяет путь к файлу сертификата.

Конечно же, опций, отвечающих за настройку поведения mod_ssl гораздо больше и множество из них определены по умолчанию в файле /etc/apache2/mods-available/ssl.conf. Целью данной заметки являлось создание руководства из серии «за две минуты» и поэтому освещён необходимый минимум знаний. Желающим углубиться в раскопки недр работы и настройки TLS в Apache советую в первую очередь посетить официальную страницу документации, а также справочник по опциям mod_ssl.

Теперь, когда всё готово к работе, можно включать созданный виртуальный хост:

# a2ensite secure

и перезапускать Apache:

# /etc/init.d/apache2 restart

Проверка

Если всё прошло успешно и вы не получили никаких ошибок в результате перезапуска сервера, самое время проверить результаты работы. Открыв в браузере URL вашего сайта, вы должны увидеть предупреждение о риске для вашей безопасности в связи с тем, что сайт использует self-signed сертификат:

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

SparkleShare

SparkleShare — бесплатная утилита с открытым исходным кодом для организации совместной работы с файлами, разработанная таким образом, чтобы максимально упростить пользователям настройку и работу с программой. Программа создаёт в домашнем каталоге пользователя каталог с именем SparkleShare, к которому можно подключить множество удалённых каталогов для синхронизации, которые могут быть расположены на разных серверах. Помимо всего прочего SparkleShare обладает системой уведомлений, похожей на DropBox. Установить утилиту можно из PPA-репозитория:

$ mkdir -p ~/.ssh
$ sudo add-apt-repository ppa:warp10/sparkleshare
$ sudo apt-get update
$ sudo apt-get install sparkleshare libwebkit1.1-cil git-core

Первая команда нужна, если у вас нет каталога ~/.ssh, поскольку без него SparkleShare «вылетает». На webupd8 об это можно прочесть подробней. Если вашим Linux является не Ubuntu, вы можете собрать SparkleShare из исходных кодов, скаченных с соответствующей страницы проекта.

SpiderOak

SpiderOak — утилита для резервного копирования, разделения и синхронизации файлов, работающая под Windows, Mac и Linux. Сервис хранит файлы пользователей в зашифрованном виде, при этом ключ шифрования создаётся и хранится на клиентской стороне, так что даже сотрудники сервиса не смогут получить доступ к персональным данным своих клиентов. SpiderOak предлагает 2 гигабайта бесплатно и 10 долларов в месяц за каждые дополнительные 100 гигабайт. Некоторые части клиента являются OpenSource и владельцы сервиса планируют в ближайшем будущем открыть исходные коды целиком.

Загрузить SpiderOak для Windows, Mac и почти всех популярных версий Linux, включая Ubuntu, Debian, Fedora, CentOS/RHEL и Slackware, можно со страницы загрузок проекта.

Ubuntu One

Ubuntu One, собственный облачный сервис Canonical, не нуждается в представлении. Если вы являетесь пользователем Ubuntu, у вас, скорее всего, уже установлен клиент Ubuntu One. Клиент в Ubuntu 11.04 получил обновлённый интерфейс и предлагает бесплатно 2 GB после регистрации. Существует также версия клиента для Windows, находящаяся в данный момент в стадии публичного тестирования. Существенным недостатком Ubuntu One является пока что слабенькая поддержка сред, отличных от GNOME, а также проприетарная политика Canonical в отношении серверной части Ubuntu One. Больше информации вы можете получить в треде на askubuntu. Каждый желающий может подключиться к Ubuntu One, а также ознакомиться с существующими тарифными планами.

Wuala

Wuala — ещё один онлайн-сервис для хранения, резервного копирования, синхронизации и разделения файлов, предлагающий клиенты под Windows, Mac и Linux. Сервис предлагает бесплатно 1 гигабайт пространства изначально, код клиента закрыт. Для скачивания доступны deb-пакеты для Ubuntu и других Debian-based дистрибутивов, а также RPM-пакеты для  Fedora, Red Hat и CentOS.

Minus

Вероятно, самый простецкий из онлайн-хранилищ файлов. Установив клиентское приложение Minus для рабочего стола, вы получите возможность отправлять в онлайн-хранилище файлы путём старого-доброго Drag'n'Drop-а нужного контента на иконку приложения. Доступны клиенты для Mac, Linux, Windows, Windows Phone 7, Andorid, iPhone, а также расширения для Firefox и Chrome.

ZumoDrive

Облачный сервис, предлагающий 2 гигабайта бесплатного пространства зарегистрировавшимся пользователям. Клиент сервиса существует под Windows, Mac, Linux, iOS, Android и Palm webOS. Предлагаемые тарифные планы варьируются в диапазоне от 10 до 500 гигабайт по цене от 3 до 80 долларов в месяц. Для Linux доступны DEB и RPM-сборки.

TeamDrive

Проприетарный сервис, предназначенный для совместной работы с файлами, их синхронизации и хранения. Доступны клиенты под Windows, Mac и Linux. Как и многие другие, TeamDrive предлагает бесплатно 2 гигабайта дискового пространства. Среди интересностей можно отметить присутствие плагина для OpenOffice, призванного облегчить соместную работу над документами.

Источник: techdrivein.com

Собираетесь приобрести новый гаджет? Обзор HTC Desire HD, а также множества других популярных электронных девайсов поможет сделать вам правильный выбор перед покупкой.

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

Однако многие не обратили внимание на одно «но». Ваши файлы, хранящиеся на серверах DropBox, находятся там в открытом виде, то есть любой недобросовестный сотрудник DropBox или же умник, получивший доступ к содержимому их хранилища с помощью взлома, получит доступ к вашим файлам. Хорошо, конечно, если самым «страшным» среди ваших секретов окажется то, как вы с нарисованными усами спите в ванной на вечеринке друга, посвящённой дню системного администратора... А что, если у вас есть данные, закрытость которых от публичного доступа определяет побольше, вплоть до вашего благополучия и свободы? Что, если благодаря известным уязвимостям в DropBox, кто-то сможет получить то, что ему вовсе не предназначалось?

Рад вам представить Wuala — безопасное онлайн-хранилище файлов из Швейцарии. Во многом Wuala предоставляет те же возможности, что и DropBox, однако есть интересные дополнения, о которых мы с вами поговорим далее в этой статье, а пока — краткий перечень возможностей сервиса:

• Безопасность. Данные, хранящиеся на серверах Wuala, а также в локальном кэше клиента, установленного в вашем компьютере, надёжно зашифрованы. Ко всему прочему ваш пароль никогда не передаётся сервису, поэтому доступ к нему никто кроме вас получить не может (естественно, если вы его сами кому-нибудь не сообщите).
• Резервное копирование и контроль версий. Wuala позволяет хранить различные версии одних и тех же файлов, что даст вам возможность не беспокоиться в случае ненужного случайного удаления или изменения файлов.
• Синхронизация. При помощи этой функции вы сможете автоматически синхронизировать ваши файлы между несколькими компьютерами, что избавит вас от необходимости настраивать синхронизацию или же выполнять ручное копирование фалов между компьютерами.
• Доступ отовсюду. Вы сможете получить доступ к своим файлам из любой точки мира, таким образом вам не нужно постоянно таскать с собой ноутбук.
• Разделение доступа. При помощи Wuala вы сможете избавиться от необходимости отправлять файлы вашим  друзьям, коллегам и знакомым по почте.
• Совместная работа. Вы можете создавать группы пользователей, и предоставлять им ваши файлы для совместной работы, что опять-таки избавит вас от необходимости обмениваться с коллегами изменёнными версиями файлов по почте.
• Торговля дисковым пространством. Вы можете обменивать свободное дисковое пространство вашего компьютера на дополнительное пространство для вашей учётной записи на Wuala.

Ниже вы можете посмотреть промо-ролик Wuala на английском, наглядно демонстрирующий всё вышеперечисленное:

Установка

Клиент Wuala создан на Java и существует для нескольких платформ: Linux, Mac, Windows, Android и iPhone. В этой статье рассматривается установка Wuala под Ubuntu Linux 10.10, а на сайте сервиса вы сможете найти установщик или пакет для вашей платформы, если она отличается от рассматриваемой здесь.

Перейдите на сайт сервиса и кликните по большой красной кнопке Download:

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

После того, как файл будет сохранён, установите его удобным для вас способом. Я выбрал для этих целей Ubuntu Software Center:

Теперь, когда пакет установлен, ссылка на запуск приложения появилась в Gnome Menu:

Запустив приложение, необходимо создать новую учётную запись, если у вас ещё нет таковой:

Вы получите изначально 2 гигабайта дискового пространства вместо одного, если введёте при регистрации промо-код 7NKMKJCG3AP74GGKAPAB в поле «Promo code»

Если всё пройдёт успешно, перед вами откроется клиент Wuala, отображающий содержимое ваших данных, хранящихся на сервисе:

а также значок программы в системном лотке:

Всё, вот и вся установка!

Интеграция с файловой системой

У клиента Wuala есть возможность интегрироваться в файловую систему а-ля DropBox, то есть, для сохранения файлов на сервере Wuala, вам их нужно просто поместить в специальный каталог. Этот самый специальный каталог создаётся программой в домашнем каталоге пользователя, что мне не очень понравилось и я решил отключить эту опцию, а для управления файлами использовать возможности клиента Wuala.

Если вам, подобно мне, больше нравится именно такой вариант, откройте меню «Edit — Preferences...» и в разделе «General» снимите птичку «Enable filesystem integration», после чего перезапустите Wuala, кликнув правой кнопкой по значку программы в системном лотке, выбрав «Exit» и запустив её снова.

Добавление каталогов

Чтобы добавить в хранилище каталог с файлами, выберите в меню клиента «File — Add Folder to Wuala» и укажите нужный каталог с файлами:

и после нажатия «ОК» дождитесь добавления всех файлов:

Вуаля! Вот и наш каталог на серверах Wuala:

Просмотр свойств файлов и каталогов, комментарии

После того, как вы добавили файлы/каталоги в Wuala, вы можете просматривать их свойства при необходимости. Сделать это можно либо при помощи контекстного меню файла/каталога, выбрав «Properties...»:

либо развернув панель свойств, кликнув на небольшой выступающий треугольник в окне клиента справа:

Как видно, в окне свойств в отличие от панели предлагается больше информации и различных действий. В частности, вы можете увидеть и скопировать ссылку для доступа к объекту через веб, и сменить область видимости объекта (об этом — дальше). Зато в панели свойств вы можете добавлять комментарии к объектам, чего нельзя сделать непосредственно из окна свойств. Также комментарии можно добавлять из контекстного меню объекта, выбрав «Add Comment...».

Корзина

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

Резервные копии

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

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

Чтобы создать объект резервного копирования, необходимо в верхней панели клиента (или в меню «File») нажать кнопку «New» и в появившемся меню выбрать «Backup...», после чего в появившемся окне выбрать источник для создания резервных копий, указать каталог для хранения бэкапов на сервисе, опционально указать фильтр для отсева ненужных файлов и частоту созданий копий:

После нажатия на кнопку «ОК» окно клиента примет примерно такой вид, показывая в верхней части информацию о резервной копии:

Теперь Wuala будет наблюдать за изменениями в файлах указанного вами каталога и при необходимости отправлять изменения на сервис. Если вдруг в какой-то момент вам понадобится восстановить из резервной копии файл или каталог в каком-то состоянии, вы сможете сделать это при помощи контекстного меню:

Синхронизация

Синхронизацию часто путают с резервным копированием из-за того, что многие рассматривают резервное копирование как «процесс создания копии чего-то где-то», что не совсем правильно. Резервное копирование, как правило, подразумевает контроль версий файлов. А вот синхронизация — нет. Задача синхронизации файлов состоит в том, чтобы поддерживать одинаковость состояний файлов и каталогов во всех синхронизируемых точках. В этом смысле данная функция Wuala полностью аналогична функции DropBox.

Чтобы создать объект синхронизации, необходимо в верхней панели клиента (или в меню «File») нажать кнопку «New» и в появившемся меню выбрать «Sync...», после чего в появившемся окне выбрать источник синхронизации и указать каталог для хранения объекта синхронизации на сервисе:

После нажатия на кнопку «ОК» вы увидите созданный объект синхронизации, а в верхней панели — информацию о том, между сколькими компьютерами он синхронизируется:

Совместная работа

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

Чтобы создать группу, в верхней панели клиента (или в меню «File») нажмите кнопку «New» и в появившемся меню выберите «Group...». В следующем окне необходимо выбрать имя для вашей группы, её тип и нажать «Create»:

Обратите внимание на опцию «Web access through secret weblink», отметив которую вы сможете предоставить доступ другим через веб к файлам группы при помощи секретной ссылки. При необходимости вы можете создать открытую группу, переставив переключатель на «Public Group». Файлы такой группы будут доступны для чтения всем, в том числе и поисковым ботам и к группе смогут присоединяться все желающие. Присоединившиеся к группе пользователи получат доступ к файлам на запись.

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

Приглашённые в группу пользователи могут иметь одну из трёх ролей. Имена и права этих ролей можно редактировать в окне управления группой, доступном из контекстного меню группы «Manage Group...»:

Используя переключатель «Default Role for new Members», вы можете определять роль по умолчанию для новых участников вашей группы.

Общий доступ к файлам

Часто бывает нужно поделиться с кем-то парой-тройкой файлов, при этом нет никакого желания заморачиваться с отправкой файла электронной почтой (ох уж эта лень человеческая!). Wuala предлагает простой и быстрый способ предоставления общего доступа к вашим файлам (точнее, каталогам). Кликните по нужному каталогу правой кнопкой и в контекстном меню выберите «Share this Folder — Sharing & Access...»:

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

Торговля пространством

Если у вас какое-то количество свободного дискового пространства, которым вы не прочь поделиться с другими, вы можете сделать это в обмен на дополнительное пространство от Wuala для себя. Единственное условие: вы должны быть в онлайне не менее 4 часов в сутки. Для того, чтобы включить опцию торговли пространством, откройте «Edit — Preferences...», перейдите в раздел «Trading» и поставьте птичку «Trade up to», выбрав количество гигабайт, которые вы готовы предоставить народу в раздельное пользование:

Локализация

Ах, да, чуть не забыл! Интерфейс клиента Wuala переведён на множество языков, среди которых есть и русский:

Резюме

Отличный сервис, во многом превосходящий DropBox. Гибкость и безопасность, а также недорогие расценки (от 19 евро за 10 гигабайт в год) делают Wuala отличным решением для тех, кому нужно надёжное хранилище для своих файлов.

Nautilus

Файловый менеджер GNOME имеет встроенную поддержку протокола DAV, поэтому его пользователям ничего доустанавливать не нужно и всё, что нужно сделать — это в панели адреса ввести URL WebDAV-ресурса, к которому необходимо подключиться. Откройте окно Nautilus и нажмите Ctrl+L, чтобы переключить панель адреса из breadcrumb-режима в режим ввода текста и укажите URL нужного ресурса:

Укажите имя пользователя и пароль для подключения:

И получаем доступ к нашему ресурсу:

Konqueror

Пользователи KDE также не обделены возможностью доступа к WebDAV-содержимому. Принцип подключения ничем не отличается от подключения из Nautilus, за исключением того, что в URL ресурса необходимо указывать webdav:// в качестве имени протокола, а не dav://, как это имеет место быть в Nautilus.

Microsoft Windows XP

Подключиться к WebDAV-ресурсу в этой ОС также возможно, используя встроенные средства. Прежде, чем подключаться к ресурсу, убедитесь в том, что в вашей системе разрешён запуск службы «Веб-клиент» («Web-Folders»):

Далее, необходимо открыть «Сетевое окружение» и запустить аплет «Новое место в сетевом окружении»:

Указываем URL ресурса (можно использовать HTTPS, если ваш сервер поддерживает его):

Авторизуемся:

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

Вот и наш ресурс:

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

Windows 7

К сожалению, на данный момент у меня нет возможности сделать скриншоты из этой ОС, поэтому наглядно процесс подключения WebDAV-ресурса в Microsoft Windows 7 я опишу чуть позже в этой же статье, как только появится такая возможность.

Ничто не вечно в этом мире, а техника и подавно! Срочный ремонт АйФонов в Москве, а также другой разнообразной электроники, включая КПК, мобильные телефоны, игровые приставки, ноутбуки и многое другое для вас с удовольствием и качественно выполнят сотрудники сети сервисных центров mobi03.ru.

В сегодняшней заметке мы с вами рассмотрим настройку WebDAV-каталога на сервере www.example.com. Каталог будет доступен по URL http://www.example.com/webdav. В процессе написания заметки в качестве тестовой платформы использовалась Ubuntu Server 10.04.2.

Первым делом необходимо включить дополнительные модули Apache2, нужные для работы WebDAV. А, ну и сам Apache2 установить тоже не помешает, если он у вас ещё не установлен ;)

# apt-get install apache2
# a2enmod dav_fs
# a2enmod dav

После того, как необходимые модули включены (Apache пока не перезапускаем, рано), создайте виртуальный хост, который будет обслуживать наш WebDAV-каталог. В моём примере конфигурация виртуального хоста располагается в /etc/apache2/sites-available/example.com:

<VirtualHost *:80>
        ServerAdmin webmaster@example.com
        ServerName example.com
        ServerAlias www.example.com
        DocumentRoot /home/srw/example.com
        <Directory /home/srw/example.com>
                Options Indexes MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>
</VirtualHost>

После того, как виртуальный хост создан, создайте каталог для хранения файлов хоста и присвойте ему соответствующие Apache владельца и группу-владельца:

# mkdir /home/srw/example.com
# chown www-data.www-data /home/srw/example.com

Активируйте виртуальный хост:

# a2ensite example.com

Проверьте конфигурацию Apache:

# apache2ctl configtest

И после этого перезагрузите конфигурацию веб-сервера:

# service apache2 reload

После этого, если всё корректно настроено, вы должны увидеть содержимое каталога /home/srw/example.com по URL http://www.example.com/, открыв его в браузере.

Далее необходимо настроить авторизацию доступа к каталогу WebDAV, если конечно вы не хотите, чтобы он был доступен всем подряд. Для настройки авторизации автор предлагает использовать метод Digest Authentication, который хотя и может не поддерживаться старыми клиентами, однако предотвратит отправку паролей в открытом виде. Для этого необходимо включить модуль Apache, реализующий данный метод:

# a2enmod auth_digest

И создать файл паролей:

# htdigest -c /home/srw/.passwd webdav-example myuser

Вам будет предложено дважды ввести пароль для нового пользователя myuser.

Почти всё готово, осталось лишь добавить в конфигурацию виртуального хоста /etc/apache2/sites-available/example.com директивы, включающие поддержку WebDAV и авторизации:

<VirtualHost *:80>
        ServerAdmin webmaster@example.com
        ServerName example.com
        ServerAlias www.example.com
        DocumentRoot /home/srw/example.com
        <Directory /home/srw/example.com>
                Options Indexes MultiViews
                AllowOverride None
                Order allow,deny
                Allow from All
        </Directory>
        <Files ".passwd">
                Order allow,deny
                Deny from All
        </Files>
        <Location />
           DAV On
           AuthType Digest
           AuthName "webdav-example"
           AuthDigestProvider file
           AuthUserFile  /home/srw/.passwd
           Require valid-user
       </Location>
</VirtualHost>

Ещё раз проверяем конфигурацию Apache:

# apache2ctl configtest

И перезагружаем:

# service apache2 reload

Всё! Теперь у вас есть полноценный WebDAV-ресурс и самое время проверить, как он работает и с чем его едят. Об этом — в следующей статье.

По мотивам debian-administration.org

Всем поклонникам и просто пользователям мобильных телефонов известной марки посвящается. Темы для Nokia, картинки, игры, видео, рингтоны и многое-многое другое на сайте Nokia-X.Ru.

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

Исходные данные

В качестве PHP-сценария для проведения тестов использовался небольшой скрипт, выбирающий все строки из таблицы БД MySQL и выводящий результаты при помощи var_dump ():

$oPDO = new PDO("mysql:server=localhost;dbname=test;", 'user', 'password');
$oQRes = $oPDO->query("SELECT * FROM test1");
var_dump($oQRes->fetchAll());

Структура таблицы test1 БД следующая:

+-------+---------+------+-----+---------+----------------+
| Field | Type    | Null | Key | Default | Extra          |
+-------+---------+------+-----+---------+----------------+
| id    | int(11) | NO   | PRI | NULL    | auto_increment |
| name  | text    | YES  |     | NULL    |                |
+-------+---------+------+-----+---------+----------------+

Таблица содержит 10000 записей, где в каждом поле name записан MD5-хеш случайного числа в диапазоне от 0 до time (). URL сценария, работающего под Apache — http://test.ashep:80/test.php. Давайте посмотрим при помощи siege как сервер будет обрабатывать запросы к этому сценарию.

Прямые запросы к Apache

Эмулируем 10 серий по 10 одновременных запросов:

$ siege -c 10 -r 10 http://test.ashep:80/test.php
Transactions:		         100 hits
Availability:		      100.00 %
Elapsed time:		      109.66 secs
Data transferred:	       32.65 MB
Response time:		       10.30 secs
Transaction rate:	        0.91 trans/sec
Throughput:		        0.30 MB/sec
Concurrency:		        9.39
Successful transactions:         100
Failed transactions:	           0
Longest transaction:	       12.76
Shortest transaction:	        3.66

Сервер успешно обработал все запросы, однако время на обработку каждого составило в среднем 10,3 секунд.

Проксирование через Nginx

Теперь создадим реверс-прокси сервер в Nginx так, как мы это делали в предыдущей статье, в качестве upstream-сервера будем использовать наш Apache по http://test.ashep:80.

server {
    listen 8080;
    server_name test.ashep;
    access_log /var/log/nginx/test.access_log;
    error_log /var/log/nginx/test.error_log;
    location / {
        proxy_pass http://test.ashep:80;
    }
}

Повторим тест, на этот раз уже через Nginx:

$ siege -c 10 -r 10 http://test.ashep:8080/test.php
Transactions:		         100 hits
Availability:		      100.00 %
Elapsed time:		      104.97 secs
Data transferred:	       32.65 MB
Response time:		        9.77 secs
Transaction rate:	        0.95 trans/sec
Throughput:		        0.31 MB/sec
Concurrency:		        9.31
Successful transactions:         100
Failed transactions:	           0
Longest transaction:	       14.54
Shortest transaction:	        2.89

Результаты примерно те же. Логично, поскольку Nginx всего лишь транслирует запросы к upstream-серверу, ничего при этом не кэшируя.

Кэширующее проксирование через Nginx

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

Определять кэш можно лишь в контексте секции http, которая, например, в моём Debian описана в /etc/nginx/nginx.conf. Для определения кэша используется опция proxy_cache_path, которая имеет следующий формат:

proxy_cache_path path [levels=number] keys_zone=zone_name:zone_size [inactive=time] [max_size=size];

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

• path определяет место в файловой системе, где будет храниться кэш. Кэш в Nginx хранится в виде обычных файлов, каждый из которых хранит содержимое ответа на какой-то запрос. URL запроса хешируется в MD5 и полученная строка используется в качестве имени файла кэша, а также ключа, по которому Nginx будет отыскивать нужный фрагмент кэша;
• при помощи levels можно определить количество уровней вложенности каталогов с файлами кэша. Формат описания уровней может быть одним из: 'X', 'X:X' или 'X:X:X', что соответственно определяет один, два или три уровня вложенности каталогов. Каждая 'X' является единицей или двойкой и определяет количество символов в имени каталога соответствующего уровня;
• значением параметра keys_zone определяется имя кэша (zone_name), на которое можно ссылаться из других участков конфигурации сервера, а также её размер (zone_size);
• при помощи необязательного параметра inactive определяется время жизни объектов кэша, если к ним не было запросов. Т. е. если в течение указанного периода времени объект кэша ни разу не запрашивался — он подлежит удалению. Значение параметра inactive по умолчанию равно 10 минутам (10m);
• значение необязательного параметра max_size определяет размер кэша, больше которого ему не будет позволено «раздуваться».

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

proxy_cache_path /var/cache/nginx levels=2:2 keys_zone=default:100m;

Приведённой выше строкой создаётся двухуровневый кэш в каталоге /var/cache/nginx с именем 'default' и размером 100 мегабайт. Теперь определённый кэш default можно использовать в конфигурации серверов Nginx. Слегка дополненная конфигурация сервера, приводившаяся выше:

server {
    listen 8080;
    server_name test.ashep;
    access_log /var/log/nginx/test.access_log;
    error_log /var/log/nginx/test.error_log;
    location / {
        proxy_pass http://test.ashep:80;
        proxy_cache default;
        proxy_cache_valid   200 302 10m;
        proxy_cache_valid   404 1m;
    }
}

Обратите внимание на две новых опции. При помощи параметра proxy_cache мы указываем Nginx какой кэш необходимо использовать при кэшировании данных от upstream-сервера, в данном случае — это 'default', определённый ранее в /etc/nginx/nginx.conf. Опция proxy_cache_valid определяет время в течение которого не устаревшими будут считаться объекты кэша, полученные полученные в результате ответов upstream-сервера. Формат опции следующий:

proxy_cache_valid код_ответа [код_ответа код_ответа ...] время

Таким образом ответы upstream-сервера с кодами 200 и 302 будут кэшироваться на 10 минут, а ошибки 404 — в течение одной минуты.

Сохранив конфиг-файлы и перезапустив Nginx, попробуем провести нагрузочное тестирование с включённым кэшированием:

$ siege -c 10 -r 10 http://test.ashep:8080/test.php
Transactions:		         100 hits
Availability:		      100.00 %
Elapsed time:		       15.68 secs
Data transferred:	       32.65 MB
Response time:		        0.73 secs
Transaction rate:	        6.38 trans/sec
Throughput:		        2.08 MB/sec
Concurrency:		        4.65
Successful transactions:         100
Failed transactions:	           0
Longest transaction:	        9.51
Shortest transaction:	        0.02

Среднее время ответа от сервера составило 0,73 секунды. Неплохо, правда? ;)

Siege умеет выполнять многопоточное нагрузочное тестирование web-серверов по протоколу HTTP (S)/1.0/1.1 методами GET и POST. Утилита симулирует параллельные запросы к веб-серверу на протяжении заданного времени и в конце теста вычисляет следующие показатели:

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

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

Siege присутствует в репозиториях всех популярных дистрибутивов, так что вы должны без труда установить её в своей системе. Если же ваш дистрибутив не располагает утилитой в среди включённых в комплект пакетов, вы можете самостоятельно собрать siege из исходных кодов, полученных со страницы проекта на freshmeat.net.

Условия тестирования, приводимого в этой заметке, те же самые, что и в предыдущей. Следуя схеме тестирования, определённой в предыдущей статье, для начала выполним 1000 последовательных запросов статического HTML-файла:

$ siege -b -c 1 -r 1000 http://aserver.ashep:80/test.html

Здесь:

• опция '-b' переключает утилиту в режим тестирования производительности, т. е. siege не будет делать паузу случайной длительности между запросами;
• опция '-c' определяет количество параллельных запросов, отправляемых за один раз. В нашем случае — один;
• при помощи опции '-r' определяется количество повторов запроса.

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

Transactions:		        1000 hits
Availability:		      100.00 %
Elapsed time:		       10.97 secs
Data transferred:	        8.95 MB
Response time:		        0.01 secs
Transaction rate:	       91.16 trans/sec
Throughput:		        0.82 MB/sec
Concurrency:		        1.00
Successful transactions:        1000
Failed transactions:	           0
Longest transaction:	        0.03
Shortest transaction:	        0.00

Из результатов теста видно, что:

• общее количество транзакций составило 1000;
• «доступность» (т. е. процент успешных сокет-подключений ) сервера составила 100%;
• тест занял 10,97 секунд;
• было передано 8,95 мегабайт данных;
• среднее время, потребовавшееся серверу для ответа составил 0,01 секунды;
• в среднем за одну секунду удалось выполнять 91,16 транзакций;
• средняя скорость обмена данными с сервером составила 0,82 мегабайта в секунду;
• параллельно сервер обрабатывал один запрос;
• было успешно (HTTP-код ответа сервера <400) обработано 1000 транзакций;
• не удалось обработать (HTTP-код ответа сервера >=400) обработано 0 транзакций;
• длительность самой длинной по времени транзакции составила 0,03 секунды;
• длительность самой длинной по времени транзакции составила 0,00 секунд.

Попробуем теперь выполнить запрос того же URL 1000 раз, только теперь одновременно будем отправлять по 200 запросов за раз:

$ siege -b -c 200 -r 5 http://aserver.ashep:80/test.html

Transactions:		        1000 hits
Availability:		      100.00 %
Elapsed time:		       12.69 secs
Data transferred:	        8.95 MB
Response time:		        1.70 secs
Transaction rate:	       78.80 trans/sec
Throughput:		        0.71 MB/sec
Concurrency:		      134.16
Successful transactions:        1000
Failed transactions:	           0
Longest transaction:	       10.26
Shortest transaction:	        0.01

В результатах этого теста видим значительно возросшее время, требуемое серверу для ответа — 1,7 секунды против 0,01 в предыдущем тесте. При этом на 12 снизилось количество транзакций обрабатываемых за одну секунду. Из генерируемых двухсот одновременных запросов сервер в среднем смог обрабатывать лишь 134,16. Но при всём этом доступность сервера составила 100%, т. е. сервер не был загружен настолько, что был не в состоянии принимать входящие сетевые соединения.

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

$ siege -c 200 -r 5 http://aserver.ashep:80/test.html

Transactions:		        1000 hits
Availability:		      100.00 %
Elapsed time:		       12.29 secs
Data transferred:	        8.95 MB
Response time:		        1.52 secs
Transaction rate:	       81.37 trans/sec
Throughput:		        0.73 MB/sec
Concurrency:		      124.05
Successful transactions:        1000
Failed transactions:	           0
Longest transaction:	        9.32
Shortest transaction:	        0.01

Как видно, некоторые показатели несколько улучшились, за счёт ухудшения показателя Concurrency, что логично. При необходимости вы можете увеличить диапазон случайно временной задержки между отправкой запросов при помощи опции '-d'. Например, чтобы siege выдерживал случайную паузу между запросами в пределах между 0 и 5 секундами:

$ siege -d 5 -c 200 -r 5 http://aserver.ashep:80/test.html

Если вам необходимо, чтобы siege «побродил» по вашему серверу вместо того, чтобы тупо долбиться на один и тот-же URL, создайте текстовый файл со списком URL, которые необходимо посетить в процессе тестирования и укажите путь к нему при помощи опции '-f':

$ siege -d 5 -c 200 -r 5 -f ~/urls.txt

Чтобы заставить утилиту брать URL из файла не последовательно, а случайно, добавьте опцию '-i':

$ siege -d 5 -c 200 -r 5 -i -f ~/urls.txt

При необходимости вы можете ограничить время, которое будет отведено siege для выполнения теста, при помощи опции '-t'. Обратите внимание, что эта опция имеет приоритет перед опцией '-r'. При указании значения опции '-t' можно использовать суффиксы 's', 'm' и 'h' для определения времени в секундах, минутах и часах соответственно. Например:

$ siege -d 5 -c 200 -t 10s http://aserver.ashep:80/test.html

Приготовления

Утилита ab поставляется в комплекте с Apache, так что если он у вас установлен — у вас есть уже всё необходимое. В сегодняшней заметке мы будем упражняться на установленном в конфигурации по умолчанию Apache 2.2.14 в Ubuntu Server 10.04.2 LTS. Конфигурацию оборудования (кому интересно — оно довольно слабенькое) и настроек Apache приводить не буду, ибо нет смысла в рамках данной статьи. Целью данной заметки является небольшой обзор утилиты ab, а не анализ производительности конкретного ПО на конкретном железе. В рамках примера произведём тест отдачи сервером:

• HTML-файла test.html размером 177 байт;
• небольшого PHP-сценария test.php, код которого приведён ниже.

Все файлы размещены в корне DocumentRoot сервера. Код PHP-сценария использовался такой:

phpinfo();

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

Запрос html-файла

Итак, начнём. Для начала давайте организуем нагрузку нашему серверу в одну тысячу последовательных запросов. Для указания числа запросов используется опция '-n'. Номер порта можно не указывать, если он не отличен от 80-го:

$ ab -n 1000 http://aserver.ashep:80/test.html

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

Benchmarking aserver.ashep (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Далее вы увидите информацию о версии ПО сервера, его имени, какой документ загружался и каков его размер:

Server Software:        Apache/2.2.14
Server Hostname:        aserver.ashep
Server Port:            80
Document Path:          /test.html
Document Length:        177 bytes

И далее, собственно, результаты:

Concurrency Level:      1
Time taken for tests:   1.500 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      453000 bytes
HTML transferred:       177000 bytes
Requests per second:    666.58 [#/sec] (mean)
Time per request:       1.500 [ms] (mean)
Time per request:       1.500 [ms] (mean, across all concurrent requests)
Transfer rate:          294.88 [Kbytes/sec] received

Как видно:

• Concurrency Level: количество одновременно-отправляемых запросов — 1;
• Time taken for tests: тысяча запросов к серверу заняла 1,5 секунды;
• Complete requests: успешно получен ответ на всю тысячу запросов;
• Failed requests: неудавшихся запросов — ноль;
• Write errors: ошибок записи — ноль;
• Total transferred: общий объём переданных данных: 453000 байт;
• HTML transferred: из них «полезного» HTML — 177000 байт;
• Requests per second: среднее количество запросов в секунду составило 666.58
• Time per request: среднее время на один запрос 1,5 миллисекунды
• Transfer rate: скорость обмена данными с сервером составила 294.88 килобайта в секунду.

Далее в выводе идёт информация о времени, затраченном на сетевые подключения:

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       2
Processing:     1    1   0.7      1      13
Waiting:        1    1   0.5      1       8
Total:          1    1   0.7      1      14

И на обслуживание запросов сервером:

Percentage of the requests served within a certain time (ms)
  50%      1
  66%      1
  75%      1
  80%      1
  90%      2
  95%      3
  98%      4
  99%      5
 100%     14 (longest request)

Как видим, сервер успешно справился с тысячей последовательных загрузок статического файла небольшого размера. Давайте теперь посмотрим, как сервер поведёт себя, если вся эта тысяча запросов будет направлена к нему одновременно, указав это при помощи опции '-c':

$ ab -n 1000 -c 1000 http://aserver.ashep:80/test.html
Benchmarking aserver.ashep (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
apr_socket_recv: Connection reset by peer (104)
Total of 804 requests completed

Здесь тест не смог быть завершён по причине того, что после одновременной отправки 804 запросов сервер перестал принимать входящие соединения. Опытным путём, снижая количество одновременных запросов, было установлено что безболезненно мой Apache в текущей конфигурации может обрабатывать  примерно 300 одновременных не Keep-Alive запросов.

$ ab -n 1000 -c 300 http://aserver.ashep:80/test.html

Server Software:        Apache/2.2.14
Server Hostname:        aserver.ashep
Server Port:            80

Document Path:          /test.html
Document Length:        55716 bytes

Concurrency Level:      300
Time taken for tests:   13.658 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      55998000 bytes
HTML transferred:       55716000 bytes
Requests per second:    73.22 [#/sec] (mean)
Time per request:       4097.409 [ms] (mean)
Time per request:       13.658 [ms] (mean, across all concurrent requests)
Transfer rate:          4003.91 [Kbytes/sec] received

Connection Times (ms)
 min  mean[+/-sd] median   max
Connect:        0   17 190.0      6    3015
Processing:   224 1659 2376.3    644   13644
Waiting:      212 1628 2360.6    621   13636
Total:        230 1677 2379.8    648   13650
Percentage of the requests served within a certain time (ms)
 50%    648
 66%    654
 75%    668
 80%    785
 90%   7003
 95%   7243
 98%   7384
 99%   7425
 100%  13650 (longest request)

Естественно, с Keep-Alive запросами дело будет обстоять ещё хуже, поскольку занимаемые Apache'м ресурсы сервера освобождаются не так быстро. Для выполнения теста с Keep-Alive-соединениями просто добавьте опцию '-k':

$ ab -k -n 1000 -c 1000 http://aserver.ashep:80/test.html

Запрос PHP-сценария

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

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

$ ab -n 1000 -c 300 http://aserver.ashep:80/test.php

Server Software:        Apache/2.2.14
Server Hostname:        aserver.ashep
Server Port:            80

Document Path:          /test.php
Document Length:        55469 bytes

Concurrency Level:      300
Time taken for tests:   44.110 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      55660000 bytes
HTML transferred:       55469000 bytes
Requests per second:    22.67 [#/sec] (mean)
Time per request:       13232.931 [ms] (mean)
Time per request:       44.110 [ms] (mean, across all concurrent requests)
Transfer rate:          1232.28 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  198 934.7      0    9021
Processing:   295 5910 9113.3   2457   44098
Waiting:      227 5711 9149.6   2273   44039
Total:        301 6108 9102.0   2470   44106
Percentage of the requests served within a certain time (ms)
  50%   2470
  66%   2983
  75%   4412
  80%   5575
  90%  14254
  95%  32750
  98%  33302
  99%  33589
 100%  44106 (longest request)

Как видим, сервер успешно справился с запросами, однако время их обработки существенно возросло, составив в среднем 44 миллисекунды на запрос, в то время как отдача небольшого HTML-файла примерно такого же размера составляла всего лишь 13 миллисекунд.

Устали настраивать сервера? Самое время приятно провести время! Большая коллекция игр для iPhone и iPad на proiphone.com.ua не заставят вас скучать!

Балансировка нагрузки может быть полезной в случаях, когда ваш один-единственный сервер уже не справляется с возложенными на него задачами в силу возросшего количества запросов. В Nginx роль балансировщика реализует модуль HttpUpstreamModule, обычно по умолчанию содержащийся  в сборке Nginx. Тем, кто не читал предыдущих моих статей об Nginx и тем, что забыл, напоминаю о том, что все действия, описываемые в этой серии статей, тестировались и выполнялись на Debian 5 «Lenny» и в незначительной степени могут отличаться от требуемых в вашей системе.

Простая конфигурация

Допустим, вы разместили ваше приложение на нескольких серверах, пусть это будут три сервера с именами myserv-1.local, myserv-2.local и myserv-3.local, расположенные в вашей локальной сети (конечно же, на самом деле без разницы, где они будут размещаться). Для того, чтобы описать такое «облако» из трёх серверов в Nginx используется опция upstream:

upstream mySuperCloud {
  server myserv-1.local;
  server myserv-2.local;
  server myserv-3.local;
}

Описанное таким образом «облако» из нескольких upstream-серверов теперь можно использовать в качестве значения параметра proxy_pass, рассмотренного в предыдущей статье. Везде, где Nginx будет наталкиваться на ссылку (в нашем случае — «mySuperCloud»), он будет по алгоритму Round-Robin выбирать следующий сервер и выполнять обратное проксирование к нему и от него. Таким образом, теперь, описывая виртуальный хост, вы можете сослаться на ваше «облако»:

server {
  listen 192.168.0.1:80;
  access_log /var/log/nginx/proxy.log;
  location / {
    proxy_pass http://mycloud;
  }
}

Привязка клиента к серверу

Часто бывает нужно, чтобы один и тот же клиент, начав делать запросы к какому-то определённому серверу, не переключался на другие. Для этого в Nginx предусмотрена опция ip_hash. Если она определена, сервер будет запоминать IP-хеши клиентов и стараться проксировать каждого из них на один и тот же сервер.

upstream mySuperCloud {
  ip_hash;
  server myserv-1.local;
  server myserv-2.local;
  server myserv-3.local;
}

Исключение сервера из «облака»

Если какой-то сервер по каким-то причинам вам необходимо отключить, чтобы Nginx не проксировал к нему клиентов, воспользуйетсь опцией down:

upstream mySuperCloud {
  server myserv-1.local;
  server myserv-2.local down;
  server myserv-3.local;
}

Определение «веса» сервера

«Вес» сервера, грубо говоря, определяет насколько часто сервер будет использоваться. Например, вес сервера myserv-1.local равен 3, вес myserv-2.local равен 1 и вес myserv-3.local равен 2. В этом случае Nginx проксирует первых трёх клиентов к серверу myserv-1.local, четвёртого — к myserv-2.local, а пятого и шестого — к myserv-2.local, после чего круг начнётся сначала. Для определения веса сервера используется директива weight, значение по умолчанию которой равно единице.

upstream mySuperCloud {
  server myserv-1.local weight=3;
  server myserv-2.local;
  server myserv-3.local weight=2;
}

Автоотключение серверов

Если какой-то из upstream-серверов перестанет отвечать на запросы, то подключение к нему станет невозможным. Nginx в этом случае переключиться на использование следующего сервера из «облака», однако каждый раз будет пытаться подключаться к неработающему серверу, растрачивая время. При помощи директивы max_fails параметра server можно определить максимально-допустимое количество неудачных попыток подключения к upstream-серверу, после чего тот будет считаться нерабочим и запросы к нему прекратятся. По умолчанию значение этого параметра равно единице, то есть после одной неудачной попытки Nginx на определённое время прекратит попытки новых подключений с нерабочему серверу. Это «определённое время» определяется значением опции fail_timeout, по умолчанию равным 10 секундам.

upstream mySuperCloud {
  server myserv-1.local max_fails=3 fail_timeout=120;
  server myserv-2.local;
  server myserv-3.local;
}

Резервные серверы

Под понятием «резервный» в Nginx выступает сервер, который используется тогда, и только тогда, когда все «не резервные» upstream-серверы определены как нерабочие, т. е. не отвечающие на запросы. Резервные серверы отмечаются с помощью директивы backup:

upstream mySuperCloud {
  server myserv-1.local;
  server myserv-2.local;
  server myserv-3.local;
  server backup-server-1.local backup;
  server backup-server-2.local backup;
}

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

Используя обратное проксирование вы можете:

• скрыть инфраструктуру ваших серверов, обслуживающих сайт;
• использовать application firewall, что даст вам централизованно анализировать входящий/исходящий трафик, не нагружая этим upstream-серверы;
• переместить SSL с upstream-серверов на прокси;
• балансировать нагрузку между upstream-серверами;
• кэшировать статический и динамический контент, сжимать отправляемые данные самостоятельно, снижая общую нагрузку на upstream-серверы;

В Nginx функционал проксирования обеспечивается модулем HttpProxy, который компилируется по умолчанию, если при сборке Nginx вы явно не отключили его. Во всех современных дистрибутивах Nginx поставляется собранным с поддержкой проксирования, так что обычно никаких лишних телодвижений делать не нужно. Тем, кто не читал предыдущих моих статей об Nginx и тем, что забыл, напоминаю о том, что все действия, описываемые в этой серии статей, тестировались и выполнялись на Debian 5 «Lenny» и в незначительной степени могут отличаться от требуемых в вашей системе.

Итак, давайте начнём экспериментировать!

Допустим, у нас имеется два сервера:

• frontend-сервер Nginx, IP-адрес 192.168.0.1, порт 80;
• upstream-сервер Apache2, IP-адрес 192.168.0.2, порт 80;

Начнём с малого: настроим проксирование абсолютно всех запросов, приходящих на frontend-сервер к upstream-серверу. Создайте отдельный файл конфигурации виртуальных хостов в /etc/nginx/sites-available/proxy со следующим содержимым:

server {
  listen 192.168.0.1:80;
  access_log /var/log/nginx/proxy.log;
  location / {
    proxy_pass http://192.168.0.2;
  }
}

Не забудьте сделать соответствующий симлинк в каталог /etc/nginx/sites-enabled/ и перезапустить сервер:

# ln -s /etc/nginx/sites-available/proxy /etc/nginx/sites-enabled/proxy
# /etc/init.d/nginx restart

Как видите, ничего революционно нового. Уже знакомые директивы server и location. Что нового, так это директива proxy_pass. Вложенная в location, она определяет URL сервера, к которому будет выполняться проксирование.

От рассмотренной выше конфигурации на практике толку мало, разве что Nginx установлен у вас на файрволе и нет прямого доступа к upstream-серверу из Интернет.

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

server {
  listen 192.168.0.1:80;
  access_log /var/log/nginx/proxy.log;

  location / {
    proxy_pass http://192.168.0.2;
  }
  location ~* \.(gif|jpg|jpeg|png)$ {
     proxy_pass http://192.168.0.3;
   }
}

Выполнять проксирование вовсе необязательно к другим серверам, это можно делать и в пределах localhost'а. Например, у вас на сервере работает Apache, довольно сильно нагруженный каким-нибудь PHP-приложением. Зачем нагружать Apache ещё больше, поручая ему ещё и отдачу статических файлов? Не лучше ли вручить бразды правления статическим контентом Nginx'у, который с этой задачей справляется на порядок быстрее.

server {
  listen 192.168.0.1:80;
  access_log /var/log/nginx/proxy.log;

  location / {
    root /var/www/;
  }
  location ~* \.php {
    proxy_pass http://127.0.0.1:8080;
  }
}

Обратите внимание на содержимое второго location'a: при запросе php-файлов, Nginx будет проксировать запрос к локальному интерфейсу, на порт 8080, то есть конфигурацию вашего Apache необходимо изменить, чтобы он ожидал соединения на указанном адресе и порту.

На сегодня пока всё. Но это далеко не всё, что касается обратного проксирования. Предвкушая возгласы «тема сисек не раскрыта», сообщаю о том, что в будущих статьях об Nginx планируется рассмотреть настройку кэширования, балансировку нагрузки к upstream-серверам, а также, я надеюсь, многое-многое другое. Stay tuned ;-)

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

Предотвращение утечки IPv6

В своих экспериментах мы будем использовать глобальные IPv6-адреса из диапазона, предназначенного для использования в Интернет. Сегодня, когда провайдеры не поддерживают и не выдают IPv6-адреса своим клиентам, такие эксперименты не должны вызвать каких-либо проблем. Однако на всякий случай, всё же заблокируйте на вашем маршрутизаторе пропуск IPv6-пакетов наружу. Если ваш роутер работает под управлением Linux, то вы можете заблокировать весь IPv6-трафик следующими командами:

# ip6tables -P OUTPUT DROP
# ip6tables -p INPUT DROP
# ip6tables -p FORWARD DROP

Присваивание глобальных IPv6-адресов

Адреса link-local, которыми мы пользовались в первой статье довольно ограничены в применении. В реальной жизни нам понадобятся глобальные unicast-адреса. Такими адресами являются адреса из области 2000::/3. Любознательные люди могут знать, что адреса из области 2001:0DB8::/32 предназначены для использования в экспериментах, так что их мы и будем использовать. Давайте присвоим реальный IP-v6-адрес сетевому интерфейсу eth0:

# ip -6 addr add 2001:0db8::1/64 dev eth0

Обратите внимание: /64 — это не CIDR-нотация, это количество бит префикса. Следующая диаграмма поможет понять о чём идёт речь:

2001:db8:0000:0000:0000:0000:0000:0001
_____________|____|___________________
Network ID   Subnet  Interface ID

Network ID определяется провайдером, когда он выдаёт блок IPv6-адресов. Вы же можете управлять значением Subnet и Interface ID. Таким образом, в нашем случае 64 бита отведены под Network ID + Subnet и 64 бита под Inetrface ID. Вспомните, что в IPv4 для адреса в целом отводилось 32 бита, так что выделенного такого размера блока адресов вам хватит очень надолго!

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

$ ping6 2001:db8:0:0:0:0:0:1
PING 2001:db8:0:0:0:0:0:1(2001:db8::1) 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=0.043 ms

Однако пинг с другого хоста у вас не пройдёт, поскольку для этого, так же как и с IPv4 нам понадобится роутер.

Добавление адресов

Вы можете добавлять сколько угодно адресов интерфейсам ваших систем. Просто считайте в шестнадцатиричной системе по порядку: 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f, 10, 11 и так далее, получая таким образом новые адреса:

2001:db8::1
2001:db8::2
2001:db8::3
...
2001:db8::18
2001:db8::19
2001:db8::1a
2001:db8::1b

Маршрутизация

Само-собой разумеется, ваш роутер должен поддерживать IPv6. Если вашим роутером является Linux-система, то включить маршрутизацию можно следующей командой:

# sysctl -w net.ipv6.conf.all.forwarding=1

Проверить, включена ли маршрутизация IPv6, можно командой:

# cat /proc/sys/net/ipv6/conf/eth0/forwarding
1

«1» означает, что всё хорошо и в вашем устройстве маршрутизация шестой версии IP включена. Теперь установите radvd — router advertiser daemon и в его файле конфигурации /etc/radvd.conf поместите следующее, изменив имя интерфейса eth0, если нужно:

interface eth0
{
   AdvSendAdvert on;
   prefix 2001:db8::/64
   {
   };
};

Теперь добавьте интерфейсу вашего роутера IPv6-адрес:

# ip address add 2001:db8::1a/64 dev eth0

Проверьте, всё ли у вас получилось так, как нужно, при помощи команд

$ ifconfig eth0 | grep inet6
          inet6 addr: 2001:db8::1a/64 Scope:Global
          inet6 addr: fe80::20e:2eff:feb9:cbad/64 Scope:Link

$ ip -6 route show
2001:db8::/64 dev eth0  metric 1024  mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0

И теперь можно запустит radvd:

# /etc/init.d/radvd start

Теперь вы должны без проблем пинговать интерфейс вашего роутера. обратите внимание, что в случае с глобальным адресом, в отличие от link-local, вам не нужно указывать имя интерфейса:

$ ping6 2001:0db8::1a
PING 2001:db8::1a(2001:db8::1a) 56 data bytes
64 bytes from 2001:db8::1a: icmp_seq=1 ttl=64 time=1.73 ms

Все компьютеры, находящиеся на одном свитче с маршрутизатором должны теперь автоматически получить адреса из диапазона 2001:0db8::/64. Чтобы добавить в таблицу маршрутизации ваших хостов роутер по-умолчанию воспользуйтесь командой:

# ip -6 route add default via 2001:db8::1a

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

interface eth0
{
  AdvSendAdvert on;
  prefix 2001:db8::/64
  {
    AdvOnLink on;
    AdvAutonomous on;
  };
  route ::/0
  {
  };
}

Теперь в таблицах маршрутизации IPv6 ваших хостов вы будете видеть следующее:

$ ip -6 route show
...
default via 2001:db8::1a dev eth0 metric 1024 mtu 1500 advmss 1440 hoplimit 0
...

Что делать, если вам не нужно, чтобы radvd раздавал IPv6-адреса всем подряд в вашей сети? Про перечислите в файле конфигурации демона link-local адреса тех станций, которым вы хотите выдавать адрес, а запросы от остальных будут просто проигнорированы:

interface eth0
{
  AdvSendAdvert on;

  prefix 2001:db8::/64
  {
    AdvOnLink on;
    AdvAutonomous on;
  };
  route ::/0
  {
  };
  clients
  {
    fe80::20d:b9ff:fe05:25b4;
    fe80::20b:6aff:feef:7e8d;
    fe80::221:97ff:feed:ef01;
  };
};

Калькулятор IPv6-адресов

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

Службы имён

Вообще, настройка DNS для IPv6 — тема достаточно объёмной статьи, однако я надеюсь что некоторые описанные здесь моменты дадут вам нужное направление.

Идея, лежащая в основе автоконфигурации сетевых IPv6 интерфейсов (link-local адреса и router advertisements), призвана избавить от необходимости держать DHCP-сервер, однако вам всё ещё нужно поддерживать DNS-сервер, чтобы хосты могли выполнять преобразование имён в IP-адреса и обратно. BIND9 уже поддерживает IPv6, но как всегда в случае с BIND, вам придётся потрудиться, перелопатив несколько конфиг-файлов, расположенных в разных местах. В других DNS-демонах от вас понадобилось бы меньше усилий, однако ещё никакой из них не поддерживает IPv6 в полном объёме. Если вас заинтересовала тема настройки IPv6 в BIND, вы может обратить к руководству по BIND.

В предыдущей статье мы рассматривали вариант использования старого-доброго /etc/hosts. Как вариант, вы можете использовать Dnsmasq, который является моим любимым средством организации DNS в локальных сетях. Он поддерживает IPv6-DNS и TFTP, однако в нём нет DHCP, что не позволяет ему быть универсальным решением. Dnsmasq делает содержимое /etc/hosts доступным по сети, используя DNS-протокол. Сперва настройте IPv6-интерфейсы ваших хостов на использование  статических адресов, а затем разместите соответствие адресов именам в файле /etc/hosts вашего Dnsmasq-сервера и перезапустите демон Dnsmasq. Далее установите rdnssd — recursive DNS server discovery daemon на том же хосте, где у вас установлен radvd, затем добавьте в файл конфигурации /etc/radvd.conf строку, указывающую адрес вашего Dnsmasq-сервера:

RDNSS 2001:0db8::1b

Перезапустите radvd. Проекты radvd и rdnssd находятся в стадии разработки, поэтому не исключено, что вы можете столкнуться с какими-нибудь проблемами, хотя на моих Debian-системах они работают отлично.

Источник: linux.com

По своей природе виртуальные хосты бывают двух типов: «name-based» и «address-based». Хосты первого типа сервер обслуживает на основе их доменного имени, получаемого от клиента в момент запроса. Виртуальные Хосты второго типа обслуживаются сервером на основании IP-адреса интерфейса, на который поступил запрос от клиента. Также, конечно же, можно комбинировать эти два типа, т. е. на определённом IP-интерфейсе «вешать» определённые name-based виртуальные хосты.

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

server {
...
}
server {
...
}
server {
...
}
...

Name-based

Теперь давайте попробуем на практике создать конфигурацию для пары виртуальных name-based виртуальных хостов domain-1.com и domain-2.com. Создайте новый файл конфигурации Nginx, например, в /etc/nginx/sites-available/twohosts (напоминаю ещё раз: все примеры рассматриваются в контексте установленного из репозиториев Nginx в Debian 5) и откройте его в текстовом редакторе. Следующая конфигурация описывает два виртуальных хоста:

server {
  server_name domain-1.com;
  access_log /var/log/nginx/domain-1.com.log;

  location / {
    root /var/www/domain-1.com;
    index index.htm index.html;
  }
}

server {
  server_name domain-2.com;
  access_log /var/log/nginx/domain-2.com.log;
  location / {
    root /var/www/domain-2.com;
    index index.htm index.html;
  }
}

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

# mkdir /var/www/domain-{1,2}.com

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

# for NAME in `seq 2`; do echo "Domain ${NAME}" > /var/www/domain-${NAME}.com/index.html; done

Делаем новый конфигурационный файл доступным для загрузки Nginx:

# ln -s /etc/nginx/sites-available/twohosts /etc/nginx/sites-enabled/twohosts

И перезапускаем сервер:

# /etc/init.d/nginx restart

Не забудьте добавить в /etc/hosts вашего клиентского компьютера необходимые записи (естественно, не забудьте заменить IP-адрес сервера на тот, который у вас):

# echo 192.168.0.1 domain-{1,2}.com >> /etc/hosts

На этом всё. Теперь попробуйте с клиентского компьютера открыть браузером URL http://domain-1.com и http://domain-2.com. Если всё настроено верно, то по каждому из URL вы увидите строки «Domain 1» и «Domain 2» соответственно.

Address-based

Иногда бывает необходимо, чтобы виртуальный хост был доступен только по определённому адресу, а не со всех интерфейсов сервера. Здесь на помощь приходит уже известный по предыдущим публикациям параметр listen. Допустим, у вашего сервера есть два интерфейса: 192.168.0.1 и 192.168.0.2. Вам необходимо, чтобы виртуальный хост domain-1.com был доступен только по адресу 192.168.0.1, а хост domain-2.com — по адресу 192.168.0.2. Всё, что вам нужно сделать это задействовать параметр listen в конфигурации каждого из виртуальных хостов:

server {
  server_name domain-1.com;
  access_log /var/log/nginx/domain-1.com.log;
  listen 192.168.0.1;

  location / {
    root /var/www/domain-1.com;
    index index.htm index.html;
  }
}

server {
  server_name domain-2.com;
  access_log /var/log/nginx/domain-2.com.log;
  listen 192.168.0.2;
  location / {
    root /var/www/domain-2.com;
    index index.htm index.html;
  }
}

Основными возможностями Nginx сегодня являются:

• поддержка SSL/TLS;
• name-based и IP-based виртуальные сервера;
• pipelined и keep-alive соединения ;
• перенастройка «на лету»;
• потоковое FLV;
• управление соединениями на базе IP-адреса источника;
• встроенный Perl.

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

Nginx портирован на FreeBSD, Linux, Solaris, Mac OS X и Windows, причём на каждой из этих систем сервер может использовать наиболее эффективный для данной ОС метод обработки событий. Перед сборкой Nginx из исходных кодов пользователь может выбрать необходимые для работы модули, реализующие функции от базовой работы с HTTP до поддержки WebDAV и GeoIP. При помощи модулей сторонних разработчиков в Nginx можно добавить поддержку Lua, обработку изображений «на лету», поддержку БД Redis и Drizzle, backend-менеджмент и многое другое.

Последняя версия Nginx доступна из SVN-репозитория проекта svn://svn.nginx.org и распространяется на условиях BSD-подобной лицензии, состоящей из двух пунктов. Больше информации мы можете получить на сайте проекта, а также из wiki, содержащей в том числе инструкции по установке двоичных сборок под Linux, BSD и Windows. История изменений, вплоть до последней версии, также доступна онлайн.

Источник h-online.com

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

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

Синтаксис вызова утилиты из командной строки следующий:

nmap <опции> цель

Допустим, вам необходимо попытаться определить тип и версию запущенной ОС на удалённой системе target.host.com. Запустите Nmap с опцией '-O' (использование этой опции требует администраторских привилегий):

# nmap -O target.host.com

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

Starting Nmap 5.21 ( http://nmap.org ) at 2010-02-27 23:52 EST
Nmap scan report for 10.0.0.1
Host is up (0.0015s latency).
Not shown: 997 closed ports
PORT      STATE SERVICE
53/tcp    open  domain
5009/tcp  open  airport-admin
10000/tcp open  snet-sensor-mgmt
MAC Address: 00:11:24:6B:43:E2 (Apple Computer)
Device type: WAP|printer
Running: Apple embedded, Canon embedded, Kyocera embedded, Xerox embedded
OS details: VxWorks: Apple AirPort Extreme v5.7 or AirPort Express v6.3; Canon imageRUNNER printer (5055, C3045, C3380, or C5185); Kyocera FS-4020DN printer; or Xerox Phaser 8860MFP printer
Network Distance: 1 hop
OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 10.21 seconds

Как вы видите, Nmap предоставил достаточно много информации. В представленном примере Nmap выполнил ряд тестов, на основании которых попытался определить тип и версию ОС, используемую на хосте. Приведённый выше вывод Nmap — результат сканирования роутера Apple Airport Extreme. Помимо того, что Nmap сообщил нам тип предполагаемой ОС, он также вывел информацию о сетевой удалённости устройства, MAC-адрес и производителя сетевого интерфейса, перечень открытых портов и время, затраченное на сканирование.

Ниже представлен вывод другого сканирования, хоста под управлением Ubuntu 9.10:

Starting Nmap 5.21 ( http://nmap.org ) at 2010-02-28 00:00 EST
Nmap scan report for 10.0.0.6
Host is up (0.0039s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
MAC Address: 00:17:08:2A:D6:F0 (Hewlett Packard)
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.19 - 2.6.31
Network Distance: 1 hop
OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 3.40 seconds

Здесь мы видим, что производителем сетевого интерфейса является HP, операционной системой является Linux с ядром версии в районе 2.6.19-2.6.31. Вообще, точно определить версию ядра Linux с помощью Nmap обычно невозможно.

Предупреждение

В приведённых выше примерах я сканировал свой собственный роутер и одну из рабочих станций, находящихся в моей сети, поскольку я имею на то полное право. В принципе вы можете сканировать любой хост, какой пожелаете, однако, не очень хорошая идея заниматься сканированием чужих сетей и хостов без разрешения их владельцев. Если вам нужен хочт для экспериментов, сообщество готово вам его предоставить по адресу scanme.nmap.org. Этот хост специально создан для тестирования Nmap, только если вы не собираетесь тестировать на нём атаки типа DoS.

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

Сканирование нескольких хостов

За один запуск Nmap вы можете сканировать более одного хоста. Если в качетсве целей сканирования вы используете IP-адреса, вы можете передавать их Nmap в виде диапазонов, например: 10.0.0.1-6 или 10.0.0.0/24. Первый способ определяет диапазон IP-адресов c 10.0.0.1 по 10.0.0.6, а вторая — с 10.0.0.1 по 10.0.0.254, т. е. всю подсеть 10.0.0.0 с маской 24 в CIDR-нотации. Например, если вы хотите выполнить сканирование хостов с IP-адресами 10.0.0.1-10.0.0.42, команда будет следующей:

# nmap -O 10.0.0.1-42

Если же вы используете имена хостов вместо адресов, то просто перечислите имена через пробел:

# nmap -O host1.target.com host2.target.com

Поиск открытых портов

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

$ nmap target.hostname.com

Interesting ports on target.hostname.com (10.0.0.88):
Not shown: 1711 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
3306/tcp open  mysql
Nmap done: 1 IP address (1 host up) scanned in 0.228 seconds

Здесь вы можете увидеть, что на целевом хосте открыты порты 22, 80 и 3306 с перечислением названий сервисов, сидящих на этих портах, соответственно ssh, http и mysql. Nmap распознаёт шесть состояний портов: open (открыт), closed (закрыт), filtered (порт недоступен, скорее всего фильтруется файрволом), unfiltered (порт доступен, но состояние определить не удалось), open|filtered (открыт или фильтруется файрволом), и closed|filtered (закрыт или фильтруется файрволом).

Если вам нужна более детальная информация, воспользуйтесь одинарной или двойной опцией '-v', например:

$ nmap -vv host.target.com

Initiating Ping Scan at 11:44
Scanning 10.0.0.28 [1 port]
Completed Ping Scan at 11:44, 0.00s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 11:44
Completed Parallel DNS resolution of 1 host. at 11:44, 0.00s elapsed
Initiating Connect Scan at 11:44
Scanning host.target.com (10.0.0.28) [1714 ports]
Discovered open port 22/tcp on 10.0.0.28
Discovered open port 80/tcp on 10.0.0.28
Discovered open port 3306/tcp on 10.0.0.28
Completed Connect Scan at 11:44, 0.08s elapsed (1714 total ports)
Host host.target.com (10.0.0.28) appears to be up ... good.
Interesting ports on host.target.com (10.0.0.28):
Not shown: 1711 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
3306/tcp open  mysql
Read data files from: /usr/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.104 seconds

Сканирование служб

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

$ nmap -sV target.host.com

Starting Nmap 5.21 ( http://nmap.org ) at 2010-02-28 00:15 EST
Nmap scan report for test.host.net (XX.XXX.XXX.XX)
Host is up (0.090s latency).
Not shown: 965 closed ports, 33 filtered ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 4.7p1 Debian 8ubuntu1.2 (protocol 2.0)
80/tcp open  http    Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.10 with Suhosin-Patch)
Service Info: OS: Linux
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.43 seconds

Как видно из вывода выше, Nmap определил серверы SSH-4.7 и Apache-2.2.8, находящиеся на портах 22 и 80. Также из названий версий ПО удаётся определить, что сервер работает под Ubuntu Linux. Такой метод сканирования может оказаться весьма кстати, когда вам необходимо выявить устаревшие версии ПО, работающие на ваших хостах, которые могут быть подвержены известным угрозам.

Кто живёт в моей сети?

Не уверены точно, что знаете обо всех обитателях своей сети? Попробуйте запустить Nmap с параметрами '-sP' и он выполнит обычное пинг-сканирование, определяя лишь отвечающие хосты, не прибегая к сканированию портов. Например, чтобы определить «живых» в подсети 10.0.0.0/24, достаточно простой команды:

$ nmap -sP 10.0.0.0/24

Или же, как было сказано выше, вы можете указать диапазон хостов, а не всю подсеть. Например:

$ nmap -sP 10.0.0.1-16

Zenmap

Если работа в режиме командной строки — не ваш конёк, вы можете воспользоваться Zenmap — GUI-утилитой, облегчающей построение командной строки Nmap, а также обладающую некоторыми бонусами вроде построения графической карты сети.

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

Итоги

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

По материалам Linux.Com