Пошук по сайту

Поклонникам чистого NGINX предлагаю ознакомиться с панелью управления aaPanel. CyberPanel - это не для приверженцев чистого NGINX. Просьба воздержаться от проявлений "религиозной" предвзятости по отношению к веб-серверу LiteSpeed, в тоже время приветствуется анализ с фактическим набором данных, а не голословные утверждения. CyberPanel и веб-сервер LiteSpeed могут быть интересны как альтернатива веб-серверам с поддержкой .htaccess: Apache Nginx+Apache Т.е. имеет смысл сравнивать ситуации одного порядка. Не вполне корректно делать сравнение ситуаций с поддержкой htaccess и без нее. Без htaccess работает NGINX, и NGINX практически всегда будет лучшим решением. Но если нужен htaccess, то из вашего выбора выпадает чистый NGINX , но остается, например, вариант Nginx+Apache или LiteSpeed. Друзья, старался подготовить доступное руководство на русском языке по установке и управлению CyberPanel - бесплатной панелью управления сервером (VDS/VPS). Попробую подробно, с освещением плюсов/минусов и подводных камней. Несущественные моменты, понятные итак большинству специалистов, знакомых с Linux (FreeBSD) буду опускать чтобы не загромождать слишком описание. Но иногда буду давать наиболее полное описание чтобы даже начинающий мог провести успешно установку. Но все же знания Linux хотя бы в общих чертах приветствуются. Данная статья по большей части не является перепечаткой (переводом) или компиляцией информации из разных источников, а основана на собственном опыте, многие нюансы просто нигде не описаны пока на просторах интернета. Особенно применительно к Opencart. Итак, CyberPanel + веб-сервер LiteSpeed + LSPHP. Весьма достойный выбор в качестве основы для размещения магазинов на опенкарт. Причем, высоконагруженных магазинов с количеством товаров от 100 000 в том числе. Про LSPHP смотрим здесь: https://www.php.net/manual/ru/install.unix.litespeed.php Все знают про веб-серверы Apache и Nginx, которые могут работать как самостоятельно, так и в связке Nginx + Apache (фронтэнд + бэкЭнд). Есть еще один интересный веб-сервер - это LiteSpeed , который есть в бесплатной (OpenLiteSpeed ) и коммерческой версии. По популярности, конечно, Apache и Nginx будут впереди, но на сегодня доля LiteSpeed - это почти 10%. Статистику можно посмотреть здесь: https://w3techs.com/technologies/details/ws-litespeed Большинству специалистов известна очень удобная (в первую очередь для непрофессионала) панель управления сервером ISPmanager. Пожалуй, плюсов в ISPmanager гораздо больше чем минусов. Это одна из самых продвинутых и удобных панелей управления. Но недавно появился дополнительный (относительный) минус - это повысилась ее стоимость в Lite версии с одновременным ограничением на кол-во используемых доменов - до 10, включая поддомены (на автоподдомены ограничение не распространяется). Если нужно поддержать более 10 доменов - тут уже нужно выбирать ISPmanager Pro (до 50 доменов). Кроме платных панелей управления есть бесплатные (некоторые среди них свободные с открытым кодом, часть - закрытые с проприетарным кодом). И есть очень даже надежные и удобные панели управления. Я работал с разными, штук пять достойных вполне можно обозначить. Сразу скажу, что говорить про панель Vesta CP уже нет смысла, т.к. развитие и поддержка сошли на нет, в прошлом панель имела проблемы с безопасностью, в общем, остается забыть про нее. Благо, что есть достойные альтернативы. Для поклонников Vesta CP: Начну краткий обзор с CyberPanel. Позже планирую осветить и другие достойные панели управления. Инструкцию по установке с определенными нюансами прикладываю ниже. Есть свои подводные камни. Постараюсь осветить максимально подробно трудности и способы их преодоления. Материал буду дополнять. У меня он уже подготовлен в гораздо большем объеме чем сейчас я выкладываю здесь. Я довольно подробно останавливаюсь на выборе определенной ОС, приведу сравнительный анализ, что и какой именно набор софта вы получите в случае одной или другой ОС. Сразу скажу, что в случае CyberPanel нельзя говорить, что можете ставить то, что вам нравится и ли к чему привыкли, т.к. есть определенные ограничения софта, которые вы получите в случае разных ОС, и обойти вы их просто так не сможете. Нужно понимать, что веб-сервер OpenLiteSpeed требует довольно специфические сборки php - LSPHP, которые вы просто так не соберете самостоятельно и не установите в случае необходимости в отличие от php как модуля Апачи, cgi, php-fpm. А именно веб-сервер OpenLiteSpeed поставляется вместе с панелью управления CyberPanel. OpenLiteSpeed функционально заменяет Апачи, Nginx и их связку. При этом скорость будет на уровне чистого Nginx + php-fpm, это если верить разработчикам веб-сервера и независимым тестировщикам. Однако, любые заявления самих разработчиков всегда стоит ставить под сомнения, т.к. лукавого подхода в сравнении с продуктом конкурента никто не отменял. Не помешает сделать сравнительные тесты самостоятельно на вполне реальных задачах опенкарт. Плюс возможность кеширования HTML на уровне веб-сервера, т.е. без всяких ускорителей-кешеров. Специально для опенкарт есть официальный модуль. Но это отдельный вопрос, со своими плюсами и минусами, постараюсь его осветить позже более подробно. OpenLiteSpeed умеет работать очень быстро со статикой (файлы изображений, js, css, шрифты и прочие подобные файлы) и с php. Кстати, очень многие крупные хостинг-провайдеры отдали предпочтение именно веб-серверу LiteSpeed. Например, крупнейший провайдер Украины ***** использует LiteSpeed (коммерческий вариант) для предоставления обычного (виртуального) хостинга. Сайт разработчика панели CyberPanel. Процесс установки CyberPanel кратко описан здесь. Разработчиком CyberPanel заявлена совместимость с операционными системами: Centos 7.x, Centos 8.x, Ubuntu 18.04, Ubuntu 20.04 Поддержка Linux Debian не заявлена в CyberPanel . Но сам веб-сервер OpenLiteSpeed устанавливается на Debian без проблем. К тому же есть еще одна весьма достойная бесплатная панель управления, которая поддерживает OpenLiteSpeed , Apache или чистый Nginx на выбор. Я говорю про aaPanel - это Open Source панель управления для серверов. Что примечательно, наиболее полная поддержка всевозможного софта в aaPanel опять же достигается именно в Centos 7, т.е. некоторый полезный софт есть только под Centos 7. aaPanel поддерживает Centos 7, Debian, Ubuntu, т.е. в этом случае выбор ОС будет шире. Панели управления aaPanel я посвящу отдельный блог, она явно этого заслуживает, а также сделаю сравнение с CyberPanel и ISPmanager. CyberPanel работает совместно с веб-сервером OpenLiteSpeed (или с его коммерческой версией). OpenLiteSpeed понимает конфигурационные файлы Apache .htaccess, поэтому можно считать, что программное обеспечение, которое рассчитано на работу с Apache, будет также работать и под OpenLiteSpeed. Работа CyberPanel с Apache или Nginx не предусмотрена. Если говорить про быстродействие, то можно утверждать, что OpenLiteSpeed с успехом заменяет связку Nginx + Apache, т.е. по быстродействию он не уступает этой связке, но превосходит по быстродействию Apache (если тот работает один без Nginx). OpenLiteSpeed имеет расширение для Opencart, позволяющее использовать кеширование страниц средствами самого веб-сервера. Выбирайте правильно операционную систему Linux нужной версии. Более старая версия поддерживает более старые версии php, а не только самые свежие. Если использовать Ubuntu 18.04 , то будут доступны php версий: 7.0, 7.1 (с поддержкой mcrypt), 7.2, 7.3, 7.4, 8.0 (без поддержки mcrypt). Если же нужно использовать php 5.6, то тогда стоит установить Linux Centos 7.X, поддержка которой прекратится 01.01.2025. ВАЖНО IMPORTANT Важно понимать, что в случае Ubuntu 20.04 и использовании CyberPanel вам будут доступны для работы с веб-сервером OpenLiteSpeed только версии php (lsphpXX ): 7.2, 7.3, 7.4, 8.0. В этих версиях нет расширения mcrypt, необходимого для определенных версий Opencart, и вы не сможете самостоятельно его установить в отличие от случаев если бы вы использовали веб-сервер Nginx или Apache (но эти веб-серверы CyberPanel не поддерживает). Также вы не сможете установить другие более старые версии lsphpXX, например, lsphp56 или lsphp71. Устанавливайте Ubuntu 18.04 если вам нужны php (lsphpXX ) 7.0, 7.1, в которых есть расширение mcrypt. Версии php 7.2...8.0 в Ubuntu 20.04 не содержат mcrypt. Если нужны все версии PHP (5.3...8.0) с поддержкой mcrypt, то тогда нужно использовать ОС Centos 7. Впрочем, от расширения mcrypt можно в принципе совсем отказаться в Opencart и заменить его openssl. Самый большой выбор версий PHP будет если установить Centos 7 + CeberPanel. От php 5.3 до php 8.0, что покрывает практически все потребности, особенно если используется движок Opencart старых версий. Для каждого сайта можно назначить свою версию php. Примечательно, что в случае Centos 7 все версии PHP (LSPHP), включая php 8.0, имеют подключенное расширение mcrypt, чего нельзя сказать о варианте для Ubuntu. CyberPanel установит автоматически сервер MariaDB. Но версия данного сервера будет зависеть от того какую ОС вы установили прежде. Для Centos 7 будет установлена самая свежая версия MariaDB 10.5 (актуальная на июнь 2021). Для Ubuntu 18.04 будет установлена MariaDB 10.1, а на Ubuntu 20.04 - MariaDB 10.3 соответственно, т.е. для Ubuntu устанавливаются те версии, которые доступны из репозиториев Ubuntu. Т.е. Centos 7 получается, что будет самым универсальным решением в плане PHP и будет иметь самый свежий софт по сравнению с Ubuntu, не смотря на то, что Centos 7 выпущена ранее Ubuntu 18.04. На Ubuntu также можно обновить MariaDB до 10.5, но более сложным способом. В случае Centos 7 получается все проще и с более предсказуемым результатом. На данный момент (июнь 2021) актуальная версия Centos 7 - это Centos 7.9 от 12 ноября 2020 с ядром Linux 3.10.0-1160. Поддержка (выпуск обновлений безопасности и стабильности) Centos 7 разработчиком заявлена до конца 2024 года. Centos 8 также поддерживает CyberPanel, но поддержка Centos 8 заявлена лишь до конца 2021. Перед установкой панели управления у вас должна быть установлена Centos 7 или Ubuntu 18.04, или 20.04. Далее на примере Ubuntu. Обновление репозиториев Ubuntu: Код: sudo apt update Можем узнать какие пакеты могут быть обновлены: Код: apt list --upgradable Для обновления системы используем: Код: sudo apt upgrade или Код: sudo apt full-upgrade Установите curl: Код: sudo apt install curl Во время установки будет вопрос (выбираем Yes): Проверьте версию установленного curl (для определения успешной установки): Код: curl -V Перезагрузите Ubuntu: Код: reboot Запускаем установку CyberPanel: Код: sh <(curl https://cyberpanel.net/install.sh || wget -O - https://cyberpanel.net/install.sh) В ходе установки будет предлагаться разный выбор опций. Обычно все довольно прозрачно для понимания. На скриншотах ниже показаны большинство выбираемых опций. На запрос установки разных расширений PHP отвечаем "Y". По умолчанию (если при установке не меняли) пароль: 1234567. Разумеется, что его нужно сменить. Задать новый пароль админа панели управления CyberPanel : Код: adminPass newpassword Узнать пароль для пользователя root для MySQL/MariaDB: Код: cat /etc/cyberpanel/mysqlPassword Все пароли для входа в панели управления указаны в отдельных файлах в этой папке /etc/cyberpanel:

Якщо ви використовуєте панелі управління серверами VestaCP/Hestia в режимі Nginx+php-fpm без Apache (то ви вже молодці :). І плануєте встановити (або вже використовуєте) багатомовність з префіксами виду /uk/url.html то перед вами постане одна проблема, яка пов'язана з кривим дефолтним конфігом Nginx в цих панелях. Проблема полягає в тому що сервер не буде обробляти запити типу /uk/index.php?route= і видаватиме помилку 404. Лікуємо. Перед if (!-f $document_root$fastcgi_script_name) { return 404; } в location ~ [^/]\.php(/|$) { потрібно записати if (!-e $request_filename) { rewrite ^/(.+)$ /index.php?_route_=$1 last; }

Переривши безліч інформації щодо кешу та кешування опенкарту, я так і не знайшов простого та бюджетного способу прискорити TTFB. Час від часу я натрапляв на доповнення щодо кешу опенкарту для LiteSpeed. Але чомусь я так і не знайшов жодної дієвої інструкції (та доповнення) як робити дієвий кеш опенкарту в Nginx, особливо якщо у вас шаблон залежний від типу пристрою. І головною проблемою, яка постане перед вами при вирішенні цього питання це .... проксування куків з кешу і бекенду. В кого є які думки з цього приводу? Upd1 Дві функції які роблять твій сайт повільним

