Выделенный Web-сервер на основе nginx – отличный способ повышения производительности Web-сайтов. В скорости обработки статического контента ему просто нет равных: он легко выдерживает несколько тысяч одновременных соединений и может быть легко оптимизирован и подогнан под любую конфигурацию. Однако? выступая в качестве фронт-энда для Apache, nginx оказывается наиболее уязвимым местом всей Web-инфраструктуры, поэтому безопасности nginx необходимо уделить особое внимание.

Эта статья – своего рода ликбез, или, если хочешь, резюме всех техник повышения безопасности nginx. В ней не будет теории, описания основ настройки Web-сервера и прочей воды. Вместо этого ты получишь исчерпывающий практический материал, описывающий все основные шаги, которые необходимо проделать для того, чтобы получить по-настоящему защищенный Web-сервер.

Установка

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

Измени строку приветствия Web-сервера

Скачай исходники nginx, открой файл src/http/ngx_http_header_filter_module.c и найди следующие две строки:

static char ngx_http_server_string[] = "Server: nginx" CRLF;
static char ngx_http_server_full_string[] = "Server: " NGINX_VER CRLF;

Замени их на что-то вроде этого:

static char ngx_http_server_string[] = "Server: ][ Web Server" CRLF;
static char ngx_http_server_full_string[] = "Server: ][ Web Server" CRLF;

Удали все неиспользуемые тобой nginx-модули

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

Выполни сборку с помощью следующих команд:

# ./configure --without-http_autoindex_module --without-http_ssi_module
# make

# make install

Так ты получишь nginx с заранее отключенными (и в большинстве случаев бесполезными) модулями SSI (Server Side Includes) и Autoindex. Чтобы узнать, какие модули можно безболезненно выбросить из Web-сервера, запусти скрипт configure с флагом '--help'.

Препарируем nginx.conf

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

Отключи показ версии сервера на всех ошибочных страницах

Добавь в файл nginx.conf строку "server_tokens off". Это заставит nginx скрывать информацию о типе и версии Web-сервера на страницах, генерируемых в ответ на ошибочный запрос клиента.

Настрой защиту от срыва стека

Добавь в секцию server следующие строки:

# vi /etc/nginx/nginx.conf

# Максимальный размер буфера для хранения тела запроса клиента
client_body_buffer_size 1K;
# Максимальный размер буфера для хранения заголовков запроса клиента
client_header_buffer_size 1k;
# Максимальный размер тела запроса клиента, прописанный в поле Content-Length заголовка. Если сервер должен поддерживать загрузку файлов, это значение необходимо увеличить
client_max_body_size 1k;
# Количество и размер буферов для чтения большого заголовка запроса клиента
large_client_header_buffers 2 1k;

Обрати внимание на директиву large_client_header_buffers. По умолчанию, для хранения строки URI nginx выделяет четыре буфера, размер каждого из которых равен размеру страницы памяти (для x86 это 4 Кб). Буферы освобождаются каждый раз, когда по окончанию обработки запроса соединение переходит в состояние keep-alive. Два буфера по 1 Кб могут хранить URI длиной только 2 Кб, что позволяет бороться с ботами и DoS-атаками.

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

# vi /etc/nginx/nginx.conf

# Таймаут при чтении тела запроса клиента
client_body_timeout 10;
# Таймаут при чтении заголовка запроса клиента
client_header_timeout 10;
# Таймаут, по истечению которого keep-alive соединение с клиентом не будет закрыто со стороны сервера
keepalive_timeout 5 5;
# Таймаут при передаче ответа клиенту
send_timeout 10;

Контролируй количество одновременных соединений

Для защиты Web-сервера от перегрузки и попыток осуществить DoS-атаку добавь в конфиг следующие строки:

# vi /etc/nginx/nginx.conf

# Описываем зону (slimits), в которой будут храниться состояния сессий. Зона размером 1 Мб может хранить около 32000 состояний, мы устанавливаем ее размер равным 5 Мб
limit_zone slimits $binary_remote_addr 5m;
# Задаем максимальное количество одновременных соединений для одной сессии. По сути, это число задает максимальное количество соединений с одного IP
limit_conn slimits 5;

Первая директива должна находиться в секции HTTP, вторая – в секции location. Когда количество соединений выйдет за пределы лимитов, клиент получит сообщение «Service unavailable» с кодом 503.

Разреши коннекты только к своему домену

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

# vi /etc/nginx/nginx.conf

if ($host !~ ^(host.com|www.host.com)$ ) {
return 444;
}

Ограничь количество доступных методов обращения к Web-серверу

Некоторые боты используют различные методы обращения к серверу для попытки определения его типа и/или проникновения, однако в документе RFC 2616 четко сказано, что Web-сервер не обязан реализовывать их все, и неподдерживаемые методы могут просто не обрабатываться. Сегодня используемыми остаются только методы GET (запрос документа), HEAD (запрос заголовков сервера) и POST (запрос на публикацию документа), поэтому все остальные можно безболезненно отключить с помощью помещения следующих строк в секцию server конфигурационного файла:

# vi /etc/nginx/nginx.conf

if ($request_method !~ ^(GET|HEAD|POST)$ ) {
return 444;
}

Отшивай ботов

Другой способ блокирования ботов, сканеров и прочей нечисти основан на определении типа клиента (user-agent). Он не слишком эффективен, потому как большинство ботов косят под вполне легитимные браузеры, но в ряде случаев остается полезным:

# vi /etc/nginx/nginx.conf

# Блокируем менеджеры загрузки
if ($http_user_agent ~* LWP::Simple|BBBike|wget) {
return 403;
}
# Блокируем некоторые типы ботов
if ($http_user_agent ~* msnbot|scrapbot) {
return 403;
}

Блокируй Referrer-спам

Если твой сайт публикует Web-логи в общедоступном виде, ты легко можешь стать жертвой Referrer-спама (когда спам-боты обращаются к твоему серверу, указывая в заголовке referrer – адрес рекламируемого сайта). Такой вид спама может легко испортить SEO-рейтинги интернет-страницы, поэтому его необходимо блокировать в обязательном порядке. Один из способов сделать это – занести наиболее частые слова, встречающиеся в адресах рекламируемых сайтов, в черный список.

