Подготовка VPS на Debian, Nginx+php-fpm, PHP 7.3, mariadb для Opencart 2/3

Neuro75 · 6 січня 2020

Вот, болею на Новый год, время свободное есть, сервера ковыряю, свои записки сумасшедшего разбираю. Немного данных накопилось по настройке 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? Полагаю, что серьезно можно рассматривать две серверных оси - Debian и CentOS. Каждый использует к чему привык, я привык к Debian.

Почему 8.2? Можно долго спорить про "чем старше версия ядра, тем она тяжелее", про "свежий софт в дистрибутивах" и пр. Я использую 8.2, т.к. интереса ради ставил подряд разные версии Debian и CentOS (и разные ядра, соответственно) и гонял их на синтетических тестах (unixbench, в основном). Ядро от 8.2 существенно всех победило (и CentOS, попрошу заметить, в том числе). В основном - за счет очень быстрой работы с винтом. Почему оно так, я не знаю. Косвенно эти результаты подтверждаются тем, что у хостеров, предлагающих на выбор ОС для VPS, Jessie представлен именно версией 8.2. Ну и читал где-то когда-то что это ядро быстрое. Пруфы лень искать. А я на ресурсы, которых на VPS всегда мало, очень жадный.

Почему чистый Nginx без Apache? Держать Apache только ради mod-rewrite - непозволительная роскошь (см.выше про жадность).

Почему PHP-fpm. Быстрый потому что.

Почему PHP 7.3 и mariadb 10.4 - потому что 2020 год все-таки наступил. Кроме того, у меня на VPS не только на OpenCart сайты крутятся, а другие CMS не разделяют мнение "OpenCart все равно практически не использует возможностей свежих версий PHP, поэтому ставьте 5.6 и не парьтесь) Note: Opencart.pro работать не будет, т.к. ему нужен ioncube 5.6 и перекодировать его на более свежий не хотят (глубоко вздохнул о своих нескольких ранее использовавшихся oc.pro, нравилось с этой версией работать, но что делать - время идет). Также не будут работать и модули, которые закодировны ioncube 5.6 и на новые версии PHP не перекодированы. Но я таких в последнее время что-то уже и не встречаю.

А, и еще - почему без ISP-Manager? Штука безусловно удобная. Для быстрого разворачивания сервера, создания сайтов и управления ими. У кого стоит - тому этот мануал в принципе не нужен, через панель все сделает. Долгое время считал ее у себя незаменимой. Обленился, руками конфиги править отвык. Но: а) я один пользователь своего VPS, мне многопользовательский разделенный доступ не нужен; б) все что умеет панель умею делать руками, для создания и администрирования нескольких сайтов на opencart ниженаписанного также достаточно; в) не так уж и часто что-то глобальное на сервере конфигурируется, один раз время потратил и забыл; г) тонкая настройка, есть тонкая настройка, тоньше чем руками не настроишь; д) мало у каких хостеров панель прилагается к тарифу бесплатно, а где прилагается - ну значит уже включена в стоимость тарифа; е) см. выше про жадность на ресурсы; не уверен, что она их жрет, скорее всего - активно нет, но что-то наверняка поджирает.

Установка ОС

Все написанное ниже работает для любой версии 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

Спойлер

С весны 2019 обновления безопасности jessie переехали в новый репозиторий, о чем образ 8.2 не знает, кроме того, jessie первой строкой sources.list ставит CD-ROM. Поэтому первой командой полностью чистим sources.list, после второй - добавляем ему новое содержимое (для стандартных репозиториев я использую зеркала из Германии, когда-то они по тестам были самые быстрые, сейчас не знаю):

Вставляем:

Цитата

deb http://ftp.de.debian.org/debian/ jessie main
deb-src http://ftp.de.debian.org/debian/ jessie main

deb http://security.debian.org/debian-security jessie/updates main

Обновляем:

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, см.ниже), доступ по паролю разрешен.

Можно все так и оставить, тогда пропускаем этот пункт и идем к следующему.

Можно поменять. Размышления на эту тему под спойлером.