Привет хейтеры и друзья. Давно я ничего не писал. Времени ноль, но попробую наверстать упущенное. Последние две недели. Приходит мой друг говорит у меня тут все ложиться, клиенты не могут заказ оформить, база падает! Смотрим. Ну ежкалемене на магазин на 200 товаров филтер бибер И у него 100 000 запросов от гугла в сутки на страницы этого бреда! Вот эта хламина!!! Надробила ему полмиллиона ссылок. С ноиндекс без ноиндекс. Но это бред. Слава богу что друг мой на turbohost и @dinox выдал с барскго плеча временно достаточно ресурсов, чтобы это пережить. Хвала тебе конотопский герой. Что ты поверил в коня и замироточил... Мы реально уже пятый день, ловим 100-200 к запросов на эти все посадочные фильтра от бибера. Это бред. Бредовый бред делат посадочные все со всеми. Мораль - бегите от фильтра бибера, пожалуйста.. Есть вменяемый же Ну или Но друзья, никогда. Прошу вас, никогда ********** filter_viewer, это такая ******** мать**** **ка *** на **й странная вещь! Я не знаю чем думал этот перс, который ее написал! История номер два, которая зацепила до слез, есть у нас такой странный тип @toporchillo, у которого есть модуль для беру ру обмена инфой, и он такой этот усатый типа супер программист и так далее... Но блин этот усатый таракан программист живет в каких то 90х и у него везде апач, а у моих красавчиков у всех nginx. И он такой - ой. А я вот тут что то написал, а как запустить под nginx это не знаю, и это ваши проблемы. Друзья мои.. Если вы столкнетесь с этим товарищем, то вот вам решение для nginx под его модули для маркетплейса беру ru в конфиг nginx добавляем перед location / location /yandexbuy2/ { proxy_hide_header Content-Type; add_header 'Content-Type' 'application/json charset=UTF-8'; rewrite ^/yandexbuy2/(.+)$ /index.php?route=yandexbuy2/$1 last; } location /yandexbuy/ { proxy_hide_header Content-Type; add_header 'Content-Type' 'application/json charset=UTF-8'; rewrite ^/yandexbuy/(.+)$ /index.php?route=yandexbuy/$1 last; } И в сеопро в метод validate добавляем if (isset($this->request->get['route']) && stristr($this->request->get['route'], 'yandexbuy')) { return; } Знаете, для меня до сих пор загадка, почему этот персонаж, который вроде не тупой совсем програмист, не умеет делать такие простые реализации.. Но если он придет и скажет спасибо за то что мне оплатили за его работу, мне будет приятно! Ну и @pikitos пробил дно. $sql .= " ORDER BY nalichie2 DESC, nalichie DESC, Видимо он когда упал с мотоцикла в Тайланде, у него что-то совсем щелкнуло в голове. Мало того что у него был один раз запрос с сортировкой по предварительно вычисляемому полю, ну он еще их решил сделать два. Быстрые магазины, оптимизированные запросы sql, да ваще он хотел Орать на это. Ему лишь бы плюшек пышь пышь больше и на 20 товаров демы типа работает. А то что вот это все загинается на 1000 товаров так его не волнует. Его волнует лишь бы вы велись на обертку, плюшки и покупали. Яндекс и гугл выкинут вас из поиска за долгую загрузку страниц. Ничего страшного. Зато у никиты будут бабулетти для того чтобы в очередной раз арендовать мотик без прав в тае, и надеюсь разбить себе голову наконец, а не только ногу сломать! У меня еще есть для вас много историй и кейсов. Но пока нет настроения их расписывать. p.s. Чуть не забыл. Для тех кто на 1.5 и не только, но юзает это допотопное решение. Пожалуйста, бегите от этого... Вот прямо сейчас. Ибо эта дрянь делает полную перезагрузку DOM после инициализации любой страницы категории и это CLS секунда-полторы, а гугл пейдж спид, очень не любит это дело... Просто потратьте 2-3-4к рублей и смените это морально устаревшее ***но мамонта на что-то внятно и современное!

У меня есть наброски для FastCgi Cache: fastcgi_temp_path /dev/shm/ngx_cache; fastcgi_cache_path /dev/shm/ngx_cache/ngx_fcgi-cache levels=1 keys_zone=phpcache:64m max_size=200m inactive=1d; fastcgi_cache_key "$scheme$request_method$host$request_uri"; fastcgi_store on; fastcgi_cache_lock on; fastcgi_cache phpcache; # The name of the cache key-zone to use fastcgi_cache_valid 200 301 302 304 30m; # кешировать ответы с кодом 200 и.т.д на 1 час fastcgi_cache_min_uses 1; # Кол-во запросов, после которых ответ будет закеширован # Выдаем всегда свежий Last-Modified. expires -1; # Внимание!!! Эта строка expires необходима! add_header Last-Modified $sent_http_Expires; fastcgi_hide_header Set-Cookie; fastcgi_cache_use_stale updating error timeout invalid_header http_500; # Используем вариант из кеша (даже если он устарел) в случае ошибки add_header X-Fastcgi-Cache $upstream_cache_status; # Add header so we can see if the cache hits or misses Но есть очень большое но которое мешает его использовать! ЭТО кеширование ВСЕГО и ВСЯ! Как только не пытался его отключить на не нужных страницах! fastcgi_no_cache $no_cache; fastcgi_cache_bypass $no_cache; location ~ ^/(admin/*|my-account|index.php?route=account/simpleedit|change-password|address-book|wishlist|newsletter|reward-points|returns|order-history|downloads|transactions|index.php?route=account/recurring|index.php?route=account/logout){ set $no_cache 1; } Нужно его отключать на сайте где url начинается с: admin/*|my-account|index.php?route=account/simpleedit|change-password|address-book|wishlist|newsletter|reward-points|returns|order-history|downloads|transactions|index.php?route=account/recurring|index.php?route=account/logout Но чет не получается

