CyberPanel - бесплатная панель управления для VDS / VPS / сервера + LiteSpeed + Linux Ubuntu 18.04 / 20.04, Centos 7 / 8

Установка Киберпанели на примере 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

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 без всякого кеширования.

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

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

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

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

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

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

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

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

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

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

Не устаю повторять, что в OpenCart скорость кешей практически никогда не является узким местом. Просто потому, что другие 2 узких места (скорость выполнения запросов MySQL и кода PHP) не дают магазину развить достаточную пропускную способность, чтобы скорость работы кеша стала заметной.

Что касается конкретно кеша страниц, нет большой разницы - страница отдалась за 0.01 сек или за 0.0001 сек. Все это феноменально быстро по сравнению с генерацией страницы даже при всех мыслимых оптимизациях и самых крутых серверах.

А за пост спасибо, полезное и классно расписано!

8 часов назад, MaxD сказал:

 

Не устаю повторять, что в OpenCart скорость кешей практически никогда не является узким местом. Просто потому, что другие 2 узких места (скорость выполнения запросов MySQL и кода PHP) не дают магазину развить достаточную пропускную способность, чтобы скорость работы кеша стала заметной.

 

Что касается конкретно кеша страниц, нет большой разницы - страница отдалась за 0.01 сек или за 0.0001 сек. Все это феноменально быстро по сравнению с генерацией страницы даже при всех мыслимых оптимизациях и самых крутых серверах.

Позволю не согласиться. Опенкарт "умеет" создать проблему даже в кеше. Например чего только стоит glob на каждую инициализацию класса.

Цитата

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

Всем кто привык к Vesta крайне рекомендую использовать Hestia CP. Это форк весты, который динамически развивается, и имеет гораздо больше "плюшек".

Спасибо за пост.

Одно время использовал на битрикс/opencart проектах Brainy CP отечественной разработки, но в последствии отказался.

Пока ISP Manager впереди любой панели, но всвязи с текущими изменениями она становится не так уж удобной.

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

Brainy CP отечественной разработки, но в последствии отказался

если не секрет, почему отказались ?

у меня стоит 3 года уже и вроде все устраивает

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

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

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

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

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

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

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

мануал по установке худшего окружения на свете, мало того что эта панель жрет больше ресурсов, чем докер вместе c любым аркестратором, еще и берем худший веб сервер для php, который проигрывает по всем бенчмаркам nginx.  Плюс мы демонизируем php что вообще не приемлемо для языка который должен родиться и умереть. Сделать быстрый магазин на этом легаси не возможно, ну если только у вас не одна страница html, а с этим и шаредик справится

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

*******

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

Да и помнится как  парень в желтой футболке пытался доказать насколько плох 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 (или другими панелями) где можно увидеть?

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

крупнейший хостинг провайдер, использует лайтспид, лишь потому что у него есть htacces, потому что нацелен на домохозяек, которые не могут собрать конфиг nginx

ну и если хочется сухих цифр то вот, собрал 2 стенда https://github.com/stickpro/ngx-vs-lightspeed
в бенчмарке особой разницы  нет так как это по сути тест php и разница будет видна только в разных версиях языка, а вот с ttfb разница заметна в docker-compose можно увидеть какие все об окружении

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

nginx+apache это просто костыль, если хотите сравнивать одинаковые магазины пожалуйста, в репозитории все для этого есть

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

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

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

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

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

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

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

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

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

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

2 часа назад, Dmitry_1988 сказал:

что файловый менеджер не поддерживает кириллические символы

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

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

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

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

Уже загруженные файлы файловый менеджер отображает нормально.

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

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

Также без проблем можно производить операции с кириллическими файлами (копирование, перемещение и т.д.)

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

Все же панель управления не для этого.

Для загрузки картинок вполне годится фтп или менеджер в самом опенкарт с поддержкой массовой загрузки перетаскиванием.

Например, этот файловый менеджер для Опенкарт:

Но если хочется прямо в панели управления файловый менеджер, который работает без проблем с кириллицей в любых ситуациях, то стоит смотреть в сторону панели управления aaPanel.  Я уже упоминал ее. Там файловый менеджер позволяет работать с любыми папками, а не только с папками сайтов. Но в aaPanel метод drag & drop работает только в Хроме и подобных браузерах, но не в FireFox. В ISPmanager, кстати, нет в файловом менеджере drag & drop.

Пример файлового менеджера aaPanel:

Описание aaPanel я готовлю в настоящий момент.

Пока отмечу еще раз, что панель управления aaPanel позволяет вам использовать

на выбор несколько сценариев веб-сервер + PHP (с aaPanel ):

• nginx + php-fpm (без поддержки .htaccess)
• openLiteSpeed + lsphp (с поддержкой .htaccess)
• apache + php (apache module )

Используя aaPanel у вас есть прекрасная возможность сравнить производительность разных серверов на одном железе и одинаковом программном окружении (сервер БД и т.д.) с одинаковыми настройками. Т.е. один и тот же сайт без переустановки можно протестировать под управлением разных веб-серверов. Чем не база для объективной и непредвзятой оценки?

Повторюсь еще раз, что я решил сделать детальный обзор разных достойных панелей управления под разными операционными системами Linux/

Если интересно, то могу и под FreeBSD 11, 12, 13 также рассмотреть варианты, т.к. с ними я тоже работал, но это сильно на любителя, но в целом для профессионала FreeBSD также может быть интересна, хоть для нее нет полноценных панелей управления как для Linux.

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

Я работал с ними довольно продолжительное время на разных проектах.

Практически все они неидеальные, приходится мириться с их отдельными недостатками.

Но они сильно облегчают работу непрофессионалу. И позволяют сделать некоторую экономию средств по сравнению с платной панелью управления.

На мой взгляд, если есть возможность для вашего сайта использовать чистый nginx + php-fpm, то стоит отдать ему предпочтение.

Если же по тем или иным причинам вы не можете отказаться от htaccess, то тут на выбор:

• OpenLiteSpeed
• Nginx + Apache

Использование веб-сервера Apache (в чистом виде) можно оправдать в случае небольшого магазина с небольшой нагрузкой. Но, как правило, на VDS не переходят с небольшим магазином, а, как раз наоборот, поэтому этот вариант получается самым неудачным  выбором.

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

Может ли это быть связано с тем , что панель написана на питоне?