Tag: Nginx

Небольшая заметка про подключение letsencrypt на сайт с nginx сервером. За основу взял хабра-статью от @questor-а. Наша задача добавить поддержку https на сайт малой кровью. letsencrypt позволяет нам это сделать, взяв на себя всю чёрную работу по подготовке, выдаче, загрузке и обновлению сертификатов (подробнее). Всё нижеописанное я привожу для linux debian-like систем.

Принцип работы

Для подключения HTTPS необходимы сертификаты (для шифрования и аутентификации). Причём эти сертификаты должны быть выданными доверенными серверами, список которых вшит в браузеры. Обычно это дело было платным, но с недавних пор, появилось несколько доступных и бесплатных альтернатив. Одна из которых это Let’s Encrypt.

Let’s Encrypt выпускает сертификаты бесплатно и в автоматическом режиме на 3 месяца. Для работы с ним подготовлено ПО с открытым кодом и есть открытое API для взаимодействия вручную. Мы воспользуемся готовым рекомендованным ПО.

Принцип работы этого ПО заключается в том, что сервер запрашивает у letsencrypt-центра выпуск новых сертификатов для указанных доменным имён. Для этого letsencrypt-центр ломится на ваш сервер по конкретным URL-ам с этими доменными именами, и убеждается в том, что они принадлежат вам. Затем выпускает новые сертификаты и передаёт их на сервер сайта. ПО складирует их в указанной директории. Вам остаётся лишь подключить их к nginx и настроить автоматическое обновление по cron-у.

Подготовка, подключение и обновление под катом.

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

Ситуация. Сервер сайта генерирует файл и пытается отдать его как статику, задействовав заголовок ETag. Реализовывается вся необходимая логика с возвратом 304 и поглядыванием в if-none-match. Но в итоге упираюсь в то, что браузер в упор не видит ETag заголовок. Первым делом полез смотреть заголовки в curl -v. Но заголовок возвращается. Начинаю ковыряться в разных статьях про ETag на предмет подводных камней. Ничего не нашёл, всё должно работать просто и надёжно. Пробую в разных браузерах. Они в упор не видят заголовка. Начинаю эксперементировать со значением заголовка, расположением в списке других заголовков, прочей чертовщиной заниматься. Очередной подход к google-у выдал мне причину.

Оказалось, что дело в том, что в конфигурации хоста nginx у меня прописано сжимать GZip-ом все ответы с определённым content-type-ом. А nginx при этом срезает ETag. Именно поэтому я видел заголовок в ответе curl-а, но не видел в браузерах. Поправил конфиг ― заработало.

Помимо прочего, я некоторое время не мог завести базовый механизм работы Last-Modified. Браузер упорно не хотел кешировать файл, несмотря на наличие всех необходимых заголовков. Оказалось всё дело в формате даты. Найденные мною быстрые решения для momentjs были кривыми, и браузер их не понимал. В конце некоторых дат указывалось смещение в виде +00:00, и всё ломалось.

Для нужд разработки возникла необходимость в proxy-овании некоторых запросов, в обход CORS-а. Погуглив и слегка причесав код, получилось следующее:

"use strict";

/**
 * run: iojs --harmony_arrow_functions proxy.js
 *
 * nginx:
 * location ~ ^/api.*$ {
 * 	proxy_pass http://127.0.0.1:3001;
 * 	proxy_set_header X-Real-IP $remote_addr;
 * 	proxy_set_header Host $host;
 * 	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 * }
 */

let hostname = '%hostname%';
let port = 3001;
let auth = '%user%:%pass%';
let http = require('http');

http.createServer((clientReq, clientRes) =>
{
	let opts =
	{
		hostname: hostname,
		port: 80,
		path: clientReq.url,
		auth: auth,
		headers: clientReq.headers,
		method: clientReq.method
	};
	opts.headers.host = hostname;

	console.info('serve: %s %s', clientReq.method, clientReq.url);

	let proxy = http.request(opts, (proxyRes) =>
	{
		proxyRes.addListener('data', (chunk) => clientRes.write(chunk, 'binary'));
		proxyRes.addListener('end', () => clientRes.end());
		clientRes.writeHead(proxyRes.statusCode, proxyRes.headers);
	});

	clientReq.addListener('data', (chunk) => proxy.write(chunk, 'binary'));
	clientReq.addListener('end', () => proxy.end());
}).listen(port);

Запускается путём выполнения iojs --harmony_arrow_functions proxy.js, логирует все запросы в консоль. Точно умеет POST, GET, отдавать статику… Для простых нужд вполне сгодится. Жаль браузеры пока толком не умеют arrow functions :(

После обновления на живом сервере с php5.3 до php5.5 столкнулся с неприятной проблемой. Socket-файл, для прослушивания nginx-ом, который создаёт при старте демон php5-fpm, стал недоступен для nginx, который запускается от www-data. Лечится это дело очень просто, необходимо в pool-конфиги добавить следующее:

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Думаю по названиям настроек всё более чем понятно. Жаль только, что когда я попробовал перенести эти настройки на уровень выше, в сам php-fpm.conf, демон споткнулся при старте. Так было бы удобнее.

Перенеся сервер, на котором расположен deltaplan.kz, с apache2 на php-fpm, я столкнулся с неожиданной проблемой. Несмотря на правильным образом настроенные nginx конфиг и php-fpm pool GPS-подсайта — сервер упрямо, вместо того, чтобы запускать PHP файлы, возвращал их исходный код. Первым делом я вспомнил про security.limit_extensions = .php. Затем полез мучить различные fastcgi-параметры nginx хоста. Однако враг зашёл с другой стороны. Дело в том что в /etc/php5/fpm/php.ini по непонятным мне причинам был установлен short_open_tag: Off, в то время как XC Leonardo вовсю использует сокращённый вариант <? ?>. Разрешив эту опцию и перегрузив php5-fpm всё взлетело.