Пыталься подружить Nginx-Unit с OcStore 3 не вышло! Т.к OcStore 3 заводится с пинка: location / { try_files $uri @opencart; } location @opencart { rewrite ^/(.+)$ /index.php?_route_=$1 last; } if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?_route_=$1 last; } Не могу как эти костыли перекинуть в nginx-unit! Создал 2 конфига оба не работают! Первая версия: { "listeners": { "127.0.0.1:8380": { "application": "opencart" } }, "applications": { "opencart": { "type": "php", "user": "user_site", "group": "user_site", "processes": { "max": 20, "spare": 5 }, "root": "/var/www/site.com/public_html/", "index": "index.php" } } } И втрорая: { "listeners": { "127.0.0.1:8380": { "application": "index_php_script" }, "127.0.0.1:8381": { "application": "direct_php" } }, "applications": { "index_php_script": { "type": "php", "processes": { "max": 20, "spare": 5 }, "user": "user_site", "group": "user_site", "root": "/var/www/site.com/public_html", "script": "index.php" }, "direct_php": { "type": "php", "processes": { "max": 25, "spare": 5 }, "user": "user_site", "group": "user_site", "root": "/var/www/site.com/public_html", "index": "index.php" } } } А сам конфиг nginx-default: upstream index_php_upstream { server 127.0.0.1:8380; } upstream direct_php_upstream { server 127.0.0.1:8381; } server { listen 443; server_name localhost; root /site/pub...; location / { try_files $uri @index_php; } location @index_php { proxy_pass http://index_php_upstream; proxy_set_header Host $host; } location /admin { index index.php; } location ~* \.php$ { try_files $uri =404; proxy_pass http://direct_php_upstream; proxy_set_header Host $host; } } Может кто уже юзает Ngin-Unit? Поделитесть помощью!

Расскажу вам интересную технологию, которая позволяет без ущерба для ресурсов выживать под гнетом самодурства странных законов тех или иных правительств. Предположим у нас есть магазин в РБ, которому необходимо держать большую нагрузку. Но сервера в РБ стоят диких денег, да и хороших серверов нет. А нам надо разместить сайт где-то на hetzner. По законодательству РБ - это айяй, так как все ресурсы должны быть с айпи, которые принадлежат белорусским провайдерам. Ок ок.. Берем небольшой сервер в РБ, без всяких там панелей, еще чего-то. Ставим чистый NGINX, берем сервер на Hetzner и делаем proxy-прокладку с сервера в РБ на сервер на hetzner. И выглядит это так: мир -> проклада.рб (чистый nginx, который работает как прокси) -> hetzner (с полноценным веб сервером) -> прокладка -> мир. Да мы получим небольшой лаг по времени, но он не сравним с лагами и ценником беларуских хостеров. Радуемся. Если займетесь подобным процессом, вам очень пригодиться вот этот мануал: https://www.digitalocean.com/community/tutorials/how-to-proxy-digitalocean-spaces-with-nginx-on-ubuntu-16-04 Как разворачивать прокси на nginx. И вот этот про то как сделать let's encrypt сертификат для nginx с помощью cert-bot https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-centos-7 Также подобная техника может очень пригодится, если вы находитесь в ру-зоне и по каким-то причинам РКН блокирует ваши домены. Иногда бывают случаи, когда домен блокируется наглухо вместе с аккаунтом у хостера, айпи и самим доменом. И нет возможности что-либо с этим сделать. Или оперативно склеить трафик со старого на новый домен. Поэтому берем разворачиваем базовый ресурс сайта на любом вменяемом хостинге. Покупаем за 5 евро на Digital Ocean или На хетцнер клауд минимальную ноду, ставим туда NGINX как прокладку и так же запускаем на основной базовый ресурс, если вдруг получили блокировку, за 20 минут, развернули новый домен на новую клауд-ноду, подклеили на старой старый домен редиректом на новую и без потери трафика и позиций, работаем дальше!

Не могу сделать редирект ROUT'а rewrite ^/en/index.php?route=common/footer/getOctPolicy$ https://SITE.com/index.php?route=common/footer/getOctPolicy permanent; Т.е /en/index.php?route=common/footer/getOctPolicy на без(/en) https://SITE.com/index.php?route=common/footer/getOctPolicy Не работает у меня почему-то

Вот, болею на Новый год, время свободное есть, сервера ковыряю, свои записки сумасшедшего разбираю. Немного данных накопилось по настройке VPS на Nginx для Opencart, решил выложить. Пилить на какой-нибудь свой сайт статью - ЧСВ еще недостаточно развито, а в формате форума думаю самое то. Вдруг пригодится кому. Мануал не претендует на истину в последней инстанции, даже вообще ни в какой инстанции не претендует, просто я вот так делаю. Аргументированная критика и бросание тапками принимаются. Если модераторы решат прикрепить его где-нибудь в песочнице - буду неделю раздуваться от гордости. Написан подробно для совсем новичков. Кто не новичок - не читайте, будете зевать. Просто очередной 100500 мануал по настройке сервера. Ниже буду писать команды для копипасты и в спойлерах постараюсь аргументировать почему так, а не иначе. Итак, исходные данные. Имеем голый VPS. Без ISP-Manager и прочих панелей. Системой выберем Debian 8.2. Веб-сервер - Nginx. SAPI - php-fpm. PHP 7.3. Mariadb 10.4. Обязательный https, wildcard-сертификаты от LetsEncrypt. Немного паранойи в настройках тоже добавим, куда ж без нее. Сайт используемый в примере - традиционный mysite.ru. Пользователь debian - debuser. IP VPS - 123.123.123.123. Эти переменные буду выделять в конфигах вот так {mysite.ru) для их замены на свои значения. Установка ОС Все написанное ниже работает для любой версии Debian, которую вы выберите (на 10 сервер еще не поднимал, на 99% уверен что все будет работать, на 9 точно работает). Единственно, в /etc/apt/sources.list поменяйте jessie на имя выбранного дистрибутива - stretch или buster. Если же согласились с моими аргументами в спойлере выше и решили ставить Debian 8.2, то ищем у хостера предложенный к установке образ этой версии и раскатываем его на VPS. Если таковой не предлагается - просим поддержку подключить standard+nonfree образ с debian.org и ставимся с него. Установка стандартная, останавливаться на ней не буду. Образ, указанный по ссылке, про устанавливаемые компоненты спрашивать не будет, он просто ставит минимальный набор. Образ хостера, скорее всего спросит на этапе "Выбор программного обеспечения" - снимаем галки со всего, кроме "Server SSH". "Стандартные системные компоненты" включаем/выключаем по желанию. Чего ему потом будет не хватать подтянет сам по зависимостям или спросит. Если не уверены в себе, ну поставьте галку и на них тоже. Удаленное подключение по SSH. Из windows - используем putty, последнюю версию которой берем на официальном сайте. Во всяких окошках и полях заполняем что ей надо (IP VPS, порт ssh, имя пользователя и его пароль), сохраняем подключение и потом дважды по нему щелкая наблюдаем удаленный терминал. Счастливые обладатели linux на десктопе просто вводят ssh {IP_адрес_сервера} -l {имя_пользователя_Debain} GRUB, стандартные репозитории и серверные ключи ssh Все команды ниже выполняются от рута, поэтому su и поехали дальше по списку. Адепты sudo гуглят и выполняют "Установка и настройка sudo в Debian" и в дальнейшем перед всеми командами добавляют sudo. а) удаляем дефолтную пятисекундную задержку grub. На сервере она нам вообще ни к чему -> выигрываем пять секунд на каждом перезапуске nano /etc/default/grub Значение GRUB_TIMEOUT=5 меняем на GRUB_TIMEOUT=0 update-grub б) приводим в порядок список репозиториев Этот пункт - единственный, который будет отличаться для разных версий Debain. Для 8.2: > /etc/apt/sources.list nano /etc/apt/sources.list Вставляем: Обновляем: apt-get update Должен обновиться и выругаться на ключ AA8E81B4331F7F50 от неизвестного нового репозитория обновлений безопасности. Ставим этот ключ: apt-key adv --recv-keys --keyserver keyserver.ubuntu.com AA8E81B4331F7F50 Для stretch и buster: ничего не делаем в) немного обещанной паранойи (можно не делать, но лучше сделать) Если мы подключали образ, который не сами скачали, то неизестно, что в нем за ключи для ssh. Поэтому убьем их и поставим новые rm /etc/ssh/ssh_host_* apt-get install --reinstall libssh2-1:amd64 openssh-blacklist openssh-blacklist-extra openssh-client openssh-server ssh Для проверки ребутимся reboot и вновь коннектимся по ssh. Т.к. ключи поменяли, сервер сообщит, что "ECDSA key fingerprint.... " теперь какой-то другой и спросит подключаться/нет. Ответить "yes". Настройка SSH По умолчанию ssh слушает на 22 порту, доступ root - только по ключу (параметр without-password, см.ниже), доступ по паролю разрешен. Можно все так и оставить, тогда пропускаем этот пункт и идем к следующему. Можно поменять. Размышления на эту тему под спойлером. Открываем конфиг ssh nano /etc/ssh/sshd_config а) смена порта Выбираем какой-нибудь понравившийся свободный порт. Например, из отмеченных вот тут голубым цветом. Меняем в конфиге параметр на б) запрет доступа root'ом Меняем на в) запрет доступа по паролю (доступ только по ключу) Проверить, что параметр, разрешающий доступ по ключу не закомментирован и имеет значение yes (по умолчанию так и есть, но проверить не помешает, а то может быть грустно). Раскомментировать строку и поменять ее значение на г) если выставили доступ только по ключу, то перед перезапуском демона ssh (следующий пункт) обязательно создать ключ на локальной машине и проверить, что по нему пускает Г1. Если на локальной машине linux, то в терминале пользователя, из которого ходить будете ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa ssh-copy-id -i ~/.ssh/id_rsa.pub имя_удаленного_пользователя@IP_адрес_удаленной_машины ssh-add ~/.ssh/id_rsa Г2. Для пользователей Windows - используем утилиту puttygen, которая установилась вместе с putty (см.выше). Пользоваться ей несложно, она графическая. Например, вот первый попавшийся мануал. д) для применения сделанных изменений рестартуем демона ssh service sshd restart e) ставим fail2ban Небольшая, но весьма полезная утилита, которая после нескольких попыток неправильного ввода пароля ssh отправляет IP, с которого осуществлялся доступ, в бан. apt-get install fail2ban Работает из коробки. По умолчанию для ssh настроена на защиту 22 порта. Если порт поменяли, идем в конфиг nano /etc/fail2ban/jail.conf и в секции [ssh] меняем значение на Рестартуем для применения изменений service fail2ban restart В рамках этого поста про fail2ban ограничусь, но она умеет еще много чего, крайне рекомендую погуглить "Настройка fail2ban" Настройка FTP Из двух самых распространенных ftp-серверов proftpd и vsftpd, лично я предпочитаю proftpd. Про него и напишу. apt-get install proftpd На вопрос установить как сервис или запускать через inetd - выбирайте inetd (если к вам на сервер не будут толпы посетителей по ftp ходить) Представляется, что типовым ftp-пользователем у вас на сайте будет техподдержка модулей. Все что им надо - гонять туда-сюда файлы в определенной директории определенного сайта. И поэтому по ssh им на сервере делать нечего. Для этого добавляем в список shell'ов /bin/false, который не дает пользователю ни по ssh войти, ни bash'eм пользоваться. echo "/bin/false" >> /etc/shells При создании пользователя ему нужно будет определить домашнюю директорию, в которой запереть. Поэтому, забегая вперед: сайты у нас будут лежать в /var/www, nginx работать от имени пользователя www-data, которому, соответственно, нужны полные права на /var/www. Т.е, mysite.ru будет лежать в /var/www/mysite.ru. Доступ будем давать пользователю support-mysite, который должен ходить только в нее и никуда больше на сервере. Создаем /var/www/mysite.ru (вместо mysite.ru укажите свою директорию сайта) mkdir -p /var/www/{mysite.ru} Создаем пользователя support-mysite (укажите своего) с домашней директорией /var/www/mysite.ru (укажите свою) и шеллом /bin/false adduser --home /var/www/{mysite.ru} --shell /bin/false {support-mysite} Должно ругнуться, что пользователь не имеет прав на свою домашнюю директорию (мы ж ее рутом создавали), не обращайте внимания, соглашайтесь создать все равно. Создаем пользователю support-mysite (укажите своего) пароль passwd {support-mysite} Присваиваем /var/www и всему что в нее входит владельца/группу www-data:www-data с правами на файлы 664 и директории 775 chown -R www-data:www-data /var/www && find /var/www -type f -exec chmod 664 {} \; && find /var/www -type d -exec chmod 775 {} \; Подробнее про права: Добавляем пользователю support-mysite (укажите своего) группу www-data usermod -a -G www-data {support-mysite} Редактируем конфиг proftpd nano /etc/proftpd/proftpd.conf а) меняем имя сервера (не принципиально, при подключении будет рапортовать вы туда-то подключились юзерам) на б) запираем пользователей в их домашних директориях находим и раскомментируем в) меняем порт (см. соображения выше про порт для ssh на г) разрешаем пассивный режим находим и раскомментируем д) описываем доступ support-mysite (укажите своего) к директории /var/www/mysite.ru (укажите свою). Для этого, в конец конфига добавляем блок Сохраняем конфиг и перезапускаем proftpd service proftpd restart Если вдруг когда-нибудь возникнет необходимость предоставить этому пользователю ssh-доступ, идем в /etc/passwd (nano /etc/passwd) и меняем ему там /bin/false на /bin/bash. Там же можно сменить и домашнюю директорию. Аналогично вышеописанному создаем сколько нужно ftp-пользователей на сколько нужно сайтов. При этом помним, что если им дать ssh-доступ, то они смогут ходить по всему серверу (кроме директории /root), править файлы не только своего сайта, а всех, которые лежат в /var/www (т.к. входят в группу www-data). При /bin/false - дальше присвоенной домашней директории не уйдут. Настройка firewall Файрвол будем использовать типовой - основанный на iptables, разрешающий все исходящие соединения и запрещающиий все входящие кроме специально разрешенных. Проверяем что установлены iptables последней версии apt-get install iptables Создаем файл правил nano /etc/firewall.sh Спрячу его под спойлер, а то и так уже поэму написал Делаем его выполнимым chmod +x /etc/firewall.sh Добавляем в /etc/network/interfaces загрузку правил при ребуте (вставить выделенное жирным после iface lo inet loopback nano /etc/network/interfaces Применяем правила sh /etc/firewall.sh и сохраняем текущее состояние в файл, который будем загружать iptables-save > /etc/ip_rulles.lst Логика обращения с файрволом несложная - в конце меняем или создаем по аналогии новые порты, которые должны быть открыты, применяем новые правила и сохраняем их в файл. Если надо его совсем отключить - комментируем три выделенных строки в /etc/network/interfaces и перезагружаемся. Если надо включить - раскомментируем и перезагружаемся. Установка nginx, php и mariadb Ставим пакеты для работы с https-репозиториями. Ну и заодно некоторые утилиты, чтобы лишних команд потом не писать: apt-get install lsb-release apt-transport-https ca-certificates software-properties-common curl gnupg2 mc unar haveged Ставим ключи для репозиториев cd /tmp wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db curl -fsSL https://nginx.org/keys/nginx_signing.key | apt-key add - Добавляем репозитории в sources.list nano /etc/apt/sources.list Добавить в конец файла (не забываем менять jessie на stretch или buster при необходимости): Обновляемся, апгрейдимся и ребутимся (на всякий случай, слишком много пакетов он из новых репозиториев тащит, а также обновляет initramfs, создавая новый /boot/initrd.img) apt-get update && apt-get upgrade reboot Вновь коннектимся по ssh. Ставим пакеты apt-get install mariadb-server nginx php7.3-fpm php7.3-curl php7.3-mbstring php7.3-mysql php7.3-xml php7.3-gd php7.3-zip php7.3-bcmath php7.3-imagick Примечание: если нужно PHP 7.2 или 7.1, меняем цифры в команде выше Донастройка php а) ставим ioncube скачиваем и разъархивируем тарбол с последними ioncube'ами cd /tmp wget http://downloads3.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz tar xfz ioncube_loaders_lin_x86-64.tar.gz cd ioncube Проверяем установленную версию php php -v Смотрим в какой папке лежат расширения php php -i | grep extension_dir Копируем нужный ioncube_loader в данную папку (команда с путями приведена для PHP 7.3. Как есть, так и копируем. Для PHP 7.2 и 7.1 - измените индекс в команде и вставьте путь, который показала предыдущая команда) cp ioncube_loader_lin_7.3.so /usr/lib/php/20180731 Открываем php.ini nano /etc/php/7.3/fpm/php.ini Ну или nano /etc/php/7.2/fpm/php.ini, nano /etc/php/7.1/fpm/php.ini - соответственно Находим первый "zend_extension = ...." и перед ним вставляем Для PHP 7.2 и 7.1 измените индекс и папку так, как указано выше. Повторить вставку той же строки для CLI (nano /etc/php/7.3/cli/php.ini, nano /etc/php/7.2/cli/php.ini, nano /etc/php/7.1/cli/php.ini) Перезапускаем службу service php7.3-fpm restart (service php7.2-fpm restart, service php7.1-fpm restart) б) ставим mcrypt Начиная с PHP 7.2 модуль mcrypt исключен из репозитория. Однако для Opencart 2 он нужен (а для 3 - нет, если не будете двойку использовать, то и не ставьте его, уж больно много он мусора для своей сборки тянет) Для PHP 7.3 и 7.2 ставим его через pecl apt-get install gcc make autoconf libc-dev pkg-config apt-get install php7.3-dev apt-get install libmcrypt-dev pecl install mcrypt-1.0.3 Для PHP 7.2 во второй команде указываем php7.2-dev соответственно. Создаем ini-файл модуля nano /etc/php/7.3/mods-available/mcrypt.ini Для PHP 7.2 - nano /etc/php/7.2/mods-available/mcrypt.ini Вставляем Включаем вновь созданный модуль phpenmod mcrypt Перезапускаем службу service php7.3-fpm restart (service php7.2-fpm restart) Проверка: php -m | grep mcrypt Результат должен быть в) правим php.ini nano /etc/php/7.3/fpm/php.ini Ну или nano /etc/php/7.2/fpm/php.ini, nano /etc/php/7.1/fpm/php.ini - соответственно Находим и меняем значения Перезапускаем службу service php7.3-fpm restart (service php7.2-fpm restart, service php7.2-fpm restart) Донастройка maraidb а) скрипт настройки безопасности Запускаем mysql_secure_installation Ответы с описанием под спойлером б) скрипт захода в mysql из рута без пароля Сильно пригодится, когда много баз вручную дампить придется. Да и вообще - считаю нужный скрипт. Создаем скрипт nano /root/.my.cnf Вставляем Ставим на него права и владельца chown root:root /root/.my.cnf; chmod 600 /root/.my.cnf Перезапускаем службу service mysql restart Настройка nginx а) правим конфиг В стандартном конфиге нужно поменять пользователя на www-data, включить сжатие, установить количество worker_processes равное количеству процессоров VPS, worker_connections (это значение, умноженное на worker_processes даст максимально возможное количество одновременных пользователей), по аналогии с apache - указать брать конфиги сайтов из /etc/nginx/sites-enabled/. Чтобы не морочиться даю готовый конфиг, в нем надо поменять только значения worker_processes и worker_connections (выделено жирным) Сохраняем старый конфиг cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak Очищаем > /etc/nginx/nginx.conf Открываем nano /etc/nginx/nginx.conf Вставляем б) создаем директории для хранения конфигов сайтов mkdir /etc/nginx/sites-available ; mkdir /etc/nginx/sites-enabled в) создаем шаблон параметров работы с PHP-fpm Чтобы не указывать в конфиге каждого сайта одни и теже параметры для работы с PHP-fpm, создаем шаблон, который будем инклюдить в каждый конфиг Создаем директорию для хранения шаблонов mkdir /etc/nginx/templates Создаем сам шаблон nano /etc/nginx/templates/php-fpm.conf Вставляем (обратите внимание на версию PHP - выделено жирным, для 7.2 и 7.1 - соответственно поменять) Letsencrypt-сертификаты От писания данного талмуда целый день уже голова пухнет и не могу припомнить почему я отказался от установки certbot на сам сервер и обновления сертификатов по расписанию cron'ом. Смутно припоминаю, что вроде как в Jessie он не входит в стандартный репозиторий, а собираемый из исходников имеет какие-то проблемы с зависимостями (в stretch работает). Но не суть важно. В общем, сертификаты я получаю на локальной машине и кладу их в /root/.certrs. С учетом того, что LetsEncrypt сейчас раздает wildcard сертификаты на три месяца, раз в три месяца проделать эту процедуру не считаю сложным вообще, во всяком случае на десяток имеющихся сайтов. Тем более, что за две-три недели до истечения срока они на почту задолбут, что сертификаты заканчиваются, захочешь пропустить - не пропустишь. Про запуск certbot на Windows - гуглите. Про запуск certbot на локальном linux начиная со stretch. apt-get install certbot запрос сертификата (от рута) certbot certonly --agree-tos -d mysite.ru -d *.mysite.ru --preferred-challenges dns --manual --server https://acme-v02.api.letsencrypt.org/directory mysite.ru меняем на свой домен. В одном запросе можно получить хоть сколько сертификатов (не помню максимум, но много), перечислив домены после ключа -d. Но т.к. он будет последовательно давать DNS-записи, которые нужно внести, то желательно: один запрос - один домен (в смысле пара mysite.ru и *.mysite.ru - для wildcard сертификата). Скрипт спросит о внесении вашего IP в базу Ответить Y Потом выдаст значение первой TXT-записи DNS _acme-challenge.mysite.ru, (например, такой YimPRyMcm8rEzxYCrsgK80hVKgk0YpJGazuZ_pcFlIg), которую надо вручную добавить на ваш NS-сервер и будет ждать нажатия Enter для продолжения. Вносим запись, жмем Enter. Появится вторая запись. Ее вносим, но Enter не жмем, а ждем минут 30 пока записи ДНС применятся. У меня обычно минут 15-20 применяются, мы же не А-записи меняем, так что тут все быстро. Подождали, нажали Enter, Letsencrypt опросил DNS-сервер и если записи нашел, то пишет поздравительную петицию на полэкрана и сохраняет в /etc/letsencrypt/archive/mysite.ru четыре файла: cert1.pem, chain1.pem, fullchain1.pem, privkey1.pem. Убираем из названий цифру 1 и получившиеся файлы передаем на сервер (я, например, sshfs пользуюсь для передачи файлов, кому-то удобнее ftp - про его настройку выше писалось). На сервере: Создаем директорию для хранения сертификатов mkdir /root/.certs В ней директории для сайтов mkdir /root/.certs/mysite.ru mkdir /root/.certs/mysite2.ru mkdir /root/.certs/mysite3.ru Копируем в соответсвующую директорию полученные сертификаты. Также, создаем в нужной директории ключ, использующий алгоритм Диффи Хельмана openssl dhparam -out /root/.certs/mysite.ru/dh.pem 2048 Запускаем сайт Ну и наконец заключительная часть а) создаем непосредственно конфиг сайта для mysite.ru для Opencart. Включает в себя редиректы с www на без_www, а также с http на https. Корректно работает с ЧПУ. У себя ошибок пока не наблюдал, все сборки и все модули работают. Раньше использовал одинаковые конфиги и для Opencart 2 и для Opencart 3. Сейчас нашел для себя удобным для тройки в /var/www также как и для двойки создавать директорию mysite.ru, но уже в ней поддиректорию shop, куда класть саму сборку. В результате когда storage выносится на уровень вверх он оказывается не в общей свалке всех остальных доменов, а в /var/www/mysite.ru. Туда же направляю error и access логи nginx. Все получается в одном месте. Поэтому для тройки дам немного в этой части модернизированный. В остальном конфиги идентичны. Opencart 2 Opencart 3 Бонусом - если вдруг кому надо будет рабочий конфиг для wordpress б) создаем ссылку в sites-enabled ln -s /etc/nginx/sites-available/mysite.ru /etc/nginx/sites-enabled в) создаем директорию для хранения файлов сайта для Opencart 2 mkdir /var/www/mysite.ru для Opencart 3 mkdir -p /var/www/mysite.ru/shop г) перезапускаем службу service nginx restart д) после копирования файлов в директорию сайта, не забываем обновлять права и владельца (см.выше про proftpd) если используем доступ по ftp кого-то, кому нужна запись в каталоги chown -R www-data:www-data /var/www && find /var/www -type f -exec chmod 664 {} \; && find /var/www -type d -exec chmod 775 {} \; если без ftp или ftp только посмотреть chown -R www-data:www-data /var/www && find /var/www -type f -exec chmod 644 {} \; && find /var/www -type d -exec chmod 755 {} \; ВСЕ, БЛИН, ЗАКОНЧИЛ! В таком виде оно заработает. Ну а дальше веселуха по тонкой настройке mariadb и пр. и пр. Если кому-то будет полезно, буду рад.

