sitecreator

23 часа назад, Tank сказал:

А про Fastpanel такой обзор не планируется?

планировался, был готов сделать.

но, как видите, рейтинг подобных тем очень низкий.

люди проголосовали против подобных тем.

звездочки (оценка блога) ведь отражают реальное мнение? "два с плюсом" из пяти?

я сделал блог по еще одной панели управления:

думаю, что достаточно.

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

Попробовал aaPanel - она офигительная! Все есть, простая установка и настройка. Понравилась👍

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

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

20 часов назад, AlexLSL сказал:

при переходе по ip:8090 устанавливается только не безопасное соединение, как сделать заход по https:// с SSL?

Здравствуйте.

соединение по-умолчанию производится по https, по http вы не сможете подключиться.

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

Вам сама панель управления после установки сообщает ссылки для входа, они все с HTTPS.

23 часа назад, dexion сказал:

в случае смены панели придется переустанавливать весь сервер

это верно.

23 часа назад, dexion сказал:

учитывая криворукость хостера и предыдущие опыты подобных переездов

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

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

Обращайтесь если нужно, помогу.

12 часов назад, dexion сказал:

принудительно обновили всех с isp5 на isp6

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

Фактически 6-я версия отчитается от 5-й только тем, что она дороже и есть ограничения на кол-во доменов, включая даже поддомены (только если у вас не авто-поддомены, на них ограничение не распространяется). Функциональной разницы не было замечено, как минимум, чего-то принципиального.

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

12 часов назад, dexion сказал:

А что скажете насчет FastPanel?

Весьма неплохая альтернатива. Работал с этой панелью управления.

Основное отличие от остальных панелей управления - это автоматическая передача данных по доменам на ns-сервера хостера.

Принцип тут такой же как и в ISPmanager в этом плане.

Т.е. в панели управления вы просто создаете домен, а записи для домена автоматически передаются на ведомый сервер имен, а далее становятся автоматически доступны на всех ns-серверах вашего хостера.

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

FastPanel позвроляет использовать связку веб-серверов Nginx+Apache.

В принципе все минимально необходимое в FastPanel есть. Дополнительных возможностей почти нет. aaPanel в сравнении возможностей будет побогаче.

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

Для неподготовленного пользователя, почти незнакомого с Linux, вполне подойдет FastPanel.

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

О, там даже AWS S3, надо будет испытать эту панель управления в деле

да, есть.

Если вам удобно хранилище амазона S3, то, пожалуйста, без проблем.

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

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

Выгляди в целом довольно неплохим вариантом замены isp manager.

Так и есть.  И никаких ограничений по кол-ву доменов/поддоменов.

Работает все довольно стабильно. Есть более продвинутый файловый менеджер если сравнивать с ISPmanager.

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

Да и в 90% случаев все пользуются фтп-хранилищами от провайдера, а многие вообще забили на бекап, хоть это неверно совсем.

Будут вопросы - задавайте. Я работал с очень разными панелями. Поэтому довольно хорошо знаю отличия. Разумеется, что все их нет смысла добавлять в описание. Но тонкости про S3 я написал. 

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

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

Восстановить БД при необходимости из архива backup-а:

9 часов назад, Tank сказал:

А можно автоматизировать создание бекапов на удаленный сервер, например S3 или Dropbox/Google drive?

Уже добавил подробное описание.

Как получить ключ для Google Drive также могу подробно расписать если это нужно. Но, пожалуй, описание получения ключа займет больше места и времени чем описание самой процедуры бекапа в aaPanel.

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

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

А можно автоматизировать создание бекапов на удаленный сервер, например S3 или Dropbox/Google drive?

можно. постепенно все подробно опишу как. Главное - это чтобы был интерес к теме.

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

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

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

Это приведет к тому, что общее время загрузки файла может существенно возрасти, не смотря на то, что параметр TTFB при этом будет хорошим.

Т.е. будет увеличенным параметр Content Download.

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

Без ограничения ситуация выглядит значительно лучше, т.к. как "стало в два раза быстрее".

