cat file1 file2 > file3
Но это требует ковыряния в инсталлере. Или уже нет?
Про точку отсчёта услуг -- согласен. Ну а поспорить ещё можно 🤪
Есть ещё одна панель -- DirectAdmin. Она предоставляет скрипт CustomBuild, который умеет собирать всё ПО из исходников (ну кроме MySQL, который никто из исходников не собирает). При этом это уходит на такой кровень, что для PHP собираются свои версии libxml, curl, iconv и прочего. При этом свои версии она кладёт в /usr/local/ (при чём не в /usr/local/name, а в /usr/local/), и симлинкит их из /usr/lib. Получается, на 32битной системе есть два варианта библиотек в одной папке -- от ОС и от CustomBuild, при чём они, скорее всего, разных версий. Является ли это правильным подходом?
Пускай панель собирает всё ПО, которая она хочет, где-то в /opt/panelname, но не трогает ОС. И у администратора, который считает, что он сам должен заниматься установкой ПО, не передавая это на разработчиков панели, которые, скорее всего, не знают специфических требований его окружения, будет выбор, какие симлинки положить в /usr/bin -- те, которые собрала панель в /opt или те, которые он собрал сам rpmbuild'ом. Кстати, DirectAdmin предоставляет эту возможность, только предельно криво.
Boris A Dolgov добавил 11.07.2011 в 14:00
Это по сравнению с RHEL, а не vanilla-версиями тех пакетов.
Пожалуйста, не выдёргивайте из контекста. Тот расчёт был приведён в пример чтобы показать, что так считать нельзя.
Ну а указанная Вами "ожидаемая политика сотрудника фирмы" говорит о том, что Вы не умеете набирать сотрудников (ну или платить им).
А фрилансер просто не может работать больше определенного времени, сохраняя хотя бы внимательность и сосредоточенность.
Это глупо. Разработчики панели должны разрабатывать панель, а не серверное ПО.
Ну, вижу, Вы не считаете установку RPM тривиальной задачей ;)
RHEL как-то живёт с сотнями тысяч (если не миллионами) клиентов, и все как-то пользуются стандартными собранными RPM. И все устраивает!
Позволяет -- просто возьмите RPM с офсайта и поставьте их.
cPanel уже начала поддерживать exim, sendmail и postfix? :) Вот это даже из коробки работает на всех ос.
Вы не поверите, но и лимиты на отправку писем (правда, на пользователя) там настраиваются
Ну, чего нет -- того нет 🤪
Выделенное жирным -- неправда. Fastcgi -- да, нет из коробки, решается, опять же, втыканием одной rpm. Из доверенного репозитория epel или rpmforge, которым пользуются ну уж не меньше, чем сипанелью, и которые панель подключает при установке. cgi тоже никто не отменял.
Я не понимаю -- для Вас показателем успешности панели является то, насколько мало мозгов должно быть у её админа, чтобы сделать хостинг на ней? Если так, то это скорее играет в минус панели, чем в плюс для конечных клиентов;). Потому что в случае любой нестандартной проблемы Вам всё равно придётся лезть в SSH и править конфиги/переустанавливать ПО. И ещё не ясно, как человеку, который способен делать это, проще ставить набор требуемого софт -- кликая мышкой по easyapache, или командой rpm -ihv http://my.repo.ru/myrepo-release.rpm && yum update -y
Да и отделите уже претензии к RHEL5 (вышедшему более 4 лет назад, когда cPanel не имела даже намёка на русский перевод, на VPS с 512мб памяти постоянно падала в OOM, а vps с ISP спокойно жил на 256, и easyapache был альфой, которая любила всё портить).
Не засоряйте интернет.
Я не пользовался ими, так как делаю так, как говорит Andreyka :)
У них есть README, там есть примеры.
Да. Это достигается двумя модулями:
http://mdounin.ru/hg/ngx_http_compose_filter_module/
http://mdounin.ru/hg/ngx_http_bytes_filter_module/
Там, увы, не только с ai проблемы -- для её обхода, вроде бы, они придумали чётность этих значений инкремента -- там ещё могут быть проблемы со временем и с запросами, которые влияют на выполнение последующих.
Но для совсем несерьезных баз должно быть незаметно, да.