Поставил OcStore 2.3 на Nginx. Конфиги: Nginx.conf Для сайта: Ставлю чистый OcStore 2.3 После установки появилась проблема. Не могу зайти в админку! Пишу правильные данные. И на сайте не могу переключить язык. Какая то хрень блокирует отправку или получение Post запроса. Либо что еще. Firewall отключал. OcStore 3 работает без проблем. В php-fpm, nginx ошибок нет Когда пытаюсь восстановить пароль от админки пишет maillog postfix/sendmail[3637]: fatal: parameter inet_interfaces: no local interface found for ::1 Куда копать? Ос Oracle 7.6, NGINX 1.17.1(Не стабильная)

Добрый день! Есть проблема. На vps установлена связка apache(бэк)+nginx(фронт). Никак не могу разобраться с настройкой сервера. Почему-то не работает стандартный tool/image/resize, некоторые php запросы. прошу тех, кому не все равно - приведите пример httpd.conf и nginx.conf. Было бы шикарно, если бы еще и список установленных модов apache привели. Прошу просто скинуть пример, думаю с переработкой под свой сайт я справлюсь. Спасибо огромное.

Приветствую!Вот эти записи:220.72.145.24 - - [25/Oct/2017:19:18:18 +0300] "GET / HTTP/1.1" 301 186 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:18 +0300] "\x00" 400 174 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:19 +0300] "POST /command.php HTTP/1.1" 301 186 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:19 +0300] "\x00" 400 174 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:19 +0300] "GET /system.ini?loginuse&loginpas HTTP/1.1" 301 186 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:20 +0300] "\x00" 400 174 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:20 +0300] "GET /upgrade_handle.php?cmd=writeuploaddir&uploaddir=%27;echo+nuuo+123456;%27 HTTP/1.1" 301 186 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:20 +0300] "\x00" 400 174 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:21 +0300] "GET /board.cgi?cmd=cat%20/etc/passwd HTTP/1.1" 301 186 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:21 +0300] "\x00" 400 174 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:22 +0300] "POST /hedwig.cgi HTTP/1.1" 301 186 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:22 +0300] "\x00" 400 174 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:23 +0300] "POST /apply.cgi HTTP/1.1" 301 186 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:23 +0300] "submit_button=Diagnostics&change_action=gozila_cgi&submit_type=start_ping&action=&commit=0&nowait=1&ping_ip=%3b%20AAA** *BBB|||%20%3b&ping_size=&ping_times=5&traceroute_ip=\x00" 400 174 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:23 +0300] "GET /setup.cgi?next_file=netgear.cfg&todo=syscmd&curpath=/&currentsetting.htm=1&cmd=echo+dgn+123456 HTTP/1.1" 301 186 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:24 +0300] "\x00" 400 174 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:24 +0300] "GET /cgi-bin/user/Config.cgi?.cab&action=get&category=Account.* HTTP/1.1" 301 186 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:25 +0300] "\x00" 400 174 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:25 +0300] "GET /shell?echo+jaws+123456;cat+/proc/cpuinfo HTTP/1.1" 301 186 "-" "-" "-"220.72.145.24 - - [25/Oct/2017:19:18:25 +0300] "\x00" 400 174 "-" "-" "-"После этих записей нагрузка CPU стала быстро расти до 100% и сайт висит!Что это такое?

