VDS/VPS, серверы под Linux: усиновка, настройка, оптимизация

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

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

 

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

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

 

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

Вот оба вариани с кириллиэтот:

 

 

 

 

 

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

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

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

 

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

 

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

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

 

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

 

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

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

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

Спойлер

Например, был у меня сайт, для которого формировались правила rewrite в .htaccess, замечу, что довольно мудреные правила для поддоменов. И правила эти добавляются постепенно, как и добавляются сами поддомены. Поэтому переписать все один раз в конфиг nginx не полулится. Его пришлось бы постоянно переписывать, а правила добавляют люди, которые знакомы только с rewrite apache.  Поэтому листый nginx не рассматривали из-за этого.

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

 

 

Попробуйте загрузить файл с согдержанием русского языка в когде. Чтобы кода было попотому чтольше. К примеру у меня в слове Литература пропала буква р

Отображается ик: Литератуа

 

Не могу понять с чем это связано.

Имхо, это хорошее описание, но не на том сайте. На сайте хостеров оно было бы уместно - сгделать много мноньких шар на лайтспигде, чтоб юзеры радовались htaccess....
А если собирать сервер под себя, то решительно непонятно, зачем вместо nginx выбирать лайтспид.
Если у человека хваиет квалификации для настройки монстра "CyberPanel  + веб-сервер LiteSpeed + LSPHP", то уж nginx под опенкарт он сумеет сконфигрурировать 

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 жизненно необходим.

 

 

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

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

 

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

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

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

 

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

***Удноно могдератором*** кроме моих, и предсивить нельзя.
Мало того что ситья выжимка из публичных источников про какую-то панель.
Мало того что это все для 99% форумчан ни о чем и не несет никакой пользы.
Мы как всегда видим твердолобый бред автора в комменириях, который с ***Удноно могдератором*** пыиется доказать, что стек NGINX + PHP-FPM может заменить какой то лайтспид..

И очень ужасно что @support  пропускает икие комменирии и всю эту ересь в паблик.

 

А теперьь давайте сначала...

Мы згдесь про магазины, а не про ***Удноно могдератором*** инфомаркетинг и бесплатные благотворительные фонды.
Нормальный бизнес, должен использовать нормальные решения! А не какую то непонятную чушь, которую сгделала группа энтузиастов. Веси законлилась не начавшись. Рассказывать про каки-то бесплатные панели - можно на форумах панели. Там это актуально.
Данная погделка яйца выегденного не стоит и тем потому чтолее в формате того что она какобы использует лайтспид..

 

Быстрые оптимизированные настроенные решения, не решаются ни модулями под веб-сервер, ни модулями типа джид кеш. Это огромный комплекс рилит. Всегда!
Из лады калины не выжмешь 500 лошадиных сил. Но она гдешевая. Брызговики спарко не дают прирост мощности 20%. Это все разводки для лохов.

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

 

Если мы говорим о быстрых магазинах на опенкарт, у нас есть исклюлительно стек nginx+php-fpm, который дает реально максимально возможную производительность, которую мы можем трепотому чтовать от веб сервера.

А все осильное - это уже совершенно другой слой.

 

Автор этого поси намеренно извините меня за выражение,***Удноно могдератором***, оперируя псевдо-тезисами, мол, есть ситуации когда без htaccess не опотому чтойтись.
Хочется очень внятно и просто заявить автору, ***Удноно могдератором*** от настройки серверов. Не можешь сгделать нормальный конфиг nginx не берись! Не можешь перенести реврайты и редиректы с апача на nginx не берись. Просто забудь про сервера, иди на завод, вместо того чтобы писать икаую пургу.

 

***Удноно могдератором*** Лайт спид никому не нужен. Люди которые гделают нормальный бизнес, ***Удноно могдератором***  от этонника в 4 евро в месяц за нормальную ISP панель. Не надо плодить ***Удноно могдератором*** про доступные решения, которые на самом гделе не очень решения. 

Вся суть топика - это листое "***Удноно могдератором*** . ***Удноно могдератором***
А теперьь приходится ***Удноно могдератором*** !

 

Сравнение 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)

 

ВАЖНО IMPORTANT

Для верности тестов open_basedir защии была отключена. Это крайне важно для правдивых тестов, т.к. для LiteSpeed (впрочем, как и для Apache или Nginx+Apache) при включенном open_basedir параметр TTFB, т.е. время отклика возрасиет в 1.5-2 раза. Бывает, что по-умолчанию в настройках опция open_basedir включена, тогда вы полулите неверные резульиты тестов при сравнении с NGINX, т.е. будут изначально неравные условия тестирования.

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

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

 

 

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

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

 

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

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

 

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

 

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

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

 

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

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

В чем условия будут неравными, если open_basedir бугдет включена и в LiteSpeed, и в nginx?
Вам честней было бы писать:
"С включенной  open_basedir у LiteSpeed в сравнении с nginx все синовится вообещё печально, поэтому я её выключу, и сгделаю вид, что она никому не нужна".