Спойлер

Если захотят поломать именно вас, то вас поломают.

Вместе с тем, несметные полчаща ботов шарятся по сети и тупо щупают стандартные порты у всех подряд. А найдя их пробуют простенький брутфорс из области повезет/не повезет. Как минимум логи забивают горами мусора от этой деятельности. Ну а могут и сломать. Аргумент за смену стандартного порта на что-либо другое. Ну и за использование fail2ban само-собой.

По-поводу доступа рута только по ключу. Полагаю, что нечего вообще руту по ssh на сервер лезть. Лезьте пользователем, а потом su и вперед.

Ну а лучше всего, конечно, доступ по паролю запретить и ходить по ключу. Так точно не поломают. Но если придется поддержке какого-нибудь модуля давать ssh-доступ (и такое бывает) то надо будет это в конфиге включать/отключать. Я так делаю.

Открываем конфиг ssh

nano /etc/ssh/sshd_config

а) смена порта

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

Меняем в конфиге параметр

Цитата

Port 21

на

Цитата

Port ваш_номер_порта

б) запрет доступа root'ом

Меняем

Цитата

PermitRootLogin without-password

на

Цитата

PermitRootLogin no

в) запрет доступа по паролю (доступ только по ключу)

Проверить, что параметр, разрешающий доступ по ключу

Цитата

PubkeyAuthentication yes

не закомментирован и имеет значение yes (по умолчанию так и есть, но проверить не помешает, а то может быть грустно).

Раскомментировать строку

Цитата

#PasswordAuthentication yes

и поменять ее значение на

Цитата

PasswordAuthentication no

г) если выставили доступ только по ключу, то перед перезапуском демона 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

Спойлер

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

Вторая - передаст ключ на сервер для указанного пользователя по указанному IP. При выполнении спросит пароль данного пользователя на сервере.

Вместо IP можно указывать доменное имя. Т.е. корректно и

ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

и

ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

Заходить в дальнейшем придется так, как тут выбрали, т.е. либо ssh 123.123.123.123, либо ssh mysite.ru. Также, если выбрали mysite.ru, то нужно чтобы его А-запись указывала на IP сервера. В целом проще выбрать IP и не париться.

Также вторая команда имеет ключ -p, указывающий на номер порта ssh. Если порт стандартный (22) ее можно опустить. Если ранее вы изменили порт, то команду надо использовать в виде:

ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected] -p номер_порта

Если изменили порт по мануалу, т.е. только что и демона еще не перезапускали, порт все еще 22, ключ -р опускаем.

Третья команда добавит информацию о назначении ключа в 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]

меняем значение

Цитата

port = ssh

на

Цитата

port = номер_порта

Рестартуем для применения изменений

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 {} \;

Подробнее про права:

Спойлер

www-data:www-data - понятно, от их имени работает nginx и ему нужен полный доступ к содержимому /var/www.

Традиционно права на файлы сайта ставят 644, директории - 755, т.е. владелец - полный доступ, остальные - только читать.

Но нам надо, чтобы техподдержка могла и писать. Поэтому пользователя техподдержки мы дополнительно загоним в группу www-data, а права на /var/www расширим так, чтобы и члены группы могли писать - т.е 664 и 775 соответственно.

Вообще же, традиционно команда выглядит так:

chown -R www-data:www-data /var/www && find /var/www -type f -exec chmod 644 {} \; && find /var/www -type d -exec chmod 755 {} \;

Можно комбинировать. Например, у нас несколько сайтов, ftp-доступ даем только к mysite10.ru, тогда

chown -R www-data:www-data /var/www && find /var/www -type f -exec chmod 644 {} \; && find /var/www -type d -exec chmod 755 {} \;

chown -R www-data:www-data /var/www/mysite10.ru && find /var/www/mysite10.ru -type f -exec chmod 664 {} \; && find /var/www/mysite10.ru -type d -exec chmod 775 {} \;

Ну и т.д., принцип понятен.

Добавляем пользователю support-mysite (укажите своего) группу www-data