"Подниму" выделенный сервер VPS или VDS на Freebsd 10.1 в связке Nginx + php5-fpm + Mysql для Opencart - под ключь. Все все все ... примерно 10 - 15 тыс (....в зависомости от потребностей). установка и настройки самого сервера, настройки безопасности (без паранойи), установка и настройки Nginx + php5-fpm + Mysql настройки безопасности Nginx, php5-fpm (опять же без паранойи) установка и настройки Вашего Opencart (в смысле с нуля или перенос уже рабочего магазина(ов)) пропись конфигов Nginx под SEO и особенности Вашего магазина все это тестирую. :) ну и что нибудь еще (что то типа синхронизации с 1С), но только техническая часть, не занимаюсь писаниями текстов и дезайном.... Также предлагаю дальнейшее сотрудничество по поддержке сервера (мониторинг нагруженности, бекапы и т.д.) по договоренности.

Добрый день Возможно, кто-то сталкивался с такой ситуацией. Есть виртуальный (shared) хостинг. На хостинге установлен Nginx (для кэширования статики) + есть пара сайтов на Opencart/OcStore. Некоторые используют Nginx, некоторые не используют... Apache тоже присутствует. Вопрос. Можно ли в Nginx изменять настройки для каждого отдельного сайта? По аналогии с апачевским .htaccess. Цель: Возможность вкл/выкл Nginx, менять настройки Nginx для каждого отдельного сайта.