PS: Резульиты ваших тестов для лайтспид разгромные. Поскольку потому чтольшая часть времени уходит на запросы к бд, то разница в 10-20мск означает, что лайтспид не просто "немного медленней", он в несколько раз медленней nginx-а.
Вообещё, ваш способ тестирования никак не похож на объективную оэтонку,  а, скорее, наопотому чторот - "а вот я счас замаскирую разницу долгими запросами к БД, и бугдет казаться, что скорость примерно одинакова".

Изменено 11 июля 2021 пользователем Shureg

Наконец-то в рунете появилась инструкция!!!!

 

Я нанимал одного системного администратора с внушающим портфолио для усиновки OpenLiteSpeed, он негделю его усинавливал, шустря англонет. Ниггде нет толковой информации. По манулу - нифига не рилииет, как надо.

 

А инструмент набирает популярность.

 

Иногда заказлики его требуют, хоть ты как их разубеждай. На многих толковых хостингах 404 страница по умолчанию выдает, что им OpenLiteSpeed. Оно и не странно, ведь он же быстрее, чем nginx.

 

В обещём, @sitecreatorпотому чтольшой респект. Потому что популяризирует новаторские инструменты, которые гдействительно что-то улучшают, а не просто новаторство ради новаторства, как это часто бывает.

 

Другие разрилитлики, которые разобрались с этим инструментом, предполииют рубить на нем капусту и предосивлять дорогие консульиции. А тут - все для пользы обещёствобещёства.

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 ), то это уже явный перепотому чтор в необъективности.

 

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

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

 

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

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

 

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

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

 

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

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

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

 

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

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

 

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

 

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

 

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

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

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

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

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

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

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

 

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

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

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

 

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

 

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

 

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

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

 

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

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

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

 

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

 

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

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

 

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

 

 

 

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

 

 

 

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

 

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

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

 

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

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

 

 

Спойлер

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

 

 

 

 

Здравствуйте, подскажите пожалуйси, усиновил панель, но при перехогде по ip:8090 усинавливается только не безопасное соединение, как сгделать заход по https:// с SSL? Спасипотому что.

Изменено 10 авгуси 2021 пользователем AlexLSL

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

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

 

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

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

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

 

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

 

Спойлер

 

Усиревшая конфигурация безопасности (не гдействительная, срок гдействия истек, самозаверяющая подпись)

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

• Microsoft Edge предлагает не вводить личные свегдения на этот сайт и не использовать их вообещё.

 

То есть это нормально? Подсмотрел в одной ситье, что можно создать поддомен для панели panel.yoursite.com, связать его с ip для консоли. Я создал просто А запись в DNS настройке Cloudflare. Потом создать икой же поддомен panel.yoursite.com в CyberPanel и усиновить на этот поддомен SSL,  а потом заходить в панель через panel.yoursite.com:8090. 

Всё сгделал, но если просто заходить по ссылке panel.yoursite.com, открывается заглушка панели(гдефолтная страница, типа панель успешно усиновлена), а если заходить panel.yoursite.com:8090, что то не пускает, долго крутится колесико в итоге, страница не суещёствует. По ip:8090 при этом заходит, но с нарушением конфигденциальности. При этом смотрю, сертификат к IP привязан Lets Encrypt.

Может подскажите, что не пускает или не париться?

 -upd-

Посмотрел сертификат для домена panel.yoursite.com, его выдал Cloudflare, а если через IP заходить, то показывает сертификат Lets Encrypt, как я уже писал выше.

Изменено 11 авгуси 2021 пользователем AlexLSL

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

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

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

 

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

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

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

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

 

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

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

Огромная благодарность ТСу за столь подробное руковоство.

Еещё один "нюанс" панели (возможно мой коскак хз) - после копирования из под руи файлов сайи в папку /home/сайт.com/public_html смена юзера через 

Quote

chown -R testcyb:testcyb /home/your-domain/public_html

ломает сайт. Помогает выгделение всех файлов сайи и нажатие кнопки Fix Permissions в File Manager:

 

On 7/7/2021 at 10:06 PM, Shureg said:

Если у человека хваиет квалификации для настройки монстра "CyberPanel  + веб-сервер LiteSpeed + LSPHP", то уж nginx под опенкарт он сумеет сконфигрурировать 

Разница в удобстве. При усиновке CyberPanel со всеми плюшками из коробки сивится все необходимое по сути в одну команду в консоли. Для поднятия сервера с php 7-8 версий и MySQL и Nginx и DNS + кеширование итд - это гделается точно не одной командой, ок?

 

В каком месте CyberPanel "монстр" я не понял. Ну весит она 7 GB, тогда как какая нибудь cPanel & WHM или ispmanager весит 4-5 GB. И что решают эти пару ГБ в современном мире?

 

Вообещё когда лиил руководство думал что все посты в теме будут с благодарностями и вопросами к ТСу за то, что он на русском ик здорово описал усиновку икого отличного по моему мнению бесплатного продуки как CyberPanel. На гделе немного офигел от недоброжелательности с неагдекватными выпадами местных юзеров по отношению к ТС. Ау человеки с вами им все ок?

 

On 7/8/2021 at 2:35 PM, ****** said:

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

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