usermod -a -G www-data {support-mysite}

Редактируем конфиг proftpd

nano /etc/proftpd/proftpd.conf

а) меняем имя сервера (не принципиально, при подключении будет рапортовать вы туда-то подключились юзерам)

Цитата

ServerName "Debian"

на

Цитата

ServerName "имя_вашего_сервера"

б) запираем пользователей в их домашних директориях

находим

Цитата

# DefaultRoot ~

и раскомментируем

Цитата

DefaultRoot ~

в) меняем порт (см. соображения выше про порт для ssh

Цитата

Port 21

на

Цитата

Port ваш_номер_порта

г) разрешаем пассивный режим

находим

Цитата

# PassivePorts 49152 65534

и раскомментируем

Цитата

PassivePorts 49152 65534

д) описываем доступ support-mysite (укажите своего) к директории /var/www/mysite.ru (укажите свою). Для этого, в конец конфига добавляем блок

Цитата

<Directory /var/www/{mysite.ru}>
Umask 022 022
AllowOverwrite off
     <Limit LOGIN>
        AllowUser {support-mysite}
        DenyALL
     </Limit>
     <Limit ALL>
        Order Allow,Deny
        AllowUser {support-mysite}
        Deny ALL
    </Limit>
    <Limit MKD STOR DELE XMKD RNRF RNTO RMD XRMD>
    AllowUser {support-mysite}
    Deny ALL
    </Limit>
</Directory>

Сохраняем конфиг и перезапускаем 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

Спрячу его под спойлер, а то и так уже поэму написал

Спойлер

#!/bin/bash
# Тут в принципе может и не надо этого всего, но не помеха вдруг какой модуль не подгружен или форвардинг не включен
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
modprobe iptable_nat
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp

# Объявление переменных
export IPT="iptables"

# Интерфейс который смотрит в интернет

# Помним, что в jessie внешний интерфейс обычно называется eth0 (как тут, выделено жирным), а в stretch и buster - по новому стантарту enps0 и пр. Проверяем в /etc/network/interfaces, если что - меняем выделенное
export WAN=eth0

# Очистка всех цепочек iptables
$IPT -F
$IPT -F -t nat
$IPT -F -t mangle
$IPT -X
$IPT -t nat -X
$IPT -t mangle -X

# Закрываем изначально ВСЁ (т.е. изначально все что не разрешено - запрещено):
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

# разрешаем локальный траффик для loopback и внутренней сети
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

# Состояние ESTABLISHED говорит о том, что это не первый пакет в соединении.
# Пропускать все уже инициированные соединения, а также дочерние от них
$IPT -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
# Пропускать новые, а так же уже инициированные и их дочерние соединения
$IPT -A OUTPUT -p all -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# Отбрасывать все пакеты, которые не могут быть идентифицированы и поэтому не могут иметь определенного статуса.
$IPT -A INPUT -m state --state INVALID -j DROP

# Приводит к связыванию системных ресурсов, так что реальный обмен данными становится не возможным.
$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
$IPT -A OUTPUT -p tcp ! --syn -m state --state NEW -j DROP

# Открытие портов извне:
# Открытие 443 порта (https)
$IPT -A INPUT -i $WAN -p tcp --dport 443 -j ACCEPT

# Открываем 80 порт (http)
$IPT -A INPUT -i $WAN -p tcp --dport 80 -j ACCEPT

# Открываем порт для ssh (если изменили номер порта в ssd_config - поменяйте тут на новый)
$IPT -A INPUT -i $WAN -p tcp --dport 22 -j ACCEPT

# Открываем 21 и служебные порты для proftpd (если изменили номер порта в proftpd.conf - поменяйте тут 21 на новый)
$IPT -A INPUT -i $WAN -p tcp --dport 20 -j ACCEPT
$IPT -A INPUT -i $WAN -p tcp --dport 21 -j ACCEPT
$IPT -A INPUT -i $WAN -p tcp --dport 49152:65534 -j ACCEPT

$IPT -L

Делаем его выполнимым

chmod +x /etc/firewall.sh