# vi /etc/nginx/nginx.conf

# Секция server
if ( $http_referer ~* (babes|forsale|girl|jewelry|love|nudit|organic|poker|porn|sex|teen) )
{
return 403;
}

Блокируй хотлинк

Хотлинк – это включение в страницу изображения (или иного контента) с другого сайта. По сути, это воровство, потому как изображение, на которое ты потратил не один час своего свободного времени, не только свободно используется другими, но и создает нагрузку на твой Web-сервер, не приводя на него посетителей. Для борьбы с хотлинками достаточно сделать так, чтобы изображения отдавались клиенту только в том случае, если он запросил их, уже находясь на сайте (другими словами, заголовок referrer-запроса должен содержать имя твоего сайта). Добавь в секцию server конфигурационного файла nginx.conf следующие строки (host.com – это адрес твоего сайта):

# vi /etc/nginx/nginx.conf

location /images/ {
valid_referers none blocked www.host.com host.com;
if ($invalid_referer) {
return 403;
}
}

В качестве альтернативы ты можешь настроить сервер на отдачу специального баннера с сообщением о воровстве вместо запрашиваемого изображения. Для этого замени строку «return 403» на строку:

rewrite ^/images/uploads.*\.(gif|jpg|jpeg|png)$ http://www.host.com/banned.jpg last

Защищай важные каталоги от посторонних

Как и любой другой Web-сервер, nginx позволяет регулировать доступ к каталогам на основе IP-адресов и паролей. Эту возможность можно использовать для закрытия некоторых частей сайта от посторонних глаз. Например, для отрезания URI от внешнего мира:

# vi /etc/nginx/nginx.conf

location /uploads/ {
# Разрешаем доступ только машинам локальной сети
allow 192.168.1.0/24;
# Отшиваем всех остальных
deny all;
}

Теперь к документам каталога uploads будут иметь доступ только пользователи локальной сети. Для установки пароля придется проделать более сложные действия. Сначала необходимо создать приватный для nginx-файл паролей и добавить в него необходимых пользователей (в качестве примера добавим пользователя admin):

# mkdir /etc/nginx/.htpasswd
# htpasswd -c /etc/nginx/.htpasswd/passwd admin

Далее открой файл nginx.conf и впиши в него следующие строки:

# vi /etc/nginx/nginx.conf

location /admin/ {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd/passwd;
}

Новых пользователей можно добавить с помощью следующей команды:

# htpasswd -s /etc/nginx/.htpasswd/passwd пользователь

Используй SSL

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

Для настройки SSL-шифрования средствами nginx достаточно выполнить несколько простых шагов. Сначала ты должен создать сертификат с помощью следующей последовательности команд:

# cd /etc/nginx
# openssl genrsa -des3 -out server.key 1024
# openssl req -new -key server.key -out server.csr
# cp server.key server.key.org
# openssl rsa -in server.key.org -out server.key
# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Затем описать сертификат в конфигурационном файле nginx:

# vi /etc/nginx/nginx.conf

server {
server_name host.com;
listen 443;
ssl on;
ssl_certificate /etc/nginx/server.crt;
ssl_certificate_key /etc/nginx/server.key;
access_log /etc/nginx/logs/ssl.access.log;
error_log /etc/nginx/logs/ssl.error.log;
}

После этого можно перезагрузить Web-сервер:

# /etc/init.d/nginx reload

Естественно, без поддержки со стороны самого Web-сайта это делать бессмысленно.

Другие способы

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

Открой файл /etc/sysctl.conf и помести в него следующие строки:

# vi /etc/sysctl.conf

# Защита от smurf-атак
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Защита от неправильных ICMP-сообщений
net.ipv4.icmp_ignore_bogus_error_responses = 1
# Защита от SYN-флуда
net.ipv4.tcp_syncookies = 1
# Запрещаем маршрутизацию от источника
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# Защита от спуфинга
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# Мы не маршрутизатор
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# Включаем ExecShield
kernel.exec-shield = 1
kernel.randomize_va_space = 1
# Расширяем диапазон доступных портов
net.ipv4.ip_local_port_range = 2000 65000
# Увеличиваем максимальный размер TCP-буферов
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_window_scaling = 1

Размести корневой каталог Web-сервера на выделенном разделе

Поместив корневой каталог Web-сервера в выделенный раздел и запретив на нем размещение любых исполняемых файлов и файлов-устройств, ты обезопасишь остальную часть системы от тех, кто сможет получить доступ к корню Web-сервера. При этом запись в файле /etc/fstab должна иметь примерно такой вид:

/dev/sda5 /nginx ext4 defaults,nosuid,noexec,nodev 1 2

Помести nginx в chroot/jail-окружение

Любая современная *nix-система позволяет запереть приложение в изолированной среде исполнения. В Linux для этого можно использовать технологии KVM, Xen, OpenVZ и VServer, во FreeBSD – Jail, в Solaris – Zones. Если ни одна из этих технологий не доступна, ты можешь поместить nginx в классический chroot, который хоть и намного более хрупок, но большинство взломщиков остановить сможет.

Установи правила SELinux для защиты nginx

