sitecreator

Т.е. получается, что вы просто слукавили, говоря о "худшем окружении"?

Вы сравниваете все исключительно с nginx?

А сравнивать веб-сервер LiteSpeed c Апачи или с nginx+apache, получается, что не нужно? Притом, что это, как раз, будет самым распространенным вариантом веб-серверов, используемых с опенкарт.

Повторюсь, что я исходил из того, например, владелец сайта хочет просто сделать безболезненный перенос магазина без правок конфигов, т.е. без отказа от htaccess. И он это может сделать при переходе с того же nginx+apache.

В htaccess может быть сотня правил rewrite (с заумной переадресацией на поддомены), и владелец сайта не хочет с этим разбираться и/или переписывать.

Вот есть у владельца сайта требование - должны работать htaccess.

Про "костыль" - это отговорка такая? Т.е. сравнивать не будем потому, что придумали отговорку про "костыль"?

А если все же сравнить, то как тогда распределятся места?

Apache, nginx+apache будут впереди или позади LiteSpeed?

Кстати, имеет смысл сравнивать производительность LiteSpeed не только и не столько с чистым nginx, а с nginx+apache.

Не говорю уже про сравнение с чистым Apache, что тоже можно было бы сделать.

Это к вопросу о том, кто займет первое место, а кто - последнее.

Понятно же, что LiteSpeed - это альтернатива в первую очередь именно nginx+apache, а не чистому nginx.

Т.е. сравнение серверов, работающих с .htaccess.  Т.е. рассматривается самый универсальный и бесконфликтный вариант.

Если же владелец сайта уверен, что у него не используется php-код, который может не запуститься под nginx, то, конечно, можно спокойно использовать чистый nginx с соответствующей конфигурацией.

Ранее я приводил уже пример подобного проблемного для nginx кода php. Это никак не связано с конфигурацией nginx. И описывал варианты исправления такого кода PHP если он, конечно, не под ионкубом. В одной из тем, посвященных, как раз таки, настройке опенкарт на чистом nginx.

Забавно, что люди, которые меня минусили раньше за описание перехода на чистый NGINX, теперь же минусят за освещение веб-сервера LiteSpeed.

Т.е. крупнейший провайдер отдал все же предпочтение LiteSpeed и отказался от nginx+apache?

Вероятно, что имея огромный практический опыт, крупнейший провайдер все же руководствовался здравым смыслом и объективными тестами в отличие от вас-теоретика?

Почему иногда все же приходится смотреть в сторону .htaccess, точнее, в сторону Апачи? Вовсе не потому, что сложно сделать конфиг для nginx. Вероятно, что для вас будет открытием, но не все завязано на конфиг и им же решается. Есть ряд случаев, когда без переделки кода PHP вы не заставите его работать на чистом nginx с самым правильным конфигом. Это касается, например, программ, работающих по протоколу 1С.

Вы бросаетесь слишком категоричными заявлениями вроде "невозможно сделать быстрый магазин". Хотя, подозреваю, что сами прекрасно понимаете, что лукавите. Если магазин с несколькими десятками тысяч товара отдает страницу за 200...400 мс с учетом всяческих фильтров товаров (и с "холодным" кешем БД) - это ли не быстрый магазин? И работает на LiteSpeed. И понятно, что при фильтрации основное время съедает работа с БД.

Синтетические бенчмарки - это часто дело довольно лукавое.

Ставьте два реальных на 100% одинаковых  магазина на 10 000 - 100 000 товаров с фильтрами, и делайте сравнение. Сравните статичные и динамические страницы. Разумеется, что настройки серверов БД должны быть одинаковые. И только тогда можно сделать вывод насколько существенна будет разница.

Причем, заметьте, я поставил целью сделать сравнение нескольких различных панелей управления. Я не навязываю ни какую-то конкретно панель управления, ни какую-то конкретную ОС или какой-то конкретный вариант веб-сервера. Я предлагаю рассматривать варианты и описываю эти варианты.

Вы с наскока и голословно объявили все программное окружение, которое предлагается вместе с CyberPanel, худшим на свете.

Но даже не потрудились перечислить это окружение и указать причину почему именно так вы считаете.