Добавляем в /etc/network/interfaces загрузку правил при ребуте (вставить выделенное жирным после iface lo inet loopback

nano /etc/network/interfaces

Цитата

# The loopback network interface
auto lo
iface lo inet loopback
   pre-up echo "1" > /proc/sys/net/ipv4/ip_forward # Включаем форвардинг пакетов
   pre-up iptables-restore < /etc/ip_rulles.lst     # Загружаем правила
   post-down iptables-save > /etc/ip_rulles.lst     # Сохраняем правила

Применяем правила

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

Спойлер

про начальные пакеты всем понятно, mc в комментарии также не нуждается,

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

haveged - решает проблему с энтропией на старте VPS. Из-за которой, в частности, иногда не запускается php-fpm после ребута.

Ставим ключи для репозиториев

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 при необходимости):

Цитата

deb http://mirror.23media.de/mariadb/repo/10.4/debian jessie main
deb https://packages.sury.org/php/ jessie main
deb http://nginx.org/packages/debian jessie nginx

Обновляемся, апгрейдимся и ребутимся (на всякий случай, слишком много пакетов он из новых репозиториев тащит, а также обновляет 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 = ...." и перед ним вставляем

Цитата

zend_extension = /usr/lib/php/20180731/ioncube_loader_lin_7.3.so

Для 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

Вставляем

Цитата

; configuration for php mcrypt module
; priority=20
extension=mcrypt.so

Включаем вновь созданный модуль

phpenmod mcrypt

Перезапускаем службу

 service php7.3-fpm restart

(service php7.2-fpm restart)

Проверка:

php -m | grep mcrypt

Результат должен быть

Цитата

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 - соответственно
Находим и меняем значения

Цитата

post_max_size = 20M
cgi.fix_pathinfo=0
upload_max_filesize = 20M

Перезапускаем службу

 service php7.3-fpm restart

(service php7.2-fpm restart, service php7.2-fpm restart)

Донастройка maraidb

а) скрипт настройки безопасности

Запускаем

mysql_secure_installation

Ответы с описанием под спойлером

Спойлер

Спрашивает текущий пароль mariadb'шного root'a:

Цитата

Enter current password for root (enter for none):

Т.к. мы ставили mariadb-server скопом со всякими-разными php-fpm, то в таком варианте пароль своего root'a он на этапе установки не спрашивал. Значит просто жмем Enter (пароль у нас сейчас пуст).

Спрашивает переключить ли сервер на работу через сокет? (да, надо переключить. Это и быстрее и трушнее. Ответ Y)

Цитата

Switch to unix_socket authentication [Y/n]

Спрашивает изменить ли текущий пароль mariadb'шного root'a? Отвечаем Y и придумываем головоломный пароль. Он нам понадобиться только 1 раз (см.ниже), так что с возможностью его запоминания сильно морочиться не надо.

Цитата

Change the root password? [Y/n]

Спрашивает удалить ли анонимных пользователей. Ответ, естественно, Y

Цитата

Remove anonymous users? [Y/n]

Отключить возможность удаленного входа root'ом (не с локальной машины). Y

Цитата

Disallow root login remotely? [Y/n]

Удалить ли дефолтную тренировочную базу test? Y

Цитата

Remove test database and access to it? [Y/n]

И последний вопрос, применить ли сделанные изменения привилегий? Y

Цитата

Reload privilege tables now? [Y/n]

Готово.

б) скрипт захода в mysql из рута без пароля

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

Создаем скрипт

nano /root/.my.cnf

Вставляем

Цитата

[mysql]
user = root
password = ваш_головоломный_придуманный_в_предыдущем_пункте_пароль

[mysqldump]
user = root
password = ваш_головоломный_придуманный_в_предыдущем_пункте_пароль

Ставим на него права и владельца

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

Вставляем

Спойлер

user www-data;
worker_processes 4;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
worker_connections 1024;
use epoll;
}