Хорошей альтернативой изолированным средам исполнения являются локальные системы обнаружения и предотвращения вторжений, такие как SELinux или AppArmor. Будучи правильно настроенными, они смогут предотвратить попытки взлома Web-сервера. По дефолту ни одна из них не настроена для работы в связке с nginx, однако в рамках проекта SELinuxNginx(http://sf.net/projects/selinuxnginx/) были созданы правила для SELinux, которые может использовать любой желающий. Остается только скачать и установить:

# tar -zxvf se-ngix_1_0_10.tar.gz
# cd se-ngix_1_0_10/nginx
# make
# /usr/sbin/semodule -i nginx.pp

Настрой брандмауэр

Обычно nginx устанавливают на выделенных машинах, готовых к высокой нагрузке, поэтому зачастую он остается единственным сетевым сервисом, работающим на сервере. Чтобы обезопасить сервер, достаточно создать совсем небольшой набор правил, которые будут открывать 80, 110 и 143-й порты (если, конечно, nginx должен работать еще и как IMAP/POP3-прокси) и закрывать от внешнего мира все остальное.

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

Для не слишком нагруженного Web-сайта хорошей идеей будет ограничить количество попыток соединений с одного IP-адреса в минуту. Это сможет уберечь тебя от некоторых типов DoS-атак и брутфорса. В Linux это можно сделать с помощью стандартного iptables/netfilter-модуля state:

# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m state --state NEW -m recent --set
# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m state --state NEW -m recent --update \
--seconds 60 --hitcount 15 -j DROP

Правила урезают лимит на количество подключений с одного IP в минуту до 15. То же можно сделать и с помощью pf:

# vi /etc/pf.conf

webserver_ip="1.1.1.1"
table <abuse> persist
block in quick from <abuse>
pass in on $ext_if proto tcp to $webserver_ip \
port www flags S/SA keep state \
(max-src-conn 100, max-src-conn-rate 15/60, \
overload <abusive_ips> flush)

Кроме лимита на количество последовательных подключений (15 в минуту), данное правило устанавливает дополнительный лимит на количество одновременных подключений равный 100.

Настрой PHP

Если ты используешь nginx в связке с PHP, не забудь настроить и его. Вот как должен выглядеть конфигурационный файл /etc/php/php.ini защищенного сервера:

# vi /etc/php/php.ini

# Отключаем опасные функции
disable_functions = phpinfo, system, mail, exec
# Максимальное время исполнения скрипта
max_execution_time = 30
# Максимальное время, которое может потратить скрипт на обработку данных запроса
max_input_time = 60
# Максимальное количество памяти, выделяемое каждому скрипту
memory_limit = 8M
# Максимальный размер данных, отсылаемых скрипту с помощью метода POST
post_max_size = 8M
# Максимальный размер загружаемых файлов
upload_max_filesize = 2M
# Не показывать ошибки PHP-скриптов пользователям
display_errors = Off
# Включаем Safe Mode
safe_mode = On
# Включаем SQL Safe Mode
sql.safe_mode = On
# Позволяем выполнять внешние команды только в этом каталоге
safe_mode_exec_dir = /путь/к/защищенному/каталогу
# Защищаемся от утечки информации о PHP
expose_php = Off
# Ведем логи
log_errors = On
# Запрещаем открытие удаленных файлов
allow_url_fopen = Off

Выводы

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

О герое дня

Nginx – один самых производительных и популярных Web-серверов в мире. Согласно данным Netcraft, он используется для поддержки более чем 12 миллионов Web-сайтов по всему миру, включая таких мастодонтов как Rambler, Yandex, Begun, Wordpress.com, Wrike, SourceForge.net, vkontakte.ru,megashara.com, Либрусек и Taba.ru. Грамотная архитектура, основанная на мультиплексировании соединений с помощью системных вызовов select, epoll (Linux), kqueue (FreeBSD) и механизме управления памятью на основе пулов (небольших буферов от 1 до 16 Кб), позволяет nginx не проседать даже под очень высокими нагрузками, выдерживая свыше 10000 одновременных соединений (так называемая проблема C10K). Изначально написан Игорем Сысоевым для компании Rambler и открыт в 2004 году под BSD-подобной лицензией.

NGINX - SSL PROXY

Введение


Как настроить nginx в качестве frontend к apache и зачем это нужно — написано неоднократно, в том числе и на Хабре. Мой случай немного отличается от классического. Начиналось все как обычно, проект на apache, увеличение количества посетителей и, связанная с ним, недостаточность ресурсов сервера. Но проект использовал SSL для защиты обмена данными с клиентами. С чем я столкнулся и как решил проблемы я расскажу под катом.

Проблемы


Поскольку непосредственный прием запросов клиентов перешел на плечи nginx то и работу с SSL надо переносить на него же. Apache, который теперь висел но loopback 127.0.0.1:8080, в поддержке SSL не нуждался. Первая проблемка заключалась в том, что сертификат был от Thawte, а они требовали использования промежуточного сертификата. Nginx для работы с такими сертификатами не имеет специальной директивы. В конфиге apache было так:


  ...
  SSLEngine on
  SSLCertificateFile /usr/local/ssl/www.blabla.ru/public.crt   SSLCertificateKeyFile /usr/local/ssl/www.blabla.ru/private.key   SSLCACertificateFile /usr/local/ssl/www.blabla.ru/intermediate.crt   ...


Как быть с SSLCACertificateFile в nginx? Оказалось надо просто «срастить» два файла, поместив их содержимое в один (публичный сертификат, следом промежуточный):

cd /usr/local/ssl/www.blabla.ru cp public.crt public_concat.crt
cat intermediate.crt >> public_concat.crt

Все, теперь в nginx просто пишем:

    server {
        listen                  1.2.3.4:443;
        server_name             www.blabla.ru;         ssl                     on;
        ssl_certificate         /usr/local/ssl/www.blabla.ru/public_concat.crt;         ssl_certificate_key     /usr/local/ssl/www.blabla.ru/private.key;         ...
    }

Редирект с незащищенного сайта на защищенный сложностей в настройке не вызвал:

    server {
        listen          1.2.3.4:80;
        server_name     www.blabla.ru blabla.ru;
        # rewrite ^(.*) https://www.blabla.ru$1 permanent;
        return 301 https://www.blabla.ru$request_uri;     }

Сложности начались при работе ajax. Асинхронные запросы к серверу выполнялись с префиксом http:// что вызывало губительный для ajax редирект... необходимость передавать переменные окружения, в частности имя протокола, из nginx в apache, сделано это было так:
в nginx:

<code>    server {
        ...
        location / {
            ...
            proxy_set_header            X-Forwarded-Proto $scheme;
            ...
        }
        ...
    }

Самое главное в apache надо в определении виртуального хоста прописать:


  ServerName www.blabla.ru   ...
  SetEnvIf X-Forwarded-Proto https HTTPS=on
  ...


Теперь все ajax запросы идут на https:// что и требовалось. Для этого трюка модуль apache setenvif_module должен быть установлен и включен в конфиге:

<code>LoadModule setenvif_module libexec/apache22/mod_setenvif.so

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

https://www.blabla.ru:80/myadmin 

Вот это самое :80 сильно все портило, phpMyAdmin не открывался с руганью что ошибка защиты SSL. Вылечилось, как указано выше, прямым указанием пути в конфиге phpMyAdmin-а:

$cfg['PmaAbsoluteUri'] = 'https://www.blabla.ru/myadmin'; 


Еще не стоит забывать о передаче реальных IP адресов посетителей в apache для сохранения имеющейся схемы ведения логов. Это расписано неоднократно, копайте в сторону модуля apache rpaf_module. 
Еще по теме:

Настройка HTTPS-серверов


english
русский

简体中文
עברית
日本語
türkçe
italiano

новости [en]
об nginx
скачать
безопасность [en]
pgp ключи [en]
документация
faq
ссылки [en]
книги [en]
поддержка
пожертвования [en]

trac
wiki
twitter
nginx.com
Оптимизация HTTPS-сервера
Цепочки SSL-сертификатов
Единый HTTP/HTTPS сервер
Выбор HTTPS-сервера по имени
     SSL-сертификат с несколькими именами
     Указание имени сервера
Совместимость

Чтобы настроить HTTPS-сервер, необходимо включить параметр ssl на слушающих сокетахв блоке server, а также указать местоположение файлов с сертификатом сервера и секретным ключом:

server {
    listen              443 ssl;
    server_name         www.example.com;     ssl_certificate     www.example.com.crt</strong>;     ssl_certificate_key www.example.com.key</strong>;     ssl_protocols       SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ...
}

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

    ssl_certificate     www.example.com.cert;     ssl_certificate_key www.example.com.cert; 

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

С помощью директив ssl_protocols и ssl_ciphers можно ограничить соединения использованием только “сильных” версий и шифров SSL/TLS. Начиная с версии 1.0.5 nginx по умолчанию использует “ssl_protocols SSLv3 TLSv1” и “ssl_ciphers HIGH:!aNULL:!MD5”, поэтому явная их настройка имеет смысл только для более ранних версий nginx. Начиная с версий 1.1.13 и 1.0.12 nginx по умолчанию использует “ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2”.

Известно, что шифры с CBC-режимом уязвимы к ряду атак, в частности к BEAST-атаке (см.CVE-2011-3389). Настройка шифров может быть изменена так, чтобы предпочитался RC4-SHA:

    ssl_ciphers RC4:HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

Оптимизация HTTPS-сервера

SSL-операции потребляют дополнительные ресурсы процессора. На мультипроцессорных системах следует запускать несколько рабочих процессов, не меньше числа доступных процессорных ядер. Наиболее ресурсоёмкой для процессора является операция SSL handshake, в рамках которой формируются криптографические параметры сессии. Существует два способа уменьшения числа этих операций, производимых для каждого клиента: использование постоянных (keepalive) соединений, позволяющих в рамках одного соединения обрабатывать сразу несколько запросов, и повторное использование параметров SSL-сессии для предотвращения необходимости выполнения SSL handshake для параллельных и последующих соединений. Сессии хранятся в кэше SSL-сессий, разделяемом между рабочими процессами и настраиваемом директивой ssl_session_cache. В 1 мегабайт кэша помещается около 4000 сессий. Таймаут кэша по умолчанию равен 5 минутам. Он может быть увеличен с помощью директивы ssl_session_timeout. Вот пример конфигурации, оптимизированной под многоядерную систему с 10-мегабайтным разделяемым кэшем сессий:

worker_processes auto;
http {
    ssl_session_cache   shared:SSL:10m;
    ssl_session_timeout 10m;
    server {
        listen              443 ssl;
        server_name         www.example.com;         keepalive_timeout   70;
        ssl_certificate     www.example.com.crt;         ssl_certificate_key www.example.com.key;         ssl_protocols       SSLv3 TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers         HIGH:!aNULL:!MD5;
        ...

Цепочки SSL-сертификатов

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

$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt 

Полученный файл следует указать в директиве ssl_certificate:

server {
    listen              443 ssl;
    server_name         www.example.com;     ssl_certificate     www.example.com.chained.crt;     ssl_certificate_key www.example.com.key;     ...
}

Если сертификат сервера и связка сертификатов были соединены в неправильном порядке, nginx откажется запускаться и выдаст сообщение об ошибке:

SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed
   (SSL: error:0B080074:x509 certificate routines:
    X509_check_private_key:key values mismatch)

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

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

$ openssl s_client -connect www.godaddy.com:443 ...
Certificate chain
 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US
     /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc
     /OU=MIS Department/CN=www.GoDaddy.com</strong>      /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
     /OU=http://certificates.godaddy.com/repository      /CN=Go Daddy Secure Certification Authority
     /serialNumber=07969287
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
     /OU=http://certificates.godaddy.com/repository      /CN=Go Daddy Secure Certification Authority
     /serialNumber=07969287
   i:/C=US/O=The Go Daddy Group, Inc.
     /OU=Go Daddy Class 2 Certification Authority
 2 s:/C=US/O=The Go Daddy Group, Inc.
     /OU=Go Daddy Class 2 Certification Authority
   i:/L=ValiCert Validation Network/O=ValiCert, Inc.
     /OU=ValiCert Class 2 Policy Validation Authority
     /CN=http://www.valicert.com//emailAddress=info@valicer... ...

В этом примере субъект (“s”) сертификата №0 сервера www.GoDaddy.com подписан издателем (“i”), который в свою очередь является субъектом сертификата №1, подписанного издателем, который в свою очередь является субъектом сертификата №2, подписанного общеизвестным издателем ValiCert, Inc., чей сертификат хранится во встроенной в браузеры базе данных сертификатов (которая в тёмном чулане хранится в доме, который построил Джек).

Если связку сертификатов не добавили, будет показан только сертификат сервера №0.

Единый HTTP/HTTPS сервер

Можно настроить единый сервер, который обслуживает как HTTP-, так и HTTPS-запросы:

server {
    listen              80;
    listen              443 ssl;
    server_name         www.example.com;     ssl_certificate     www.example.com.crt;     ssl_certificate_key www.example.com.key;     ...
}

До версии 0.7.14 SSL нельзя было включить выборочно для отдельных слущающих сокетов, как показано выше. SSL можно было включить только для всего сервера целиком, с помощью директивы ssl, что не позволяло настроить единый HTTP/HTTPS сервер. Для решения этой задачи был добавлен параметр ssl директивы listen. Поэтому использование директивы ssl в современных версиях не рекомендуется.

Выбор HTTPS-сервера по имени

Типичная проблема возникает при настройке двух и более серверов HTTPS, слушающих на одном и том же IP-адресе:

server {
    listen          443 ssl;
    server_name     www.example.com;     ssl_certificate www.example.com.crt;     ...
}
server {
    listen          443 ssl;
    server_name     www.example.org;     ssl_certificate www.example.org.crt;     ...
}

В такой конфигурации браузер получит сертификат сервера по умолчанию, т.е.www.example.com, независимо от запрашиваемого имени сервера. Это связано с поведением протокола SSL. SSL-соединение устанавливается до того, как браузер посылает HTTP-запрос, и nginx не знает имени запрашиваемого сервера. Следовательно, он лишь может предложить сертификат сервера по умолчанию.

Наиболее старым и надёжным способом решения этой проблемы является назначение каждому HTTPS-серверу своего IP-адреса:

server {
    listen          192.168.1.1:443 ssl;
    server_name     www.example.com;     ssl_certificate www.example.com.crt;     ...
}
server {
    listen          192.168.1.2:443 ssl;
    server_name     www.example.org;     ssl_certificate www.example.org.crt;     ...
}

SSL-сертификат с несколькими именами

Существуют и другие способы, которые позволяют использовать один и тот же IP-адрес сразу для нескольких HTTPS-серверов. Все они, однако, имеют свои недостатки. Одним из таких способов является использование сертификата с несколькими именами в поле SubjectAltName сертификата, например www.example.com и www.example.org. Однако, длина поля SubjectAltName ограничена.

Другим способом является использование wildcard-сертификата, например *.example.org. Такой сертификат защищает все поддомены указанного домена, но только на заданном уровне. Под такой сертификат подходит www.example.org, но не подходят example.org иwww.sub.example.org. Два вышеуказанных способа можно комбинировать. Сертификат может одновременно содержать и точное, и wildcard имена в поле SubjectAltName, напримерexample.org и *.example.org.

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

ssl_certificate     common.crt;
ssl_certificate_key common.key;
server {
    listen          443 ssl;
    server_name     www.example.com;     ...
}
server {
    listen          443 ssl;
    server_name     www.example.org;     ...
}

Указание имени сервера

Более общее решение для работы нескольких HTTPS-серверов на одном IP-адресе —расширение Server Name Indication протокола TLS (SNI, RFC 6066), которое позволяет браузеру передать запрашиваемое имя сервера во время SSL handshake, а значит сервер будет знать, какой сертификат ему следует использовать для соединения. Однако, поддержка SNI браузерами ограничена. Сейчас это поддерживается браузерами начиная со следующих версий:


  • Opera 8.0;
  • MSIE 7.0 (но только на Windows Vista и выше);
  • Firefox 2.0 и другие браузеры, использующие Mozilla Platform rv:1.8.1;
  • Safari 3.2.1 (Windows-версия поддерживает SNI только на Vista и выше);
  • и Chrome (Windows-версия также поддерживает SNI только на Vista и выше).

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

Чтобы использовать SNI в nginx, соответствующая поддержка должна присутствовать как в библиотеке OpenSSL, использованной при сборке бинарного файла nginx, так и в библиотеке, подгружаемой в момент работы. OpenSSL поддерживает SNI начиная с версии 0.9.8f, если она была собрана с опцией конфигурации “--enable-tlsext”. Начиная с OpenSSL 0.9.8j эта опция включена по умолчанию. Если nginx был собран с поддержкой SNI, то при запуске nginx с ключом “-V” об этом сообщается:

$ nginx -V
...
TLS SNI support enabled
...

Однако, если nginx, собранный с поддержкой SNI, в процессе работы подгружает библиотеку OpenSSL, в которой нет поддержки SNI, nginx выдаёт предупреждение:

nginx was built with SNI support, however, now it is linked
dynamically to an OpenSSL library which has no tlsext support,
therefore SNI is not available

Совместимость


  • Статус поддержки SNI отображается по ключу “-V” начиная с версий 0.8.21 и 0.7.62.
  • Параметр ssl директивы listen поддерживается начиная с версии 0.7.14. До версии 0.8.21 его можно было указывать только совместно с параметром default.
  • SNI поддерживается начиная с версии 0.5.32.
  • Разделяемый кэш SSL-сессий поддерживается начиная с версии 0.5.6.


  • Версия 0.7.65, 0.8.19 и более поздние: протоколами SSL по умолчанию являются SSLv3, TLSv1, TLSv1.1 и TLSv1.2 (если поддерживается библиотекой OpenSSL).
  • Версия 0.7.64, 0.8.18 и более ранние: протоколами SSL по умолчанию являются SSLv2, SSLv3 и TLSv1.


  • Версия 1.0.5 и более поздние: шифрами SSL по умолчанию являются “HIGH:!aNULL:!MD5”.
  • Версия 0.7.65, 0.8.20 и более поздние: шифрами SSL по умолчанию являются “HIGH:!ADH:!MD5”.
  • Версия 0.8.19: шифрами SSL по умолчанию являются “ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM”.
  • Версия 0.7.64, 0.8.18 и более ранние: шифрами SSL по умолчанию являются
    ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP”.

автор: Игорь Сысоев
редактор: Brian Mercer

1. При публикации электронного текста лучше использовать шрифт без засечек (личная рекомендация – Verdana, Tahoma, Arial, Calibri)
2. Шрифт не должен быть очень мелким и очень крупным. «Средняя температура по больнице» – 12 размер
3. Читать «черным по белому» легче, чем «белым по черному»
4. Оптимальная длина предложения – максимум две строки
5. Чередуйте предложения разной длины
6. Оптимальный объем абзаца – не больше 4-5 строк
7. Чередуйте абзацы разного объема, чтобы текст не выглядел монотонным
8. Наиболее удобная для чтения длина сроки – 60-80 символов
9. Абзацы желательно отделять друг от друга интервалом размером с одну строку
10. Заголовок текста должен быть напечатан шрифтом более крупного размера (по сравнению с основным текстом) и выделяться жирным
11. Длинные заголовки (больше 2-ух строк) раздражают
12. Заголовок, помещенный в кавычки, больше приковывает внимание
13. Структурные части текста следует отделять подзаголовками – размер шрифта можно не увеличивать, лучше их просто выделить жирным
14. Используйте маркированные и нумерованные списки – в них помещают разные перечисления (информацию, помещенную в маркированных списках, читают очень охотно)
15. Ключевые мысли и фразы нужно выделять, чтобы читателю было за что «зацепиться» взглядом
16. Прямая речь или цитаты желательно выделять курсивом или использовать рукописный шрифт
17. Курсив легче воспринимается на бумаге, чем на экране, поэтому не переборщите с его использованием 
18. Используйте в тексте цифры и числа – они «разбавляют» словесную кашу
19. Чем длиннее ваш текст – тем на старте меньше хочется его внимательно читать
20. Старайтесь ограничить количество слов, написанных заглавными буквами, особенно в заголовках и подзаголовках
21. Не используйте в тексте разный цвет шрифта или заливки 
22. В одном тексте должно использоваться не больше 2-ух разных шрифтов
23. «Тире» на экране читается легче, чем «двоеточие» и «точка с запятой»
24. Ваши ссылки должны быть оформлены заметно


Книги, газеты, интернет… сложно представить себе тот объём текста, который прочитывается людьми в течение дня. Наши глаза перемещаются из стороны в сторону, со строчки на строчку, и подчас мы не задумываемся, что могли бы прочитать определённый кусок текста быстрее или могли бы меньше утомиться, прочитав какую-либо статью. С газетами и журналами всё ясно — различные издательства заботятся о своих творениях, и в большинстве случаев соблюдают необходимые правила. А как насчёт интернета?

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

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

ИССЛЕДОВАНИЯ ПО ОПТИМАЛЬНОЙ ДЛИНЕ СТРОКИ ТЕКСТА
ИCССЛЕДОВАТЕЛЬГОД ИССЛЕДОВАНИЯОПТИМАЛЬНАЯ ДЛИНА СТРОКИПРИМЕЧАНИЕ
Вебер188110смМаксимальная длина 15см.
Джавель18819см-
Тинкер и Паттерсон19297,5-9смИспользовался черный текст размером 10 пунктов на белой бумаге. Параграфы длиной 18,5см читались медленнее остальных параграфов.
Кон19839смМаксимальная длина 10см
Дачники и Колерс198318,7смСтрока длиной 18,7см читалась быстрее на 28% чем 1/3 длины монитора — 6,2см.
Дайсон и Киппинг199818,2смИспользовался текст размером 12 пунктов. Тесты показали, что скорость чтения увеличивается вместе с увеличением количества символов в строке. Медленней всего читался текст длиной 10см. Несмотря на то, что текст в одной колонке читался быстрее, чем этот же текст в 3-х колонках, пользователи предпочитали 3-х колоночный формат.
Янгмэн и Шарф199920смИспользовался текст размером 12 пунктов. 20см были оптимальны для скорости чтения, но пользователи предпочитали длину 10-12,5см.
Бернард, Фернандес и Хал200224,5смИспользовался текст размером 12 пунктов. Данный тест не выявил особой разницы в скорости чтения между тремя размерами — 24,5см 14,5см и 8,5см. Взрослые пользователи всё же выбрали 2 более коротких длины.

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

Из прочитанных материалов хочу сделать вывод, что оптимальная длина строки зависит от ситуации; например от отступов, размера и типа шрифта. Но всё же люди предпочитают длину строки в 10 сантиметров (4 дюйма), что равняется примерно 60-ти символам в строке (при относительном размере шрифта 11-13 пикселей).


Если есть желание углубиться в теорию и исследования, то следующие ссылки помогут.



[править | править исходный текст]
Материал из Википедии — свободной энциклопедии
У этого термина существуют и другие значения, см. NULL.
Файл UNIX-устройства/dev/null.
Тип:символьное (c)
ОСmajorminor
Solaris132
LinuxFreeBSD13

/dev/null — специальный файл в системах класса UNIX, представляющий собой т. н. «пустое устройство». Запись в него происходит успешно, независимо от объёма «записанной» информации. Чтение из /dev/null эквивалентно считыванию конца файла (EOF).

В DOS есть псевдофайл NUL с аналогичными свойствами.



Создание[править | править исходный текст]

Псевдоустройство /dev/null считается символьным. Оно создаётся с помощью утилиты mknod следующим образом:

В Linux:

mknod FILE c 1 3

В FreeBSD:

mknod FILE c 0 27

В Solaris:

mknod FILE c 13 2

Здесь FILE — имя для нового пустого устройства. На этапе установки системы оно создаётся таким образом со «стандартным» именем /dev/null.

Примеры использования[править | править исходный текст]

  • Чаще всего перенаправление в /dev/null используется для подавления стандартного вывода (выходного потока) и/или вывода сообщений об ошибках (потока диагностики) программы их перенаправлением в /dev/null, такое подавление чаще всего используется в командных сценариях (shell scripts) для подавления нежелательного вывода на консоль.

Вывод потока стандартного вывода (STDOUT) и потока ошибок (STDERR) в /dev/null:

сделать что-то > /dev/null 2>&1

Вывод потока ошибок (STDERR) в /dev/null:

сделать что-то 2>/dev/null
  • Запуск программы reader, ожидающую в качестве обязательного параметра имя файла ввода, без такового.
 reader /dev/null
  • Проверка доступности всех файлов в каталоге foo и его подкаталогах для чтения.
 find foo/ -type f -readable > /dev/null
  • Очень удобно использовать для обнуления файлов большого размера, например, почтовых ящиков:
 cp /dev/null /var/mail/mike

Жаргон[править | править исходный текст]

На жаргоне системных администраторов и разработчиков программного обеспечения null ассоциируется с удалением информации. Например, «моя почта сохраняется на null» означает что вся поступающая почта удаляется, «шлите жалобы на null» означает не беспокоить жалобами, «шлите пожертвования на null» означает, что пожертвования не принимаются, а «redirect to null» означает послать подальше или игнорировать.

См. также[править | править исходный текст]

4 марта 2014
Для Windows XP и ранее:

Для этого нажмите меню "Пуск", там выберите "Выполнить" и введите там слово cmd после чего нажмите Enter.

У вас откроется командная строка Windows. Введите там следующую фразу: ipconfig /flushdns и нажмитеEnter.

Если вы увидите следующее:
Настройка протокола IP для Windows
Успешно сброшен кэш распознавателя DNS.

то значит кэш DNS очищен. Можно закрыть командную строку.

Для Windows Vista, Windows 7:

Для этого нажмите меню "Пуск", там в строке Поиска внизу введите слово cmd. после чего нажмите Enter. У Вас найтеся программа cmd, запустите её.

У вас откроется командная строка Windows. Введите там следующую фразу: ipconfig /flushdns и нажмитеEnter.

Если вы увидите следующее:
Настройка протокола IP для Windows
Успешно сброшен кэш распознавателя DNS.

то значит кэш DNS очищен. Можно закрыть командную строку.

Для установки сетевого адаптера atheros ar8121/ar8113/ar8114 в centos 6.5

посмотреть адапетры
 lspci | grep et
выполняем действия
Ставим ключик репозитория:
# rpm --import http://elrepo.org/RPM-GPG-KEY-elrepo.org
Ставим модуль ядра:

rpm -Uvh http://elrepo.org/linux/elrepo/el6/i386/RPMS/kmod-atl1e-1.0.1.14-1.el6.elrepo.i686.rpm

Подключаем его:
# modprobe -v atl1e

источник

Философия UX

Тут доклады про глобальное и стратегическое: тренды, концепты, подходы.


«Маленькие советы дизайнерам» — Импозантный Максим Ткачук, одетый в стиле «стивджобс, да еще в дизайнерских очках», размышлял об эволюции, как в дизайне и UX, так и о эволюции карьеры правильного юзабилиста. История дизайна, как осознанного конкурентного преимущества, об основных трендах и их причинах («послевоенный минимализм», «айпад породил адаптивный дизайн»), и собственно, практические советы как по проектированию («Small First»), так и по карьере («Zoom Out», удалите фотошоп и переходите на темную бизнес-сторону). Кстати, ему дали главный приз конференции.
«Секонд-хэнд проектирование» — Да, все знают, что «Un artista copia, un gran artista roba»©, что в мире дизайна давно превратилось в «воруй@процветай», и тут как раз о том, как сделать это правильно, чтобы не стать посмешищем и жертвой карго («говносайты под Win8»), и наоборот, где можно расслабится с исследованиями, и доверится трендам («карусели или параллакс?», «скеоморфизм или delicious flat chest?»…) дополнив лишь «одушевляющими» мелочами.
«NUI или почему не устанет рука» — Эволюция интерфейсов от старой доброй командной строки к неведомому Natural UI. Истории о носимых компьютерах, дополненной реальности, айтрекер-интерфейсы для инвалидов и нейроинтерфейсы для дополнительной невербалики. Размышления о том, где это может быть необходимо, а где не пришей вероятно излишне. Жаль только, что хоть докладчик и принес коробочку с Leap Motion, живьем ничего не демонстрировалось. Очень рекомендую докладчикам на эту тему, делать Тру-демонстрации → вот, еще в 2011 году на WUD были живые демонстрации NUI c самописным софтом. К сожалению, также не было четкого ответа — к чему собственно готовится UX-проектировщиках — тут я, пользуясь случаем, порекомендую развлечься сериалом «Black Mirror».
«Gamification in Action» — понятное дело, о прожужавшей всем уши «геймификации», по крайней мере все знают, что это все про «карму, беджики и прочие ачивки». Однако если нужно системно спроектировать игровые механики, этих знаний недостаточно — получится в духе «сделаем карму и грабить корованы», тут нужен некий матан, который нужно вкуривать либо из толстых книжек и длинных курсов на курсере, или — посмотрев этот короткий доклад, где изложена формальная система «октализа» для построения сбалансированной игровой модели.

Best practices

Тут конкретные рассказы об аспектах и практиках, как делать это правильно.


Начнем с проектирования — ««Методики описания и визуализации UX» — как делать это эффективно? Тупо описывать действия персонажей? Долго и муторно. «Story Mapping» — выделять цели, декомпозировать на задачи, и искать базис UX-инструментов для решения? «Вопрос—ответ»? «Customer Journey»? Или вообще бросить писать, и побольше рисовать комиксов — это «Story Boarding».
После описательного-рисовательного проектирования важно начинать получать фидбек и прокачивать гипотезы на работоспособность — и об этом «Быстрое прототипирование для веб и мобильных устройств» — доклад канадского специалиста на английском, но с крутым почти-синхронным переводом (по наблюдению, перевод местами удачней исходного доклада). Тут и Философия Прототипа (а то некоторые неучи путают прототип с информационной архитектурой, макетом, наброском-wireframe, и первыми версиями софта), до конкретных советов по инструментам — от Powerpoint+Keynote (очень спорная идея, имхо) до, вероятно, самого популярного Axure (более половины зала подняли руки), и более модных вебсервисов, типа proto.io.
Как улучшать продукт, когда первые ступени техзаданий и прототипов уже отброшены, продукт живой и в полете? — «Рука об руку с эффективностью — сплит-тесты». Не тратьте время на субъективные фокус-группы — A/B-тестирование на всей настоящей аудитории даст самый правильный ответ. Больше конверсии, больше! Grow Hacking! Собственно тут да, маркетинг, тоже смежная с UX область, но все же другая — вряд ли хоть один дизайнер и UX-ер сможет использовать в своей презентации Comic Sans (аудитория была в шоке, твиттер взорвался, а докладчица интересовалась в кулуарах «а что такого?»).
«Проектирование адаптивного интерфейса» — Да, пришествие смартфонов и прочих планшетов заставляют впихивать невпихуемые декстопно-вебовые интерфесы в амбразуры мобильников — и тут как раз, как это проектировать и делать, как должны трансформироваться информационные блоки, как — меняться контент («адрес и как доехать важнее в мобильной версии»), какие хаки человеческого восприятия (гештальт-обрезка картинок) можно использовать.
«Экранные приложения с большим количеством информации». Весьма прикольно, когда можно проектировать интерфейс в духе эстетического минимализма (картинка-про-интерфейс-гугла-эппла-ибизнесформы.jpg), для расслабленных пользователей, которых можно побаловать пустым пространством и красотами параллакса, и сэкономить на разработке и поддержке, используя вышеупомянутый адаптивный дизайн. Вопрос в том, что делать, если интерфейс принципиально состоит из таблиц с данными — финансово-учетные интерфейсы, и при этом все-таки нужна эффективность — т.е. за рулем сидит не тетушка, которой нужно заполнить десяток форм-карточек в день, а например, заряженный амфетаминами трейдер. Тут на счету каждый пиксель и движения, и надо понять, как упаковать максимум информации и чтобы все рулилось минимум движений, и при этом не требовало многолетнего обучения.
Ну и конечно, отдельный мир интерфейсов — игры. Тут был свежий взгляд на игромир с точки зрения классического вебUXера —«Сможет ли проектировщик взаимодействия в вебе стать проектировщиком в игровой индустрии?». C одной стороны, вроде сложнее, и навороченные миры, и неприменимы классические метрики и вообще много гитик, с другой — это Среда, которая рулит пользователем (тут я рекомендую Пелевинский «Шлем Минотавра», как мистическую UX-философию компьютерных сред), и да, тут реально рулят «шлемилем», хитрым образом меняя ракурсы камеры, не давая отвлечься постоянной анимацией, пугая его звуком, страшно подумать, что будет, когда в массы придут настоящие шлемы/3D-очки.
Отдельная тема — сервисные интерфейсы игр, которые тоже можно неслабо геймифицировать. У них до сих пор неразгаданная загадка — «Очень часто игроки перед началом боя заглядывают в дуло своему танку, по непонятной нам причине» — может кто объяснит в комментах?
Кстати, на тему «юзабилити и World of Tanks» я снимал и другие доклады → «Год в ТАНКЕ. Хроники UX-лаборатории», «Проектирование взаимодействия в многопользовательских он-лайн играх».

Процесс

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


«UX исследования на всех этапах разработки продукта» — финансово-бухгалтерский софт, но разрабатываемой уже давно (См. «Экстремальный аджайл — танцуют все») единой большой командой с юзабилистами внутри. Нужна ли медицински холодная юзабилити-лаборатория, или домашний уют, какие конфликты были у юзабилистов с кодерами и проектировщиками, и как удалось победить («программисты сами попросили об исследовании!»), как внедрять юзабилити, и где на это выбивать ресурсы. Рассказ в картинках и фотографиях, все визуально, хотя местами грустно видеть плотнозабитый опенспейс команды — неужели в таких тяжких условиях можно сделать красивый дизайн?
«Где кончается проектирование и начинается дизайн?» — явно бизнес-менеджерский взгляд из заказной разработки — в противовес чисто дизайнерскому-перфекционисткому подходу, позволительному только в очень больших продуктовых подходах. Тут же надо понять эту грань, между проектированием, дизайном и рисованием, чтобы не «заиграться в дизайн» (забудьте слово «не нравится»), не зафейлить сроки-деньги, и как максимально эффективно удовлетворить именно того заказчика, который принимает решение. И наоборот, местами стоит потратиться, чтобы не напугать заказчика грубыми скетчами, и соблюдать хотя бы минимальные классические советы «недизайнерам о дизайне» (вайтспейс, типографика, сетки, контрасты...), или использовать стандартные Axuroвские библиотеки.
«Секретная техника самураев Toyota» — это тоже менеджерское кун-фу на тему приоритезации. Тут скорее гибрид Lean UX с очень странным матаном (хитрая матрица приоритезирующих коэффициентов, из однихпотолковых слабоопределенных цифр заданых для фич, вычисляющих их приоритеты. Правда докладчик признался, что менеджеры смотрят на них, но поступают по своему — и это наверно правильно.
«Исследования интерфейсов в Яндексе» — Ну и это вершина процесса, когда у ребят есть ВСЕ, и можно позволить себе сделать Идеальный Research-процесс (только исследование, никаких рекомендаций, строгая научная чистота и отстраненность — проектирование это удел касты инженеров). В то время, как большинство компаний только мечтает о исследованиях, а наиболее крутые записываются в очередь на аренду пары часов в оборудованную лабораторию с айтрекером (если кто не в курсе — эти девайсы стоят десятки тыщ, Tobii X120 $40K-$70K), тут, повторюсь, есть все. И оборудованная лаборатория с односторонними зеркалами и кучей айтрекеров (для выездов есть тревожные чемоданчики с портативными айтрекерами) + нейротрекеры +…. Собственная база пользователей идетективное агенство подрядчики для розыска специальных экземпляров («45 летний пользователь айфона с десятью лямами в кармане собирающийся купить квартиру», «Ах, как сложно было найти пользователя, у которого основным поиском был мейл.ру»). В общем, хорошо быть богатым и здоровым + умным и красивым. Позавидуем, ОК.
Рассматривались и нетривиальные кейсы — «слепая девочка ведет блог, иллюстрируя его картинками из поиска». Кстати, почти никто не подходит к такому сложному снаряду, как компьютерные интерфейсы для слепых, и тут, пользуясь случаем, дам ссылку на доклад с описанием полноценного рабочего стола для слепых, написанного самим слепым программистом → «Luwrain. ОС для людей с проблемами зрения».

Official Red Hat/CentOS packages

To add nginx yum repository, create a file named /etc/yum.repos.d/nginx.repo and paste one of the configurations below:

CentOS:

[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1

RHEL:

[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/rhel/$releasever/$basearch/
gpgcheck=0
enabled=1