Теперь, по вашим же словам, оказывается, что LSPHP не так уж и плох? Или все же плох, но чем именно вы не можете сказать?

Есть крупнейший украинский хостинг-провайдер:

*******

Видимо, там совсем никудышные специалисты работают, раз они выбрали якобы "самое худшее окружение на свете"?

Да и помнится как  парень в желтой футболке пытался доказать насколько плох Linux Centos 7 в 2020-м. Тоже про "худший выбор"  речь вел. Мол, ядро старое, отсюда страшные дыры в безопасности и жутко тормозящий старый софт. Мы должны верить на слово подобным заявлениям?

Какие такие дыры могут быть в безопасности Centos 7 если поддержка этой ОС осуществляется до конца 2024 и регулярно выпускаются обновления, включая ядро ОС? Очередная версия Centos  7.9 была выпущена в октябре 2020-го.  Прошу заметить, что никто никому не навязывает определнную ОС, а просто предоставляется информация для анализа и выбора ОС. Впрочем, если какие-то убеждения не позволяют вам использовать Centos, то всегда есть выбор среди UNIX систем. К чему пустые холивары и предрассудки в качестве якобы "аргументов"?

Утверждать голословно, что, мол, что-то там невозможно потому, что "я так считаю" - это пустое. нужна конкретика, подкрепленная фактами.

Есть смысл сравнивать что-то конкретное.

У меня есть возможность сравнения магазина со 130 000 товарами, работающего под nginx+apache+php(module) и этого же магазина под OpenLiteSpeed+LSPHP.  Вот только влияние того же php на отклик страницы по сравнению с другими факторами будет крайне незначительный, т.к. в случае опенкарт решающее значение имеет работа базы данных. Или это тоже под сомнением?

Кстати, с чего вдруг сервер БД MariaDB стал в ряд "худшего окружения на свете"? Когда это случилось?

Но было бы интересно увидеть тестовую программу на PHP, которая бы работала медленнее в случае LiteSpeed+LSPHP по сравнению, например, с nginx+php-fpm. 

Панель жрет много ресурсов? Допустим и поверим, что это так. Насколько много и какой процессы (процессы) их пожирают?

Сравнительные данные, например, с ISPmanager (или другими панелями) где можно увидеть?

не вижу катастрофы с ресурсами:

Добавил информацию об антивирусе ImunifyAV, который поставляется вместе с CyberPanel и развертывается одним кликом.

Напомню, что в ISPmanager также есть этот антивирус ImunifyAV в виде модуля к ISPmanager.

Регулярное автоматическое сканирование  - довольно полезная опция.

Добавил информацию выше о том как создать пользователя и сайт, а также о файловом менеджере.

Тут довольно все интуитивно понятно за исключением момента как передать хостеру информацию о домене для его ns-серверов.

Можно просто вручную прописать у хостера домен через DNSmanager.

Теоретически можно наладить передачу с DNS-сервера (powerdns), который установлен вместе с панелью управления данных на ведомый (вторичный) сервер имен хостера. Т.е. powerdns на вашем VDS будет выполнять функцию master (первичного) сервера имен. Но с этим нужно разбираться, т.к. в самой панели управления нет возможности настроить доступ к вторичному серверу имен.

Резерв под описание 7

Также как и в ISPmanager в панели управления CyberPanel есть антивирус ImunifyAV.

Есть возможность работы по сканированию сайтов по расписанию.

Информацию о папках сайтов ImunifyAV получает автоматически.

Сам антивирус устанавливается легко прямо из панели управления сервером.

Это довольно удобно.

Вход в панель управления ImunifyAV осуществляется от пользователя root.

Так выглядит антивирус как модуль ISPmanager (чисто для сравнения):
 

LiteSpeed Cache for OpenCart

документация:

https://docs.litespeedtech.com/lscache/lscoc/

Цитата

Что такое LSCache?

LiteSpeed Cache (LSCache) - это встроенная высокопроизводительная функция ускорения динамического контента серверных продуктов LiteSpeed.

LSCache ускоряет динамический контент (а не только страницы PHP) с функциями, очень похожими на те, что в Apache mod_cache, используя эффективную, легко настраиваемую встроенную реализацию на сервере LiteSpeed, что значительно сокращает время загрузки страницы и нагрузку на сервер.

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