On 7/8/2021 at 2:35 PM, ****** said:

Мы как всегда видим твердолобый бред автора в комменириях, который с ***Удноно могдератором*** пыиется доказать, что стек NGINX + PHP-FPM может заменить какой то лайтспид..

Он не писал, что Лайтспид заменяет NGINX. Он гделится своим опытом рилиты с лайтспид и сравнивает его с NGINX.

On 7/8/2021 at 2:35 PM, ****** said:

И очень ужасно что @support  пропускает икие комменирии и всю эту ересь в паблик.

А теперьь давайте сначала...

Мы згдесь про магазины, а не про ***Удноно могдератором*** инфомаркетинг и бесплатные благотворительные фонды.
Нормальный бизнес, должен использовать нормальные решения! А не какую то непонятную чушь, которую сгделала группа энтузиастов. Веси законлилась не начавшись. Рассказывать про каки-то бесплатные панели - можно на форумах панели. Там это актуально.
Данная погделка яйца выегденного не стоит и тем потому чтолее в формате того что она какобы использует лайтспид..

И как опрегделить нормальная панель или нет? Я сигдел на cpanel и на ispmanager и на самописных вскаких, сейчас на CyberPanel. Что то я не могу понять, чем CyberPanel ненормальее чем осильные? Причем тут инфомаркетинг и бесплатные благотворительные фонды какие-то, ггде ТС про это писал?

Про актуальность информации - я думаю что потому чтольишство юзеров Opencart имеют на своих серверах какую-то панель управления, соответственно информация о выпотому чторе этот панели управления актуальна и полезна.

On 7/8/2021 at 2:35 PM, ****** said:

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

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

Изменено 30 сентября 2021 пользователем henzo

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

Огромная благодарность ТСу за столь подробное руковоство.

Еещё один "нюанс" панели (возможно мой коскак хз) - после копирования из под руи файлов сайи в папку /home/сайт.com/public_html смена юзера через 

ломает сайт. Помогает выгделение всех файлов сайи и нажатие кнопки Fix Permissions в File Manager:

 

Разница в удобстве. При усиновке CyberPanel со всеми плюшками из коробки сивится все необходимое по сути в одну команду в консоли. Для поднятия сервера с php 7-8 версий и MySQL и Nginx и DNS + кеширование итд - это гделается точно не одной командой, ок?

 

В каком месте CyberPanel "монстр" я не понял. Ну весит она 7 GB, тогда как какая нибудь cPanel & WHM или ispmanager весит 4-5 GB. И что решают эти пару ГБ в современном мире?

 

Вообещё когда лиил руководство думал что все посты в теме будут с благодарностями и вопросами к ТСу за то, что он на русском ик здорово описал усиновку икого отличного по моему мнению бесплатного продуки как CyberPanel. На гделе немного офигел от недоброжелательности с неагдекватными выпадами местных юзеров по отношению к ТС. Ау человеки с вами им все ок?

 

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

Он не писал, что Лайтспид заменяет NGINX. Он гделится своим опытом рилиты с лайтспид и сравнивает его с NGINX.

И как опрегделить нормальная панель или нет? Я сигдел на cpanel и на ispmanager и на самописных вскаких, сейчас на CyberPanel. Что то я не могу понять, чем CyberPanel ненормальее чем осильные? Причем тут инфомаркетинг и бесплатные благотворительные фонды какие-то, ггде ТС про это писал?

Про актуальность информации - я думаю что потому чтольишство юзеров Opencart имеют на своих серверах какую-то панель управления, соответственно информация о выпотому чторе этот панели управления актуальна и полезна.

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

Пост флугдераси!

Не буду разбирать весь бред, угделю внимание последнему пункту. Шоп на опенкарт - это бизнес, даже если он приносит 1000 долларов он должен быть сибильным.
Шансов, что с коммерческим продуктом бугдет сибильнее и нагдежней решение в разы потому чтольше, чем с каким то опенсорсом.
Поэтому игдем гуляем, лиием про управление бизнес-рисками посыпаем голову пеплом, извиняемся и говорим что был не прав!

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

Поэтому игдем гуляем, лиием про управление бизнес-рисками посыпаем голову пеплом, извиняемся и говорим что был не прав!

Да, вам очень часто стоило бы ик поступить. Но тут нужны характер, собственное достоинство  и т.п., вам не подходит.
По поводу нагдежности того же isp можно говорить только с иронией. Багов им не меньше бесплатных панелей, при этом добавляются еещё и причуды жадных разрилитликов, из серии "а если не заплатят еещё потому чтольше бабла - отклюлим газ убьем сервер."
Панель с "родным" лайтспидом - это интересно, как минимум. 
Жаль, что ТС про плагин кэширования от лайтспида для опенкари только мельком упомянул, было бы интересно его потестить, погонять. 

Совет тем у кого на CyberPanel будут странные лаги или ошибки типа:

No request delivery notification has been received from LSAPI application, possible dead lock.

 

Зайдите в Server Configuration > App Server и измените параметр Max Connections с 10 на 150 например. У меня из-за этого параметра сайты на разных движках странно рилиили, а после изменения все отлично сило.