http {
include /etc/nginx/mime.types;
default_type application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

access_log /var/log/nginx/access.log main;

    client_header_timeout 30;
    client_body_timeout 30;
    reset_timedout_connection on;

client_max_body_size 32m;
client_body_buffer_size 128k;

sendfile on;
tcp_nopush on;

keepalive_timeout 30;

    gzip on;
    gzip_disable "msie6";
    gzip_proxied any;
    gzip_min_length 1024;
    gzip_comp_level 4;
    gzip_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript application/atom+xml application/rdf+xml;

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}

б) создаем директории для хранения конфигов сайтов

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 - соответственно поменять)

Спойлер

location ~ \.php$ {
   try_files $uri =404;
   fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;
   fastcgi_buffers 16 16k;
   fastcgi_buffer_size 32k;
   fastcgi_index index.php;
   include fastcgi_params;
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
# Указанный блок location будет обрабатывать все запросы к php-файлам, первая директива в нем проверяет
# наличие запрошенного файла, в противном случае отдавая ошибку 404. Вторая устанавливает параметры соединения
# с FastCGI-шлюзом, в нашем случае с PHP-FPM, соединение устанавливается через UNIX-сокет, как наиболее
# производительный способ соединения. Затем указывается индексный файл и подгружаются настройки Nginx для FastCGI.

location ~ /\.ht {
deny all;
}
# Несмотря на то, что Nginx не использует htaccess-файлы, они, вместе с файлами htpasswd могут находиться
# в директории сайта и будет правильно запретить доступ к ним в целях безопасности.

location ~* \.(gif|jpeg|jpg|txt|png|tif|tiff|ico|jng|bmp|doc|pdf|rtf|xls|ppt|rar|rpm|swf|zip|bin|exe|dll|deb|cur)$ {
expires 168h;
}
# Кэширование статического содержимого. Данная конструкция включает кэширование на стороне браузера, сообщая тому,
# что "срок годности" указанных файлов - 168 часов (1 неделя) и при последующих обращениях на сайт данные файлы
# следует брать из локального кэша. Можно самостоятельно добавить нужные расширения файлов.

location ~* \.(css|js)$ {
expires 180m;
}

# Кэширование скриптов и стилей. Для них установим срок кэширования в 3 часа, что позволит соблюсти баланс между
# скоростью применения возможных изменений в этих файлах и уменьшением количества запросов к сайту.

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 в базу

Цитата

Are you OK with your IP being logged?

Ответить 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

Спойлер

# Редирект с 80-го порта
server {
        listen 80;
        listen [::]:80;
        server_name mysite.ru www.mysite.ru;

        location / {
                return 301 https://mysite.ru$request_uri;
        }
}

# Редирект с www 443-го порта
server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name www.mysite.ru;

        ssl_certificate /root/.certs/mysite.ru/fullchain.pem;
        ssl_certificate_key /root/.certs/mysite.ru/privkey.pem;
        ssl_trusted_certificate /root/.certs/mysite.ru/chain.pem;

return 301 https://mysite.ru$request_uri;
}

# Основной блок
server {
   listen 443 ssl http2;
   listen [::]:443 ssl http2;
   server_name mysite.ru;

   ##### Начало блока ssl
   ssl_stapling on;
   ssl_stapling_verify on;
   resolver 8.8.8.8;

   ssl_protocols TLSv1.2;
   ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
   ssl_prefer_server_ciphers on;

# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

   ssl_session_timeout 1d;
   ssl_session_cache shared:SSL:50m;
   ssl_session_tickets on;

   ssl_certificate /root/.certs/mysite.ru/fullchain.pem;
   ssl_certificate_key /root/.certs/mysite.ru/privkey.pem;
   ssl_trusted_certificate /root/.certs/mysite.ru/chain.pem;

ssl_dhparam /root/.certs/mysite.ru/dh.pem;
##### Конец блока ssl

root /var/www/mysite.ru/;
index index.php index.html;

access_log /var/log/nginx/mysite-access.log;
error_log /var/log/nginx/mysite-error.log;

   location ~* (\.tpl|.twig|\.ini|\.log|(?<!robots)\.txt) {
       deny all;
   }

   location ~* \/\.git {
       deny all;
   }

   location ~* \/image.+(\.php) {
       deny all;
   }

   location = /sitemap.xml {
       rewrite ^(.*)$ /index.php?route=extension/feed/google_sitemap last;
   }

   location = /googlebase.xml {
       rewrite ^(.*)$ /index.php?route=extension/feed/google_base last;
   }

   location /system {
       rewrite ^/system/storage/(.*) /index.php?route=error/not_found last;
   }

   location = /favicon.ico {
       log_not_found off;
       access_log off;
   }

   location = /robots.txt {
       allow all;
       log_not_found off;
       access_log off;
   }

location /admin { index index.php; }

   location / {
       try_files $uri @opencart;
   }

   location @opencart {
       rewrite ^/(.+)$ /index.php?_route_=$1 last;
   }

include /etc/nginx/templates/php-fpm.conf;
}