Дано загорелся темой отказа от апача. Поднял для своих проектов сервер NGINX+MariaBD+php5-fpm. Получил с помощью гугла и манов хороший конфиг с безопасностью, ЧПУ и много кеширования =). Выкладываю в общее пользование и возможное улучшение. Gist - https://gist.github.com/xXxSPYxXx/8908402 server{ listen 80; listen 443 ssl; server_name site.ru www.site.ru; ssl on; if ( $scheme = "http" ) { rewrite ^/(.*)$ https://$host/$1 permanent; } index index.php index.html; access_log /var/log/nginx/site.ru.access.log; error_log /var/log/nginx/site.ru.error.log; root /var/www/site.ru; keepalive_timeout 60; ssl_certificate /etc/nginx/ssl/ssl-unified.crt; ssl_certificate_key /etc/nginx/ssl/site.ru.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"; add_header Strict-Transport-Security 'max-age=604800'; location ~ \.php$ { try_files $uri = 404; include fastcgi_params; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param HTTPS on; } location /image/data { autoindex on; } location /upload { autoindex on; allow all; log_not_found off; } location /admin { index index.php; } location / { try_files $uri @opencart; } location @opencart { rewrite ^/(.+)$ /index.php?_route_=$1 last; } location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } location ~* \.(xml|csv|xls)$ { allow all; log_not_found off; } # Make sure files with the following extensions do not get loaded by nginx because nginx would display the source code, and these files can contain PASSWORDS! location ~* \.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)$|^(\..*|Entries.*|Repository|Root|Tag|Template)$|\.php_ { deny all; } # Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac). location ~ /\. { deny all; access_log off; log_not_found off; } location ~* \.(jpg|jpeg|png|gif|css|js|ico)$ { expires max; log_not_found off; } }

Уважаемые Форумчане, НЕОБХОДИМО ВАШЕ МНЕНИЕ!!! Столкнулся со следующей дилеммой! Решил перейти на новый хостинг (сейчас у меня 5 дней бесплатного тестирования). Так вот, произвёл все настройки и решил проверить скорость работы сайта через Google Page Speed. Однако, получил полное разочарование, если раньше рейтинг был в пределах 72 единиц, то после перехода рейтинг скорости упал до 40 ед. В рекомендациях Google появилось новое сообщение: Leverage Browser Caching - т.е. не происходит кеширование страниц со стороны сервера. Обратился в службу поддерки, где мне дали ответ, что у них сервера используют связку nginx+apache, при которой нет необходимости кешировать страницы, т.к. они и так быстро открываются и это более эффективная схема, чем кеширование страниц. Следует ли в этом случае игнорировать показатели Google Page Speed? Ведь этот рейтинг скорости в той или иной степени влияет на позиции сайта в поисковой выдаче! Очень интересо Ваше мнение по этому вопросу!!!