Цитата

Механизмом кэширования LiteSpeed можно управлять с помощью правил перезаписи в .htaccess корня документа веб-приложения. Итак, что вы получаете, используя плагин LSCache?

Плагин LSCache устраняет разрыв в знаниях между веб-приложением и механизмом кэширования.

Другими словами: в веб-приложениях есть правила о том, какой контент можно кэшировать, как долго он может храниться в кэше и какие события могут привести к устареванию объекта кеша. Плагины LSCache - это способ передачи этих правил веб-приложений в Cache Engine. Плагины LSCache позволяют управлять кешем таким образом, чтобы больше объектов можно было хранить в течение более длительного периода и с непревзойденной точностью.

В отличие от других плагинов кеширования для OpenCart, LiteSpeed Cache поддерживает кэширование для зарегистрированных пользователей и может кэшировать корзины покупок с товарами в них.

Как установить кеширование для Опенкарт средствами LiteSpeed расскажу немного позже если будет интерес у публики.

Нужно ли это кеширование? Какая польза и эффект от него?

Подводные камни?

А как же наши любимые ускорители-кешеровщики? Можем ли мы их не устанавливать, а пользоваться встроенными серверными возможностями кеширования?

Насколько гибкие настройки кеширования?

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

Постараюсь подробно осветить вопрос, а также поискать ложку дегтя, которая вроде бы должна идти в придачу к любой бочке меда. Или тут не окажется такой ложки?

Предполагаю, что для этого вопроса вполне уместно создать отдельный блог. Т.к. тема довольно обширная, и в тоже время далеко не всем сайтам требуется кеширование, т.к. многие правильно построенные сайты с кол-вом товаров более 10 000 работают очень шустро с веб-сервером LiteSpeed без всякого кеширования.

Установка Киберпанели на примере Centos 7

Установщик Киберпанель по идее сам должен установить правильную версию python и pip3. Но тут не всегда все проходит гладко. Поэтому если процесс установки не стартовал у вас гладко, то нужно самостоятельно установить нужную версию python.

Иногда при установке именно на Centos 7 завершается не всегда успешно установка Кибепанели, как раз из-за python (в Centos 7 по-умолчанию используется python 2-й версии ). В Ubuntu проходит все гладко.  Поскольку устанавливал многократно, то сделал такие наблюдения, от чего именно зависит - это сейчас не могу с абсолютной точностью сказать, т.к. использовался вроде бы  одинаковый образ ОС при установке, но результат был не всегда одинаковый после установки, но это все же может быть связано и с различиями в установочных образах Centos 7.


Узнать версию установленной ОС Centos:

cat /etc/centos-release

Узнать версии установленного
python

ls -ls /usr/bin/python*

Результат:

0 lrwxrwxrwx 1 root root     7 Jun 10 02:56 /usr/bin/python -> python2
0 lrwxrwxrwx 1 root root     9 Jun 10 02:56 /usr/bin/python2 -> python2.7
8 -rwxr-xr-x 1 root root  7144 Nov 17  2020 /usr/bin/python2.7
0 lrwxrwxrwx 1 root root     9 Jun 10 03:02 /usr/bin/python3 -> python3.6
12 -rwxr-xr-x 2 root root 11328 Nov 16  2020 /usr/bin/python3.6
0 lrwxrwxrwx 1 root root    17 Jun 10 03:02 /usr/bin/python3.6-config -> python3.6m-config
12 -rwxr-xr-x 2 root root 11328 Nov 16  2020 /usr/bin/python3.6m
4 -rwxr-xr-x 1 root root   173 Nov 16  2020 /usr/bin/python3.6m-config
4 -rwxr-xr-x 1 root root  3403 Nov 16  2020 /usr/bin/python3.6m-x86_64-config
0 lrwxrwxrwx 1 root root    16 Jun 10 03:02 /usr/bin/python3-config -> python3.6-config

Для установки CyberPanel необходимо наличие python 3-й версии и pip3.
Проверить версию установленного python3:

python3 -V

Установить python3 если отсутствует:

yum install -y python3-devel.x86_64

Если python3 нет в репозиториях нет, то подключите EPEL.

yum repolist