Opencart 3

Спойлер

# Редирект с 80-го порта
server {
        listen 80;
        listen [::]:80;
        server_name mysite.ru www.mysite.ru;

        location / {
                return 301 https://mysite.ru$request_uri;
        }
}

# Редирект с www 443-го порта
server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name www.mysite.ru;

        ssl_certificate /root/.certs/mysite.ru/fullchain.pem;
        ssl_certificate_key /root/.certs/mysite.ru/privkey.pem;
        ssl_trusted_certificate /root/.certs/mysite.ru/chain.pem;

return 301 https://mysite.ru$request_uri;
}

# Основной блок
server {
   listen 443 ssl http2;
   listen [::]:443 ssl http2;
   server_name mysite.ru;

   ##### Начало блока ssl
   ssl_stapling on;
   ssl_stapling_verify on;
   resolver 8.8.8.8;

   ssl_protocols TLSv1.2;
   ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
   ssl_prefer_server_ciphers on;

# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

   ssl_session_timeout 1d;
   ssl_session_cache shared:SSL:50m;
   ssl_session_tickets on;

   ssl_certificate /root/.certs/mysite.ru/fullchain.pem;
   ssl_certificate_key /root/.certs/mysite.ru/privkey.pem;
   ssl_trusted_certificate /root/.certs/mysite.ru/chain.pem;

ssl_dhparam /root/.certs/mysite.ru/dh.pem;
##### Конец блока ssl

root /var/www/mysite.ru/shop;
index index.php index.html;

access_log /var/www/mysite.ru/mysite-access.log;
error_log /var/www/mysite.ru/mysite-error.log;

   location ~* (\.tpl|.twig|\.ini|\.log|(?<!robots)\.txt) {
       deny all;
   }

   location ~* \/\.git {
       deny all;
   }

   location ~* \/image.+(\.php) {
       deny all;
   }

   location = /sitemap.xml {
       rewrite ^(.*)$ /index.php?route=extension/feed/google_sitemap last;
   }

   location = /googlebase.xml {
       rewrite ^(.*)$ /index.php?route=extension/feed/google_base last;
   }

   location /system {
       rewrite ^/system/storage/(.*) /index.php?route=error/not_found last;
   }

   location = /favicon.ico {
       log_not_found off;
       access_log off;
   }

   location = /robots.txt {
       allow all;
       log_not_found off;
       access_log off;
   }

location /admin { index index.php; }

   location / {
       try_files $uri @opencart;
   }

   location @opencart {
       rewrite ^/(.+)$ /index.php?_route_=$1 last;
   }

include /etc/nginx/templates/php-fpm.conf;
}

Бонусом - если вдруг кому надо будет рабочий конфиг для wordpress

Спойлер

# Редирект с 80-го порта
server {
   listen 80;
   listen [::]:80;
   server_name mysite.ru www.mysite.ru;

   location / {
   return 301 https://mysite.ru$request_uri;
   }
}

