ПРИМЕЧАНИЕ. Этот ответ предполагает, что вы обладаете достаточными знаниями об общих командах Linux и / или, по крайней мере, имеете возможность войти в свой маршрутизатор через SSH. Если вы этого не сделаете, то вам следует освежить свои навыки, чтобы выполнить эти предварительные условия, прежде чем продолжить, поскольку я не планирую освещать основы сценариев Linux или команд в ответе или в последующих комментариях.
Справочная информация и отказ от ответственности (1.2 безопасен, но 1.14 работает)
Маршрутизаторы Ubiquiti Edge в настоящее время основаны на Debian 7.11 - т.е. wheezy - и, следовательно, лучшее, что вы получите, не нарушая норм, - это nginx 1.6 (с использованием репозитория wheezy-backports вместо или в дополнение к wheezy). Это будет работать для поддержки веб-сокетов, но новые опции, такие как http2, все еще будут отсутствовать.
Чтобы получить более новые версии, такие как 1.14, вам нужно будет немного выйти из зоны комфорта и начать использовать новые репозитории Debian 9.5 - то есть stretch и stretch-backports . Я говорю "выйти из своей зоны комфорта" не из-за плохого опыта, а потому, что логика подсказывает, что, вероятно, есть причина, по которой Ubiquiti все еще использует wheezy на маршрутизаторе. Таким образом, некоторый риск связан с использованием пакетов stretch когда они зависят от обновления других пакетов, которые может использовать маршрутизатор (например, libc6).
Поэтому, хотя я не могу сказать, что приведенное ниже решение не нарушит ЛЮБУЮ функцию на маршрутизаторе, я могу сказать, что я использую значительное количество функций маршрутизатора (включая сервер / клиент openvpn, балансировку нагрузки и VLAN), и у меня нет не было никаких проблем.
Я также был в состоянии успешно повторно прошить текущую версию ОС / прошивки Ubiquiti EdgeMax (1.10.8) без каких-либо проблем, которые возвращают все пакеты к их исходным / стандартным версиям. (но учтите, что при перепрошивке прошивки также стираются все сделанные вами изменения / настройки, которые вы не сохранили в каталоге /config - всегда храните их где-нибудь в /config а затем добавьте сценарий запуска в /config/scripts/post-config.d который поддерживает ссылку на них в других местах по мере необходимости)
Итак, я чувствую себя довольно комфортно, говоря, что будущие обновления Ubiquiti, вероятно, будут устанавливаться нормально после этой установки - хотя вам придется переустанавливать nginx снова (возможно, используя скрипт ниже).
Теперь, когда обычные заявления об отказе от ответственности находятся в стороне, вот что работает для меня.
Мое решение (нарушить правила и получить 1.14)
Безопасность прежде всего
Сделайте резервную копию вашего конфига.
Если вы уже пытались установить nginx, неплохо было бы также продолжить и переустановить последнюю версию прошивки, чтобы вернуть все обратно к хорошей базовой точке (будьте осторожны, если вы добавили какие-либо настройки / настройки вне обычной конфигурации CLI или параметров веб-интерфейса - вы можете их потерять).
Поскольку вы будете работать со службами, которые управляют веб-интерфейсом, вероятно, было бы разумно ознакомиться с командами, необходимыми для прошивки обновлений прошивки также из SSH (СОВЕТ: add system image https://dl.ubnt.com/firmwares/edgemax/v1.10.x/ER-e100.v1.10.8.5142440.tar).
Теперь самое интересное
SSH * в ваш маршрутизатор и запустите следующий скрипт (или эквивалентные операторы), который будет:
- Настройте соответствующие репозитории Debian (
stretch и stretch-backports)
- Настройка приоритеты хранилища предпочитать
stretch-backports (если вы хотите использовать Nginx 1.10.3 измените ниже сценарий предпочитают stretch , а не stretch-backports удалив его из приоритета - 910)
- Настройте сценарий запуска, который будет использоваться для создания каталога журнала nginx при каждой загрузке системы (в противном случае nginx не запустится при перезагрузке маршрутизатора)
- Загрузите / установите последний стабильный пакет nginx-light (1.14.0 на момент написания статьи).
* Вам НЕ следует использовать функцию CLI в веб-интерфейсе вместо SSH, поскольку веб-интерфейс, вероятно, станет временно неработоспособным как часть этого процесса.
#! /bin/bash
vcfg=/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper
echo Updating package repositories ...
echo
$vcfg begin
$vcfg delete system package
$vcfg set system package repository stretch url http://ftp.us.debian.org/debian
$vcfg set system package repository stretch components "main contrib non-free"
$vcfg set system package repository stretch distribution stretch
$vcfg set system package repository stretch-backports url http://ftp.us.debian.org/debian
$vcfg set system package repository stretch-backports components "main contrib non-free"
$vcfg set system package repository stretch-backports distribution stretch-backports
$vcfg commit
$vcfg end
apt-get update
echo
echo Setting repository priorities ...
echo
echo "Package: *
Pin: release a=stretch
Pin-Priority: 900
Package: *
Pin: release a=stretch-backports
Pin-Priority: 910">/etc/apt/preferences.d/stretch
echo
echo Temporarily stopping the current web interface ...
echo
kill -SIGTERM $(cat /var/run/lighttpd.pid)
echo
echo Installing nginx-light ...
echo
echo "#! /bin/bash
[ -d /var/log/nginx ] || mkdir /var/log/nginx">/config/scripts/post-config.d/create_nginx_log_dir
chmod a+x /config/scripts/post-config.d/create_nginx_log_dir
[ -d /var/log/nginx ] || mkdir /var/log/nginx
apt-get install nginx-light -V -y
echo
echo Restarting the old web interface ...
echo
service nginx stop
/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
echo
echo Updating the nginx default site listen on non-standard ports ...
echo
sed -i -E 's/^(\s*)(listen\s+(:|\[|\])*)([0-9]+)(;|\s)/\1\2\4\4\5/g' /etc/nginx/sites-enabled/default
echo
echo Starting the nginx service ...
echo
service nginx start
echo
echo Installation complete.
[Ответьте «y Enter » на запрос о перезапуске служб]
Теперь у вас должна быть работающая установка nginx, и вы сможете проверить ее, перейдя по http://<router IP address>:8080 в вашем веб-браузере. Обратите внимание на использование порта 8080 который должен был быть настроен командой sed в приведенном выше сценарии, а не по умолчанию для порта 80 который, вероятно, конфликтовал бы с вашим веб-интерфейсом маршрутизатора по умолчанию.
Будет ли nginx служить обратным прокси-сервером для вашего роутера?
Лично я предпочитаю использовать нестандартный порт (553 в приведенном ниже примере конфигурации) для службы / графического интерфейса lighttpd предоставляемой по умолчанию на маршрутизаторе, а затем использовать nginx (прослушивание на стандартных портах 80/443) в качестве обратного прокси-сервера для lighttpd , Это позволяет мне использовать одно доменное имя для всех веб-сайтов моей локальной сети, включая маршрутизатор (т.е. router.myhouse.com, nas.myhouse.com и т.д.) Если вы хотите сделать то же самое, вы можете изменить свой порт графического интерфейса с помощью инструкции configure -> set service gui http(s)-port ### или сделать то же самое изменение в разделе Config Tree веб-интерфейса / графического интерфейса.
Настройте nginx с помощью файла конфигурации обратного прокси
Далее вы захотите настроить nginx для работы в качестве обратного прокси-сервера для некоторого ресурса. Как правило, это будет ресурс локальной сети, доступный с использованием определенного имени хоста / домена в URL-адресе, который разрешается в порт прослушивания nginx маршрутизатора.
Для этого вы создаете файл конфигурации nginx в каталоге /etc/nginx/sites-enabled (или, что еще лучше, создаете его в /config/user-data а затем создаете ссылку на него в /etc/nginx/sites-enabled каталог - это облегчит восстановление после обновлений, которые сбрасывают содержимое каталога /etc ).
Существует множество примеров файлов конфигурации nginx в сети, но приведенный ниже пример может оказаться полезным, если вы планируете разместить свой интерфейс маршрутизатора (или какой-либо другой веб-сайт, использующий веб-сокеты) за обратным прокси-сервером nginx. Или, если вы хотите специально установить Synology NAS (фотостанция, в частности, немного хитрая).
upstream edgemax {
server 192.168.1.1:553;
keepalive 32;
}
upstream nas {
server 192.168.1.7:5001;
keepalive 32;
}
upstream nasphoto {
server 192.168.1.5:443;
keepalive 32;
}
upstream nasfile {
server 192.168.1.7:7001;
keepalive 32;
}
server {
listen 443 ssl http2;
server_name router.*;
ssl_certificate /config/user-data/ssl_chain_key.pem;
ssl_certificate_key /config/user-data/ssl_chain_key.pem;
client_max_body_size 0;
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
location / {
proxy_pass https://edgemax;
}
}
server {
listen 443 ssl http2;
server_name nas.*;
ssl_certificate /config/user-data/ssl_chain_key.pem;
ssl_certificate_key /config/user-data/ssl_chain_key.pem;
client_max_body_size 0;
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
location / {
proxy_pass https://nas;
}
location /photo {
proxy_pass https://nasphoto/photo;
}
}
server {
listen 443 ssl http2;
server_name files.*;
ssl_certificate /config/user-data/ssl_chain_key.pem;
ssl_certificate_key /config/user-data/ssl_chain_key.pem;
client_max_body_size 0;
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
location / {
proxy_pass https://nasfile;
}
}
server {
listen 443 ssl http2;
server_name photos.*;
ssl_certificate /config/user-data/ssl_chain_key.pem;
ssl_certificate_key /config/user-data/ssl_chain_key.pem;
client_max_body_size 0;
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
rewrite ^/photo/(.*)$ /$1;
location / {
proxy_pass https://nasphoto/photo/;
}
}
Как только файл конфигурации обратного прокси-сервера будет создан, вы можете запустить sudo service nginx restart чтобы сделать его эффективным. Обратитесь к /var/log/nginx/error.log если есть проблемы.
СОВЕТ № 1: Если вы планируете использовать нестандартный порт для обратного прокси-сервера nginx (т. Е. В конфигурации вашего обратного прокси-сервера указано что-то отличное от listen 80 и / или listen 443), вы, вероятно, будете готовы заменить proxy_set_header Host $host; в приведенном выше конфиге с proxy_set_header Host $http_host; , Это особенно важно для веб-сокетов, которые, кажется, всегда хотят, чтобы веб-клиенты запрашивали трафик через порты по умолчанию, в противном случае это приводит к интерфейсам, в которых отсутствуют компоненты или текущие данные. (Вы также можете попробовать proxy_set_header Host $host:$server_port; но учтите, что это заметно отличается, так как он всегда добавляет порт в заголовок, даже если он не использовался в исходном запросе)
СОВЕТ №2. Также обратите внимание на использование server_name router.* Что просто означает, что использование URL- маршрутизатора. < Что- router.<anything>.<anything> Что- нибудь> для просмотра обратного прокси-сервера nginx приведет к применению этого раздела конфигурации. (В большинстве примеров вы найдете полное / явное доменное имя, например router.domain.com)
Это полезно не только с целью возможного изменения доменных имен / имен DNS (т. Е. Работает для router.home.com а также router.home.net без изменения конфигурации), но также помогает сократить ваши записи server_name . Это важно, потому что длинные имена часто приводят к ошибкам, говорящим о том, что "при увеличении размера корзины" вы запускаете nginx. Если у вас должны быть длинные имена, вам, вероятно, потребуется настроить значения server_names_hash_max_size и / или server_names_hash_bucket_size в вашей конфигурации.
ОБНОВЛЕНИЕ: я успешно обновил свой маршрутизатор с EdgeOS версии 1.9.1 до каждой версии между 1.10.8 включительно и практически без проблем. На маршрутизаторе не было nginx после обновления (как и ожидалось), но я смог запустить свой скрипт (первый блок кода в этом ответе), и он вернулся обратно. Сохранение настроек в /config и использование сценариев в /config/scripts/post-config.d для поддержки любых изменений, которые не переживают перезагрузку / обновление, является ключом к плавности плавания здесь.
ОБНОВЛЕНИЕ № 2: Этот процесс работает на меньших маршрутизаторах, таких как ER-X. Однако из-за ограниченного объема памяти на устройстве вам придется удалить неактивный образ прошивки, чтобы освободить место для nginx. Это нужно делать и после каждого обновления. Чтобы удалить неактивный образ прошивки, запустите delete system image и ответьте «да» на приглашение (я).
- Мой процесс обновления ER-X -
- Сделайте резервную копию моего конфига !!!!
- Обновите микропрограмму до последней версии и перезагрузите компьютер (и проверьте основные функции, отличные от nginx)
- Удалите старую прошивку (которая теперь является неактивным образом) с помощью команды
delete system image (show system storage отчеты об использовании системы хранятся 80% до удаления и 36% после)
- Используйте сценарии / шаги выше, чтобы переустановить nginx (показать отчеты о
show system storage 79% после установки)
- Запустите
sudo apt-get clean чтобы освободить место, используемое временными файлами и т.д. (Показать отчеты об использовании show system storage 61% после очистки)