А в случае Апачи или Nginx по-умолчанию не будет никаких ограничений.

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

Вариант "быстро установил и пошел тестировать LiteSpeed" также быстро может привести к неверному заключению и разочарованию.

Кстати, параметр скорости Content Download зависит еще от нескольких параметров, вплоть до используемого браузера.

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

Спойлер

Нужно сперва создать профиль, который именуется в панели управления как Package. Или изменить дефолтный. Package будет использоваться при создании нового сайта, каждому сайту может быть назначен свой Package, который ставит лимиты на дисковое пространство и скорость передачи данных. По умолчанию эти лимиты очень низкие, например, для диска ограничение - 10 М. Из-за этого через файловый менеджер вы не сможете загружать большие файлы (через фтп сможете). Скорость передачи данных по дефолту тоже очень маленькая. Нет смысла проводить тестирование скорости веб-сервера с дефолтными ограничениями. Рекомендуется установить 0 (без ограничений). Веб-сервер нужно перезагрузить.
 

 

 

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

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

Я нигде не писал, что он лучше.

Я не знаю почему у вас сложилось такое впечатление.

Какое мое сообщение приводит к такому выводу?

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

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

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

Лайтспид получше apache, не столько по скорости, сколько по ресурсам. Потому и перешли.

Т.е. получается, что litespeed - это не худший вариант как здесь пытались заявлять?

И сайты могут все же быть быстрыми на litespeed? Даже с использованием php?

Согласитесь, что все же не очень то компетентно выглядят некоторые заявления, что litespeed - это "худший вариант из всех возможных"?

7 часов назад, Shureg сказал:

что лайтспид не просто "немного медленней"

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

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

Или вы считаете, что они не делали всевозможные тесты, не собирали месяцами статистику с десятков тысяч сайтов?

Ведь что-то их побудило к такому переходу?

Т.е. можно предположить, что, как минимум, для них LiteSpeed работает не медленнее чем nginx+apache.

А зачем же менять шило на мыло? Что-то же они должны были получить в итоге полезное? Думаете, что выигрыша не получили? А зачем тогда перешли?

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

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

Тут же престиж и хорошие отзывы о работе компании будут на первом месте? К чему бы им рисковать и ставить что-то заведомо худшее?

Вот как-то не вяжется этот осознанный выбор (отказ от nginx+apache в пользу LiteSpeed ) крупнейшего хостинг-провайдера с "самым худшим выбором".

Лично у меня нет такого большого опыта с тысячами сайтов чтобы делать далеко идущий вывод о LiteSpeed . Разумеется, что я вначале с сомнением и опаской отношусь к отказу от "классики" в виде nginx+apache. Но могу судить на своем небольшом опыте, что в случае LiteSpeed сайты не стали работать медленнее.

А с чистым NGINX работаю много лет. И всегда его советую если есть возможность полного отказа от htaccess и нет проблем с удаленным доступом к серверам 1С из некоторых программ, которые построены исключительно под Апачи.

Поэтому агитировать меня за NGINX не нужно, я всеми руками только за, и был в первых рядах за него когда еще известный форумный борцун "против всего плохого" был против NGINX.

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

В чем условия будут неравными, если open_basedir будет включена и в LiteSpeed, и в nginx?

в том то и дело, что выключено в nginx по-умолчанию. Вы используете open_basedir совместно с nginx?

В панелях управления даже такой опции нет для nginx. Чтобы включить нужно специально прописывать конфиги. Но этого практически никто не делает, т.к. и нужды в open_basedir нет.

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

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

Если сравнивать с включенным  open_basedir, то в таком случае с apache или nginx+apache тоже с включенным open_basedir.

Выражаясь вашими словами, то в apache или nginx+apache будет все "вообще печально" в таком случае.

Только почему-то странным образом apache или nginx+apache - это не самый худший вариант в плане скорости, а litespeed - самый худший? Где логика?

То, что nginx будет впереди планеты всей, это я всегда говорил. Но если вам нужен непременно поддерживаемый .htaccess, то у вас будет выбор:

• apache
• nginx+apache
• litespeed

Т.е. вы не сможете использовать NGINX если вам нужен непременно htaccess.

Что важно конечному пользователю? Ему важна работа его реального сайта и важен конечный TTFB, т.е. отклик. Ранее было довольно странное заявление о невозможности создать на litespeed быстрый сайт, что не соответствует истине. Я показал, что можно если брать мерило в виде TTFB. Что не так? Вы не находите нелепым утверждение, что на litespeed быстрым может быть только HTML, но не сайт с использованием php?

Если подходить с такой же жесткой позицией к apache или nginx+apache, то на них, получается, что тоже невозможно создать быстрый сайт? Но, однако, на nginx+apache есть полно быстрых сайтов.

Владельца сайта обычно интересует увидит ли он реальный прирост производительности при переходе на чистый NGINX. Вот его интересует то, что он может увидеть глазами. А увидит он TTFB.

Т.е. я говорю о том, что довольно нелепое было высказывание насчет якобы тормознутости litespeed на фоне таких же тормознутых вариантов как apache или nginx+apache.

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

то разница в 10-20мск означает, что лайтспид не просто "немного медленней", он в несколько раз медленней nginx-а.

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

Посмотрите на этот анализ:

https://blog.herecura.eu/blog/2020-06-16-openlitespeed-vs-apache-vs-nginx/

И, еще раз, я рассматривал litespeed как альтернативу для:

• apache
• nginx+apache

Т.е. для случая, когда NGINX не может быть использован по причине необходимости обработки htaccess веб-сервером.

Пожалуйста, не стоит забывать об этом важном условии.

Не надо пытаться приписывать мне заявление о превосходстве (или полном равенстве) litespeed над NGINX.

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

резерв 5 для продолжения описания

резерв 4 для продолжения описания

Создание сайта/домена.

Создайте через dnsmanager (данные для доступа предоставляет провайдер) соответствующие записи для домена. Выбирайте "master".
Внесите название домена и IP вашего сервера.
 

 

Удобно сразу создать соответствующий FTP аккаунт и базу данных (пользователь и название БД будут совпадать)
 

 

Поставьте нужные редиректы:
для домена с www на домен без www
на HTTPS с HTTP (если выбрали создание SSL)

 

 

 

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

 

 

Чтобы сертификат автоматически продлевался необходимо чтобы была включена соответствующая cron-задача. По-умолчанию эта задача выключена. Включите ее. Статус должен быть Enable. Если забыть это выполнить, то вы рискуете пропустить момент когда закончится действие сертификата SSL и сайт окажется недоступным в таком случае.
 

 

Должно быть так:
 

Чтобы работали ЧПУ для опенкарт нужно в конфигурацию nginx для сайта добавить:

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

Также необходимо закрыть от доступа некоторые типы файлов и папки. Это также прописывается в конфиге.
Нужно также добавить в конфиг статические файлы webp и шрифты, и назначить для них время жизни кеша браузера 30d (желательно не меньше).
Стат. файлам js, css по умолчанию задается 12h, замените на 30d.

rewrite правила для конкретного сайта можно внести на отдельной вкладке настроек сайта. Все эти правила сохраняются в отдельном файле конфигурации.

Немного позже я добавлю как пример полный вид файла конфигурации здесь. Кстати, ранее на этом форуме я уже приводил варианты конфигурации NGINX для opencart.

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

Надо сказать, весьма недурного фильтра, необоснованно и голословно обруганного некоторыми господами, которые даже не пожелали разобраться и понять его особенности. Т.е. с порога фильтр был назван "тормозным". Какие были аргументы? Да никаких!

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

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

Я оперирую только цифрами. Реальными цифрами на реальных магазинах.

Лучше ли будет чистый NGINX по производительности? Да, будет лучше.

Но и OpenLiteSpeed позволяет работать магазину на опенкарт довольно шустро.

Сравнение NGINX + PHP-FPM vs LiteSpeed + LSPHP

Использовались для теста VDS с одинаковыми параметрами:

• 1 ядро 2.4 ГГц,
• 2 Гбайт памяти,
• 20 Гбайт диск SSD,
• ОС Linux Centos 7.9
• PHP 7.2

Для веб-сервера Nginx+php-fpm использовалась панель управления aaPanel.
Для OpenLiteSpeed +LSPHP - CyberPanel соответственно.


Была использована база товаров реального магазина на 17 000 позиций.
Измерялся параметр TTFB для:

• главной страницы
• страница Категория на 15 товаров
• страница Категория на 100 товаров

OpenLiteSpeed

 

 

Спойлер

 

 

 

 

NGINX

 

 

Спойлер

 

 

 

 

Итак, результат. Ожидаемо, что NGINX+PHP-FPM оказался несколько быстрее.
Нужно также учитывать, что это был т.н. "спокойный тест", т.е. когда одновременной нагрузки на сервер в виде многочисленных пользователей не было, был условный один пользователь. При "стресс-тесте", когда происходят одновременно массовые запросы, результаты должны быть несколько иные.

Никаких кеширований HTML средствами серверов не использовалось. Настройки серверов БД были идентичные.

Главная страница: 56 ms (LiteSpeed) / 52 ms (NGINX)
Страница Категория на 15 товаров: 94 ms (LiteSpeed) / 81 ms (NGINX)
Страница Категория на 100 товаров: 173 ms (LiteSpeed) / 152 ms (NGINX)

 

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

Вопрос потребления памяти веб-серверами - это отдельный вопрос. Выше был тест производительности.

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

зачем вместо nginx выбирать лайтспид.

а не рассматривали такой аргумент как наличие готового модуля кеширования HTML для опенкарт средствами веб-сервера?

Для nginx есть что-то подобное? Я имею ввиду не само кеширование (оно есть в nginx ), а готовое средство в виде модуля для опенкарт.

Зачем ставить всяческие кешеры HTML если есть нативное кеширование веб-сервером?

Разумеется, можно сказать, что надо делать грамотно изначально сайт быстрый и т.п. Но если уже есть тормозной сайт и оптимизацией БД можно лишь отчасти решить проблему?

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

А если собирать сервер под себя, то решительно непонятно, зачем вместо nginx выбирать лайтспид.

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

если коротко, то работали постоянно сео-спецы, которые что-то мудрили с поддоменами, и работали они исключительно с rewrite htaccess.

Они не создавали сами поддомены и в принципе не лезли в код опенкарт постоянно, но время от времени экспериментировали с htaccess.

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

nginx под опенкарт он сумеет сконфигрурировать

это всегда будет лучший выбор.

поэтому LiteSpeed есть смысл рассматривать если нельзя отказаться от htaccess.

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

А если собирать сервер под себя

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

Для себя любимого поставил бы nginx и обошел бы ограничения софта на php, которые возникают при обмене данными по протоколу 1С (и подобные) с удаленным сервером.

При возможности почти всегда ставлю чистый nginx.

Если же nginx+php-fpm, то отлично подойдет панель управления aaPanel.  При этом можно не удаляя сайта переключиться на apache или LiteSpeed если поняли, что htaccess жизненно необходим.

13 минут назад, Dmitry_1988 сказал:

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

Я не встречался с такой проблемой если кодировка документа UTF-8.

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

В каждой панели управления мне (да и другим пользователям) чего то не хватает, идеальной нет.

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

Я попозже попробую выкатить сводную таблицу недостатков каждой панели управления. Но и достоинств, соответственно.

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

И бывают иногда веские причины использования .htaccess.

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

Редактор теряет русские буквы.

вот тут не понял.

Если открыть редактор из файлового менеджера, то проблем с редактированием не заметил. Кириллица нормально вводится и отображается. Кодировка UTF-8.

Причем, есть два редактора на выбор: простой и с подсветкой синтаксиса.

Вот оба варианта с кириллицей:

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

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 не переходят с небольшим магазином, а, как раз наоборот, поэтому этот вариант получается самым неудачным  выбором.