# Редирект с www 443-го порта
server {
   listen 443 ssl http2;
   listen [::]:443 ssl http2;
   server_name www.mysite.ru;

   ssl_certificate /root/.certs/mysite.ru/fullchain.pem;
   ssl_certificate_key /root/.certs/mysite.ru/privkey.pem;
   ssl_trusted_certificate /root/.certs/mysite.ru/chain.pem;

ssl_dhparam /root/.certs/mysite.ru/dh.pem;

return 301 https://mysite.ru$request_uri;
}

# Основной блок.
server {
   listen 443 ssl http2;
   listen [::]:443 ssl http2;
   server_name mysite.ru;

   ##### Начало блока ssl
   ssl_stapling on;
   ssl_stapling_verify on;
   resolver 8.8.8.8;

   ssl_protocols TLSv1.2;
   ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
   ssl_prefer_server_ciphers on;

# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

   ssl_session_timeout 1d;
   ssl_session_cache shared:SSL:50m;
   ssl_session_tickets on;

   ssl_certificate /root/.certs/mysite.ru/fullchain.pem;
   ssl_certificate_key /root/.certs/mysite.ru/privkey.pem;
   ssl_trusted_certificate /root/.certs/mysite.ru/chain.pem;

ssl_dhparam /root/.certs/mysite.ru/dh.pem;
##### Конец блока ssl

root /var/www/mysite.ru/;
index index.php;

   add_header X-Frame-Options "SAMEORIGIN";
   add_header x-xss-protection "1; mode=block" always;
   add_header X-Content-Type-Options "nosniff" always;

access_log /var/log/nginx/mysite_access.log;
error_log /var/log/nginx/mysite_error.log;

        location / {
       try_files $uri $uri/ /index.php?$args;
       rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml$ "/index.php?xml_sitemap=params=$2" last;
       rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml\.gz$ "/index.php?xml_sitemap=params=$2;zip=true" last;
       rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html$ "/index.php?xml_sitemap=params=$2;html=true" last;
       rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html.gz$ "/index.php?xml_sitemap=params=$2;html=true;zip=true" last;
   }

include /etc/nginx/templates/php-fpm.conf;
}

б) создаем ссылку в 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 и пр. и пр.

Если кому-то будет полезно, буду рад.

Змінено 6 січня 2020 користувачем Neuro75

ocdev_pro · 6 січня 2020

на Deb 10 работает у меня пара серверов, аптайм 6 мес.
Deb10+apache2.4+php-fpm7.3+percona
lets-encrypt+acme.sh
ну и всякий сахар в iptables (netfilter),fail2ban,git итд
почта через yandex
все на http2 (для чего собственно и нужен php-fpm)

FTP можно не ставить, да и не желательно, можно по SFTP коннектить при нужде, а если только по ключу, то поднять гит по схеме( local-bitbicket(private)-server )) и обновлять проект через него.
mcrypt и вовсе не нужен, втыкните в opencart 2 файл encryption.php из тройки и все.

Shureg · 7 січня 2020

Первое, что нужно сделать новичку (или просто не мазохисту) - поставить панель вроде весты. Возможно, файловый менеджер (это по настроению и потребностям. чаще фтп хватает).
И не надо про скилл, обезьянье копирование команд скилл не пвышает. Или уж будьте последовательны, тогда и OC собирайте вручную, а не скриптом :-D .
Вообще, под любой панелью большую часть этих команд все равно придется через консоль гнать, так что для варианта "установить и забыть" можно и без панели, на скорую руку.
Но если есть намерение поковыряться, то почему бы не создать себе комфортное окружение.
PS: Для адептов "голой строки" - FTP-клиентами тоже никогда не пользуетесь, строго консольными командами качаете?
PPS: Это не критика темы или ТС. Наоборот, одобряю, что все собрано в одном месте. Просто альтернативный вариант отметил.

Змінено 7 січня 2020 користувачем Shureg

i3bepb · 7 січня 2020

Не осилил прочитать, много букв...

Shureg · 7 січня 2020

23 минуты назад, nikifalex сказал:
все круто, только не увидел в nginx конфиге аналог
RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]