yum install epel-release

pip3 -V

yum install python3-pip -y

yum clean all

yum -y update

reboot

18 часов назад, sashaustenko сказал:

Нет смысла Вам отвечать.

Лаконичный ответ когда ответа нет.

Т.е. другими словами, за свои слова вы не отвечаете?

а для чего вы пишите тогда?

Т.е. вы даже не знаете что именно сами собрались заменить на "MongoBD"? На замену чему?

Которая, конечно же MongoDB подразумевалась?

Так и скажите, что сами глупость  ляпнули, но не понимаете как это теперь объяснить.

15 минут назад, sashaustenko сказал:

переход на MongoBD

это зачем?

и вместо чего?

16 минут назад, sashaustenko сказал:

Сайт невероятно быстр

неужели для этого?

Звучит завораживающе, но фантастически.

Цитата

Из основного

- минимальная версия PHP - 8

"Warning: You need to use PHP8 or above for OpenCart to work!"

 

А почему вдруг такая категоричность случилась?

Это хоть чем-то обусловлено?

Даниель это как-то объясняет?

Что такого невероятно прорывного используется в коде php опенкарт, что он даже на 7.4 не будет работать?

Есть примеры?

Да и для чего такая заведомо невероятная несовместимость?

Далеко не у всех хостеров есть 8-ка для выбора. Да и не все расширения php есть для 8-ки.  ioncube нет пока, например.

Реального прогресса от 8-ки мы, думаю, вряд ли увидим в опенкарт, пока вижу это как "дурью маются".

44 минуты назад, Igor123123 сказал:

Можете сказать есть смысл покупать версию Bacis. Или брать более дорогую.

Пр правильном подходе даже Bacis будет достаточно. Ибо это несравнимо более высокий уровень по сравнению с онлайн-кубированием.

Онлайн - это защита от школьника, точнее, от ленивого школьника. А вот в Bacis  уже начинается Защита!  Именно с большой буквы. Конечно, если вы не будете только нажимать на одну кнопку "кубировать", но приложите усилия для изучения документации. Она, правда, сложная, почти без примеров и с... багами местами.

47 минут назад, Igor123123 сказал:

Цель: я понимаю что если захотят то взламают

Сломают если защита поверхностная. А именно такая будет в 99%, т.к. все рассуждают по вашему же принципу "а зачем серьезно работать над защитой если все равно сломают?".

Вот сами и облегчаете работу для взломщиков.

Меня полгода ломала ломали... ломали ломали... но не сломали. Так и оставили эту затею.

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

Я с интересом наблюдал за их взломом. Оценивал промежуточные результаты, делал свои выводы. У них даже часть кода получилось восстановить. Но... совсем нерабочего.  Я читал этот код.  

52 минуты назад, Igor123123 сказал:

Меня больше волнует когда при покупке для одного домена ставят на все свои сайты.

Самый простой вариант - это использовать версию ПРО. В ней можно легко делать лицензионный файл с привязкой к домену.

Но это можно и средствами php делать, но для этого нужно поработать.

Нативная защита php лицензионным файлом также может быть взломана.

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

Если хотите хорошей защиты и использовать Bacis ионкуб, то начните с изучения методов асимметричной криптозащиты. Именно с помощью этих методов вы сможете делать надежные ключи с привязкой к домену - такие ключи, для которых невозможно создать keygen. Вот такие ключи - это основа защиты, и пункт № 1 в защите. Ионкуб идет уже на 2 месте.

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

В 21.04.2021 в 13:44, Igor123123 сказал:

Можно ссылку где Вы все детально описали?

Был ранее блог, теперь его нет.

51 минуту назад, Shureg сказал:

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

Думаете, что я долгие годы мучаюсь в сомнениях что же выбрать?

а подробно писал на эту тему в свое время в тематическом блоге.

не вижу смысла давать здесь подробности.

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

Я примеры привожу лишь для поднятия интереса к теме создания относительно НЕВЗЛАМЫВАЕМОГО софта. Можно также назвать ТЯЖЕЛО ВЗЛАМЫВАЕМОГО софта, т.к. при желании взломать можно, что угодно - было бы время и целесообразность.

Разумеется, что в публичном пространстве никто вам готовых решений не выложит по вполне понятным причинам.

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