Так-то на форуме уже были примеры

  # SEO URL Settings
  location / {
    # This try_files directive is used to enable SEO-friendly URLs for OpenCart
    try_files $uri $uri/ @opencart;
  }

  location @opencart {
    rewrite ^/(.+)$ /index.php?_route_=$1 last;
  }
  # End SEO settings

Змінено 7 січня 2020 користувачем Shureg

Neuro75 · 7 січня 2020

1 час назад, nikifalex сказал:
все круто, только не увидел в nginx конфиге аналог
RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]

3-8 строка с конца, нет?

10 часов назад, Waha сказал:

все на http2 (для чего собственно и нужен php-fpm)

Ага...

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;

10 часов назад, Waha сказал:

FTP можно не ставить, да и не желательно, можно по SFTP коннектить при нужде, а если только по ключу, то поднять гит по схеме( local-bitbicket(private)-server )) и обновлять проект через него.

Дико поддерживаю. И не ставил никогда, пока не наткнулся на особо упоротых забугорных разработчиков. Я им на пальцах и по слогам "руссо туристо, кнопочка тык-тык - работать нет". А они мне ftp давай и хоть убейся. Пришлось ставить. Хотел в конце дописать, что ftp - зло, держать надо на всякий подобный случай, в файрволе строки закомментировать и давать доступ на чуть-чуть и по великим праздникам. Но к концу писанины уже глаза вылазили.

10 часов назад, Waha сказал:

mcrypt и вовсе не нужен, втыкните в opencart 2 файл encryption.php из тройки и все.

О как. За это яро плюсую, пошел пробовать.

3 часа назад, Shureg сказал:

PS: Для адептов "голой строки" - FTP-клиентами тоже никогда не пользуетесь, строго консольными командами качаете?

А зачем они нужны, если можно sshfs кусок сервера к локалке прикрутить? :-)

stickpro · 7 січня 2020

чтобы не писать простыню из 500 команд, и не заниматься рутиной есть такая вещь как докер советую освоить один раз, упростит жизнь, а для ленивых есть docker-compose

p.s лучше создать пользователя, а не производить все манипуляции под рутом, и по ssh лучше конектится по ключам, так надежнее это раз и быстрее, и отключить коннект к ssh по логину пассу

Neuro75 · 7 січня 2020

8 минут назад, stickpro сказал:

чтобы не писать простыню из 500 команд, и не заниматься рутиной есть такая вещь как докер советую освоить один раз, упростит жизнь, а для ленивых есть docker-compose

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

13 часов назад, Neuro75 сказал:

я на ресурсы, которых на VPS всегда мало, очень жадный

А так то да, много хороших и разных штук есть. У нас же памяти и процессора на сервере хоть ж..ой жуй!

stickpro · 7 січня 2020

3 минуты назад, Neuro75 сказал:

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

А так то да, много хороших и разных штук есть. У нас же памяти и процессора на сервере хоть ж..ой жуй!

это экономия на спичках, сейчас vps 4 ядра 8гб стоит 5 евро, куда дешевле

Neuro75 · 7 січня 2020

У меня 4х3100\16Гб. И все равно жаба.

Да и вообще, когда станет совсем лениво "простыню из 500 команд" писать, я скрипт напишу, который их писать будет. Вот только и его лениво писать :-) Замкнутый круг :(

Shureg · 7 січня 2020

4 часа назад, Neuro75 сказал:

А зачем они нужны, если можно sshfs кусок сервера к локалке прикрутить?

А ничего, что sshfs - это, по сути, и есть sftp-клиент, только в профиль? Так что не "зачем они нужны", а именно ими вы и пользуетесь

ocdev_pro · 7 січня 2020

Что бы не писать 500 строк напишите 1 раз bash скрипт и пускай выполняет потом все за вас

Вхід

Подготовка VPS на Debian, Nginx+php-fpm, PHP 7.3, mariadb для Opencart 2/3

Recommended Posts

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Створіть аккаунт або увійдіть для коментування

Створити обліковий запис

Вхід

Схожі публікації

Зараз на сторінці 0 користувачів

Покупцям

Розробникам

Корисна інформація

Останні розширення

Important Information