Простой пример. Для тренировки мозга и способностей хакера.

Есть, например, один единственный закубированный файл программы.

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

Кто возьмется взломать? Найдется ли хакер?

Кстати, защитить один единственный файл - это намного проще и надежнее. Одна из проблем при защите - это взаимодействие с массой других открытых файлов через публичные функции и т.д. и т.п..

Черный ящичек защитить можно намного сильнее.

--------------

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

x = 2 + 2;

44 минуты назад, Shureg сказал:

И еще вопрос, раз ионкуб такой непробиваемый, авторы всех ломаных модулей - недоумки, не смогли защиту нормальную сделать?

Нет.

Причины разные.

Например, одна из самых распространенных.

Автор желает чтобы его модуль работал на древних php , например, на 5.5 или еще более древних.

И автор желает чтобы ионкуб лоадер 6, который встретишь в 1 случае из 500, тоже поддерживался.

Люди не хотят покупать, например, "ионкуб про"  за 300 $, да еще и с ограниченным сроком использования, но хотят пока остановиться на ионкуб онлайн.

Это не то, что догадки, я просто знаю этих людей, мы обсуждали эти темы.

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

Разработчики в 95% случаев не желают использовать для генерации лицензионного ключа (не связано с ионкубом никак)  несимметричные криптометоды, а потому в этих 95% случаев хакеры просто выдирают генератор ключа из самой программы.

@Shureg , как вы думаете почему разработчики так поступают? Даже  далеко не новички.

А ведь это намного проще чем использовать грамотно защиту ионкуба. И ничего не стоит в деньгах, не надо никакой коммерческий софт для защиты покупать. Эффективность в том, что хакер не сможет сделать так любимый варезниками KEYGEN.  Хакеру нужно каждый раз заново ломать новую версию программы.

Но не делают же!

Думаю, что просто не знают. Не знакомы с базовыми методами криптографической защиты.

@Shureg , а еще есть удаленный ключи. Это тоже ВНЕШНИЙ ключ, но до которого при всем желании вам не добраться.

могут находиться на каком угодно "далеком" сервере, передаваться по закрытому протоколу (с сертификатом и т.д.) и практически не отлавливаются (не перехватываются ) на сервере.

Это чисто для понимания возможностей.

Я, например, противник привязывания работы любого приложения к серверу разработчика или любому подобному серверу.

Я лишь привел как пример.  Этот ключ вы никак случайно удалить тоже не сможете.

Как и ключ внутри другого ключа, например, внутри нативной лицензии ионкуба.

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

По разным причинам связь с удаленным сервером может отсутствовать.

Я считаю, что покупатель должен поставить модуль и работать, да хоть на локальной машине вообще с отключенным Интернетом.

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

@Shureg , вы хотите сказать, что у вас возникнет непреодолимое желание изменить что-то в подобном файле?

Сильно сомневаюсь, что вы получите от этого пользу.

А вот неработоспособность - это запросто.

Не стоит все доводить до крайностей и абсурда.

Понятно дело, что закрытые кубом файлы не подлежат редактированию по умолчанию, это бессмысленно.

Я лишь сделал маленький намек на то, что в ионкуб есть интересные средства. Но любой серьезный инструмент требует аккуратности.

Постарался сделать это наглядно.

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

@Shureg , динамический ключ находится как бы "внутри " закубированного файла. Хоть его там и нет если понимать буквально, т.к. он вычисляется в результате определенных действий и в результате определенных последовательности событий.

Он не потеряется, не волнуйтесь.

9 минут назад, Shureg сказал:

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

Надеюсь, что вы просто шутите.

я лишь привел возможные варианты для наглядности. и простоты понимания. 

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

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

Их можно использовать, но осторожно - крайне осторожно.

И в профессиональном форуме на сайте ионкуба тоже есть информация на эту тему.

Не стоит доводить до степени абсурдности вроде "заставь дурака Богу молиться...", согласны?

9 минут назад, Shureg сказал:

Изменение любого файла может оказаться фатально.

А вы хотите изменять закубированный файл?

"Понятно, буду иметь ввиду" (с) 

Надеюсь, что вы поняли эту шутку как намек?

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