Apache mpm itk или apache mpm prefork что лучше
Apache: MPM – worker, prefork или event?
Если быть совсем кратким – MPM используется сервером Apache для обработки нескольких запросов несколькими процессами одновременно.
Итак, начнем с модуля PreFork – на данный момент он является наиболее распространенным модулем, и по умолчанию Apache устанавливается именно с ним.
Apache MPM PreFork запускает по отдельному процессу на каждый запрос. Иначе говоря, каждый процесс одновременно обрабатывает только 1 поток ( thread ) на одно соединение. Т.к. PreFork заранее создает определенное количество процессов, которые не требуют времени на отдельный вызов при поступлении запроса к серверу и не нуждаются в выполнении маршалинга (в технологии ORPC – процесс упаковки запроса, включая параметры, в стандартный формат, пригодный для передачи по сети) во время его обработки, то такой вариант является наиболее быстродействующим, по сравнению с другими MPM. Однако, такой прирост производительности имеется только в случае, когда одновременно поступает некоторое ограниченное количество одновременных запросов, т.к. каждый из них должен ждать, пока процессор сможет их обработать. Кроме того, попытки увеличить количество одновременно запускаемых процессов способно серьезно повлиять на используемую сервером память.
Что касается сравнения работы Worker и PreFork – то можно увидеть сравнения например тут>>>. Как видно, разница между ними всего несколько процентов, однако – все зависит от специфики каждого сервера и обрабатываемых им запросов.
Так же, существуют ещё несколько вариантов MPM – mpm-itk, mpm-peruser и другие>>>.
Напоследок – несколько полезных команд.
Узнать, какой тип MPM используется в установленном Apache можно любой из команд:
Установить Apache с выбранным MPM можно из соответствующего порта:
/usr/ports/www # ls | grep apache
…
apache22
apache22-event-mpm
apache22-itk-mpm
apache22-peruser-mpm
apache22-worker-mpm
…
Apache MPM ITK: FastCGI vs MPM-ITK
Что быстрее? FastCGI или Apache MPM ITK? Какое решение выбрать для разграничения прав пользователей на httpd процессы сервера? mod_peruser, mod_suphp, fastcgi ил Apache MPM ITK?
Все эти модули веб-сервера Апаче (mod_peruser, mod_suphp, fastcgi) применяются для разграничение прав на файлы и каталоги между различными пользовательскими PHP процессами и собственно сервером Apache и все они оказывают влияние на производительность.
По умолчанию подключенный PHP работает под mod_php (mod_php5) от имени пользователя с логином Apache или www-data и все каталоги или файлы создаются с правами этого пользователя.
Когда мы подключимся по ФТП от имени другого пользователя (например от имени пользователя vasya), не пользователя root, и попытаемся перезаписать или удалить файл или каталог принадлежащий пользователю Apache или www-data, то нам этого недадут сделать.
Чтобы неиспользовать пользователя root и в тоже время не иметь проблем с загрузкой файлов, нам нужно использовать mod_peruser, mod_suphp, fastcgi или Apache MPM ITK, которые помогут запускать PHP процессы от имени конкретного пользователя.
Описание Apache MPM ITK
MPM-ITK модель распространяется в виде патча к Apache (apache2-mpm-itk or httpd-itk) и реализована на традиционной MPM модели PreFork (противоположность «Worker MPM»), т.е. без использования thread/нитей (ака non-threaded), это означает, что вы можете без проблем запустить любой «non-thread-aware» код (как и многие PHP расширения). С другой стороны, при использовании «non-threaded» MPM модели возможна некоторая потеря в производительности, конечно, Вы должны решить для себя, стоит это того или нет. Производительность MPM-ITK по сравнению с PreFork чуть ниже из-за того, что создается дополнительный «Fork» на каждый запрос.
Странности и предупреждения Apache MPM ITK
Ещё одна особенность MPM-ITK: Если было выполнено подключение к HTTPD и сделан запрос, а затем в том же соединении сделан запрос от другого UID, то MPM-ITK просто закроет соединение. Это совершенно законно в соответствии с RFC 2616 раздел 8.1.4, и все основные клиенты, кажется, хорошо справляются с этим, веб-сервер просто имитирует тайм-аут, а клиент просто открывает новое соединение и повторяет запрос. Тем не менее, возможно небольшое падение производительности, а следовательно, вы должны избегать включения контента из различных uids на одной и той же странице.
Обратите внимание, что MPM-ITK пока нигде не так испытывался, как, скажем, PreFork, но в тоже время начинает использоваться на некоторых сайтах в мире, как любительских так и коммерческих, которые обрабатывают по
10 миллионов хитов в день.
FastCGI vs MPM-ITK
Рекомендуемый контент
А тут же ж мог быть рекомендуемый контент от гугла 🙂 Для отображения рекомендуемого контента необходимо в браузере разрешить выполнение JavaScript скриптов, включая скрипты с доменов googlesyndication.com и doubleclick.net
Вы не любите рекламу!? Напрасно!:) На нашем сайте она вовсе ненавязчивая, а потому для нашего сайта можете полностью отключить AdBlock (uBlock/uBlock Origin/NoScript) и прочие блокировщики рекламы! AdBlock/uBlock может препятствовать нормальной работе системы поиска по сайту, отображению рекомендуемого контента и прочих сервисов Google. Рекомендуем полностью отключить блокировщик рекламы и скриптов, а также разрешить фреймы (aka iframe).
Оптимизация производительности apache2
Многие используют apache2 в качестве веб-сервера. Однако мало кто задумывается об оптимизации его производительности, что прямо пропорционально сказывается на скорости загрузки страниц сайта, скорости обработки скриптов (в частности php), а также на росте нагрузки на ЦП и увеличении объёма используемой ОЗУ.
Таким образом, следующий мануал, должен помочь начинающим (и не только) пользователям.
Все нижеприведённые примеры использовались на Raspberry PI 3, Debian 9, Apache 2.4.38, PHP 7.3.
Итак, начнем.
1. Отключение неиспользуемых модулей
Первым методом является банальное отключение модулей, которые вы не используете:
Список используемых в данный момент модулей можно посмотреть командой:
Для отключения модуля используется команда:
Соответственно для включения модуля используется команда:
Обратите внимание, что при использовании a2dismod, название модуля необходимо писать без самого слова модуль.
Наиболее загружающими систему модулями (по личному опыту) являются:
Также, после отключения какого-либо модуля, я рекомендую использовать команду — apache2ctl configtest, которая проверит конфигурацию используемых сайтов и если какой-либо из отключенных модулей был для них необходим, выдаст ошибку.
2. Смена MPM(Multi-Processing Module) и использование php-fpm
По умолчанию, после установки, apache2 использует MPM Prefork (1 поток на 1 соединение), который заметно снижает производительность, но при этом улучшает стабильность и безопасность.
Но для оптимизации производительности я рекомендую использовать MPM Worker, который позволяет использовать сразу несколько потоков на одно соединение.
Для его включения используем следующие команды:
Однако при использовании Worker вы можете столкнуться с проблемой, т.к. модуль php7.3 зависит от модуля Prefork.
Для решения этой проблемы установим модуль php7.3-fpm, который будет использоваться для отработки php-скриптов:
Стоит заметить, что использование php-fpm также снизит объём используемой ОЗУ процессом apache2 и немного ускорит отработку php-скриптов.
3. Заключение
Таким образом, такими простыми действиями мы смогли оптимизировать производительность и снизить нагрузку на машину (в данном случае RPI3).
Конечно же, есть сотни других вариантов оптимизации, вроде включения сжатия (что действительно полезно, но в большинстве своём уже включено по умолчанию), изменения параметров (файлов конфигурации) MPM, отключения HostnameLookups и т.д., но в данной статье я постарался отразить именно те пункты, которые больше всего помогли мне, и надеюсь, что помогут другим.
Apache vs Nginx: практический взгляд
Введение
Apache и Nginx — 2 самых широко распространенных веб-сервера с открытым исходным кодом в мире. Вместе они обслуживают более 50% трафика во всем интернете. Оба решения способны работать с разнообразными рабочими нагрузками и взаимодействовать с другими приложениями для реализации полного веб-стека.
Несмотря на то, что у Apache и Nginx много схожих качеств, их нельзя рассматривать как полностью взаимозаменямые решения. Каждый из них имеет собственные преимущества и важно понимать какой веб-сервер выбрать в какой ситуации. В этой статье описано то, как каждый из этих веб-серверов ведет себя при различных условиях.
Общий обзор
Прежде чем погрузиться в различия между Apache и Nginx давайте бегло взглянем на предысторию каждого из этих проектов.
Apache
Apache HTTP Server был разработан Робертом Маккулом в 1995 году, а с 1999 года разрабатывается под управлением Apache Software Foundation — фонда развития программного обеспечения Apache. Так как HTTP сервер это первый и самый популярный проект фонда его обычно называют просто Apache.
Веб-север Apache был самым популярным веб-сервером в интернете с 1996 года. Благодаря его популярности у Apache сильная документация и интеграция со сторонним софтом.
Администраторы часто выбирают Apache из-за его гибкости, мощности и широкой распространенности. Он может быть расширен с помощью системы динамически загружаемых модулей и исполнять программы на большом количестве интерпретируемых языков программирования без использования внешнего программного обеспечения.
Nginx
В 2002 году Игорь Сысоев начал работу над Nginx для того чтобы решить проблему C10K — требование к ПО работать с 10 тысячами одновременных соединений. Первый публичный релиз был выпущен в 2004 году, поставленная цель была достигнута благодаря асинхронной event-driven архитектуре.
Nginx начал набирать популярность с момента релиза благодаря своей легковесности (light-weight resource utilization) и возможности легко масштабироваться на минимальном железе. Nginx превосходен при отдаче статического контента и спроектирован так, чтобы передавать динамические запросы другому ПО предназначенному для их обработки.
Администраторы часто выбирают Nginx из-за его эффективного потребления ресурсов и отзывчивости под нагрузкой, а также из-за возможности использовать его и как веб-сервер, и как прокси.
Архитектура обработки соединений
Одно из самых существенных отличий между Apache и Nginx состоит в том как они обрабатывают соединения и отвечают на различные виды трафика.
Apache
Apache предоставляет несколько модулей мультипроцессинга (multi-processing modules, MPM), которые отвечают за то как запрос клиента будет обработан. Это позволет администраторам определять политику обработки соединений. Ниже представлен список MPM-модулей Apache:
Nginx
Nginx появился на сцене позднее Apache, по этой причине, его разработчик был лучше осведомлен о проблемах конкурентности, с которыми сталкиваются сайты при масштабировании. Благодаря этим знаниям Nginx изначально был спроектирован на базе асинхронных неблокирующих event-driven алгоритмов.
Nginx создает процессы-воркеры каждый из которых может обслуживать тысячи соединений. Воркеры достигают такого результата благодаря механизму основанному на быстром цикле, в котором проверяются и обрабатываются события. Отделение основной работы от обработки соединений позволяет каждому воркеру заниматься своей работой и отвлекаться на обработку соединений только тогда когда произошло новое событие.
Каждое соединение, обрабатываемое воркером, помещается в event loop вместе с другими соединениями. В этом цикле события обрабатываются асинхронно, позволяя обрабатывать задачи в неблокирующей манере. Когда соединение закрывается оно удаляется из цикла.
Этот подход к обработке соединений позволяет Nginx’у невероятно масштабироваться при ограниченных ресурсах. Поскольку сервер однопоточный и он не создает процессы под каждое соединение, использование памяти и CPU относительно равномерно, даже при высоких нагрузках.
Статический и динамический контент
Если рассматривать жизненные примеры, то основные различия между Apache и Nginx в том как они обрабатывают запросы к статическому и динамическому контенту.
Apache
Apache может раздавать статический контент используя стандартные file-based методы. Производительность таких операций зависит от выбранного MPM.
Apache также может раздавать динамический контент встраивая интерпретатор нужного языка в каждого воркера. Это позволяет обрабатывать запросы к динамическому содержимому средствами самого веб-сервера и не полагаться на внешние компоненты. Интерпретаторы языков могут быть подключены к Apache с помощью динамически загружаемых модулей.
Возможность обрабатывать динамический контент средствами самого Apache упрощает конфигурирование. Нет необходимости настраивать взаимодействие с дополнительным софтом, динамический модуль может быть легко отключен в случае изменившихся требований.
Nginx
Nginx не имеет возможности самостоятельно обрабатывать запросы к динамическому контенту. Для обработки запросов к PHP или другому динамическому контенту Nginx должен передать запрос внешнему процессору для исполнения, подождать пока ответ будет сгенерирован и получить его. Затем результат может быть отправлен клиенту.
Для администраторов это означает, что нужно настроить взаимодействие Nginx с таким процессором используя один из протоколов, который известен Nginx’у (http, FastCGI, SCGI, uWSGI, memcache). Это может немного усложнить процесс настройки, в особенности когда вы будете пытаться предугадать какое число соединений разрешить, так как будет использоваться дополнительное соединение с процессором на каждый пользовательский запрос.
Однако, этот метод имеет и свои преимущества. Так как интерпретатор не встроен в каждого воркера, то оверхед, связанный с этим, будет иметь место только при запросах к динамическому контенту. Статический контент будет возвращен клиенту простым способом и запросы к интерпретатору будут выполняться только тогда когда они нужны. Apache тоже может работать в такой манере, но тогда это лишит его всех преимуществ описанных в предыдущем разделе.
Распределенная конфигурация против централизованной
Для администраторов одним из очевидных отличий этих двух веб-серверов является наличие у Apache возможности задавать конфигурацию на уровне директории.
Apache
Это дает простой способ таким приложениям как системы управления контентом (CMS) конфигурировать собственное окружение не имея доступа к конфигурационному файлу веб-сервера. Это также может быть использовано шаред хостингами, чтобы сохранить контроль над основным конфигурационным файлом и дать клиентам контроль над конфигурацией определенных директорий.
Nginx
Так как Nginx не позволяет переопределять конфиги на уровне директорий, он может обрабатывать запросы быстрее, ведь ему достаточно сделать один directory lookup и прочитать один конфигурационный файл на каждый запрос (предполагается, что файл найден там где он должен быть по соглашению).
Второе преимущество связано с безопасностью. Распределенная конфигурация на уровне директорий в Apache возлагает ответственность за безопасность на обычных пользователей, которые вряд ли способны решить эту задачу качественно. То что администратор контролирует весь сервер предотвращает ошибки безопасности, которые могут возникнуть если дать пользователям доступ к конфигурации.
Интерпретация базирующаяся на файлах и URI
То как веб-сервер интерпретирует запрос и сопоставляет его с ресурсом в системе это еще одна отличительная особенность в этих двух серверах.
Apache
Так как Apache изначально был спроектирован как веб-сервер, он по умолчанию интерпретирует запросы как ресурсы в файловой системе. Он берет document root веб-сервера и дополняет его частью запроса, которая следует за именем хоста и номером порта, чтобы найти запрашиваемый файл. В общем случае, иерархия файловой системы представленная в вебе доступна как дерево документов.
Apache предоставляет ряд альтернатив на случай когда запрос не соответствует файлу в файловой системе. Использование блоков это метод работы с URI без отображения на файловую систему. Также возможно использовать регулярные выражения, которые позволяют задать более гибкие настройки для всей файловой системы.
Nginx
Nginx создан, чтобы работать и в качестве веб-сервера, и в качестве прокси-сервера. По этой причине он работает в первую очередь с URI, транслируя их при необходимости в запросы к файловой системе.
В случае запросов к статическим файлам все запросы должны быть отображены (mapped) на путь в файловой системе. Сначала Nginx выбирает блоки server и location, которые будут использованы для обработки запроса и затем объединяет document root с URI, в соответствии с конфигурацией.
Модули
И Apache, и Nginx могут быть расширены при помощи системы модулей, но способы реализации модульной системы принципиально отличаются.
Apache
Система модулей Apache позволяет динамически загружать и выгружать модули, чтобы удовлетворить ваши потребности, в то время как ваш сервер запущен. Ядро Apache всегда доступно, в то время как модули можно включать и выключать, чтобы добавить или удалить функциональность из основного сервера.
Apache использует эту функциональность для решения широкого круга задач. Благодаря зрелости платформы существует огромное множество модулей, которые могут изменять ключевые особенности сервера, например модуль mod_php позволяет включать PHP-интерпретатор в кажого воркера.
Использование модулей не ограничивается лишь обработкой динамических запросов. Среди других возможностей модулей: изменение URL’ов (URL rewrite), аутентификация клиентов, защита сервера, логгирование, кеширование, сжатие, проксирование, ограничение частоты запросов, шифрование. Динамические модули могут значительно расширить функцональность ядра.
Nginx
Nginx тоже имеет систему модулей, но она сильно отличается от подхода используемого в Apache. В Nginx модули загружаются не динамически, а должны быть выбраны и скомпилированы с ядром сервера.
Для многих пользователей по этой причине Nginx кажется менее гибким. Это особенно относится к пользователям, кто имеет мало опыта ручной сборки приложений и предпочитают использовать системы управления пакетами. Обычно разработчики дистрибутивов стремятся создать пакеты для всех часто используемых модулей, но если вам нужен какой-то нестандартный модуль вам придется собрать его из исходников самостоятельно.
Тем не менее, модули в Nginx очень полезны и востребованы, вы можете определить чего вы хотите от сервера и включить только те модули, что вам нужны. Некоторые пользователи считают такой подход более безопасным так как произвольные модули не могут быть подключены к серверу.
Модули Nginx реализуют те же возможности, что и модули Apache: проксирование, сжатие данных, ограничение частоты запросов, логгирование, модификация URL’ов, гео-локация, аутентификация, шифрование, потоковое вещание, почтовые функции.
Поддержка, совместимость, экосистема и документация
В процессе использования приложения важными являются экосистема созданная вокруг него и возможность получения поддержки.
Apache
Так как Apache пользуется популярностью такое длительное время с поддержкой у него нет проблем. Легко можно найти большое количество документации как от разработчиков Apache, так и от сторонних авторов. Эта документация покрывает все возможные сценарии использования Apache, включая взаимодействие с другими приложениями.
Существует много инструментов и веб-проектов идущих в комплекте со средствами запуска самих себя из под Apache. Это относится как к самим проектам, так и к системам управления пакетами.
Nginx
Nginx обычно используется там, где предъявляются повышенные требования к производительности и в некоторых областях он все еще является догоняющим.
В прошлом было сложно найти вменяемую поддержку по этому веб-серверу на английском языке, так как на ранних этапах разработка и документация велись на русском языке. Вместе с ростом интереса к проекту документация была переведена на английский и теперь можно найти достаточное количество документации и от разработчиков веб-сервера, и от сторонних авторов.
Разработчики стороннего ПО также начинают поддерживать работу с Nginx и некоторые из них уже предлагают на выбор пользователя конфиги для работы или с Apache, или с Nginx. И даже без поддержки приложением работы с Nginx не составляет большого труда написать свой конфиг для интеграции приложения с Nginx.
Совместное использование Apache и Nginx
После того как вы ознакомились с плюсами и минусами Apache и Nginx у вас должно появиться представление того, какой из серверов больше подходит под ваши задачи. Однако, можно достигнуть лучших результатов используя оба сервера вместе.
Распространенной схемой использования является размещение Nginx перед Apache в качестве реверс-прокси. В такой конфигурации Nginx называют фронтендом, а Apache — бэкендом. При таком подходе Nginx будет обслуживать все входящие запросы клиентов и мы получим выигрыш из-за его возможности обрабатывать множество конкурентных запросов.
Nginx будет самостоятельно обслуживать статический контент, а для динамического контента, например для запросов к PHP-страницам, будет передавать запрос к Apache, который будет рендерить страницу, возвращать ее Nginx’у, а тот в свою очередь будет передавать ее пользователю.
Такая конфигурация очень популярна, Nginx используется в ней для сортировки запросов. Он обрабатывает сам те запросы которые может и передает Apache только запросы, которые не может обслужить сам, снижая таким образом нагрузку на Apache.
Эта конфигурация позволяет горизонтально масштабировать приложение: вы можете установить несколько бэкенд серверов за одним фронтендом и Nginx будет распределять нагрузку между ними, увеличивая тем самым отказоустойчивость приложения.
Заключение
Как вы можете видеть и Apache, и Nginx — это мощные, гибкие и функциональные инструменты. Для того чтобы выбрать сервер под ваши задачи необходимо определиться с требованиями к нему и провести тесты на всех возможных паттернах использования вашего приложения.
Между этими проектами есть значительные различия, которые могут оказать влияние на производительность, возможности и время реализации необходимое для внедрения и запуска каждого из решений. Выбор является серией компромиссов и не стоит пренебрегать тестами. В конечном итоге, не существует одного универсального веб-сервера под все возможные задачи, поэтому важно найти решение максимально соответствующее вашем задачам и целям.
Настроить apache по взрослому, да и вообще о хостинге
1. В репозитории, кроме метапакета apache2 имеются apache2-mpm-event, apache2-mpm-prefork и apache2-mpm-worker. При установке метапакета устанавливается apache2-mpm-prefork. Для чего нужны остальные?
3. В продолжении вопроса про кулхацкера. Как сделать, чтобы для виртуального хоста была доступны директория /var/www/мойкрутойсайт.ru и /var/www/мойкрутойсайт.ru/docs, но не было даже намёков на доступ к другим поддиректориям /var/www/мойкрутойсайт.ru? Как сделать, чтобы вместо вебстраницы отображался список файлов, с оригинальными картинками для каждого типа файла? Как сделать наоборот, чтобы ни каким образом клиент не мог узнать какие файлы имеются на хосте?
4. Некоторые php-движки существуют в виде deb-пакетов, в репозитории были обнаружены mediawiki и drupal6. При установке файлы скрипта оказываются в /usr/share/drupal6. Что дальше с этим делать: делать /usr/share/drupal6 корнем виртуального хоста или создавать симплинк в /var/www/мойкрутойсайт.ru? В пакете ещё есть какая-то хрень в /etc/drupal. Зачем нужен этот огород? Или лучше не обращать внимание на существование таких пакетов и ставить php-движки обычным способом: скачиванием и распаковкой?
1. разные мпм (мультипроцессные обработчики). от MPM зависит эффективность работы. для хостинга самый предпочтительный вариант mpm-itk, т.к дает возможность апачевским child-ам работать от указанного UIDа.
что следует поменять, чтобы сервер не был тормозным и чтобы меня никакой кулхацкер не мог сломать?
Как сделать, чтобы для виртуального хоста была доступны директория. но не было даже намёков на доступ к другим поддиректориям
правильно выставить права доступа
Как сделать, чтобы вместо вебстраницы отображался список файлов, с оригинальными картинками для каждого типа файла? Как сделать наоборот, чтобы ни каким образом клиент не мог узнать какие файлы имеются на хосте?
Что дальше с этим делать: делать /usr/share/drupal6 корнем виртуального хоста или создавать симплинк в /var/www/мойкрутойсайт.ru?
Чтобы настроить apache по-взрослому, надо внимательно читать документацию и иметь какой-никакой опыт, чтобы результат этого чтения применять на практике.
У вас отсутствует и то и другое. Т.е. вы не читали документацию и опыта у вас нет. Значит ставьте apache как попало, запускайте то, что вам нужно, нарабатывайте опыт. Потом, когда опыт придет, вопросы типа «чтобы сервер не был тормозным и чтобы меня никакой кулхацкер не мог сломать» отпадут сами собой.
>1. В репозитории, кроме метапакета apache2 имеются apache2-mpm-event, apache2-mpm-prefork и apache2-mpm-worker. При установке метапакета устанавливается apache2-mpm-prefork. Для чего нужны остальные?
Это разные вещи. Например, mpm-worker использует треды, а не форки, для работы. Это, в общем случае, улучшает производительность, но не все модули thread-safe. Например mod_php не thread-safe. Глобально, надёжно.
Впрочем, нужность воркера уже не та, так как быстрые сервера есть и вне апача (lighttpd, nginx), а mod_php всё равно работает нормально только на префорке.
Про itk сказали выше. От себя скажу, что для своего хостинга он, в общем-то, не всегда нужен. Мы, например, запускаем разные FastCGI процессы под разными юзерами, и этого хватает.
У кого есть нормальный русскоязычный справочник по директивам apache2?
В продолжении вопроса про кулхацкера. Как сделать, чтобы для виртуального хоста была доступны директория /var/www/мойкрутойсайт.ru и /var/www/мойкрутойсайт.ru/docs, но не было даже намёков на доступ к другим поддиректориям /var/www/мойкрутойсайт.ru?
Смотреть на document root, всякие там directory и location в конфиге. В документации всё описано, там просто и логично.
Что дальше с этим делать: делать /usr/share/drupal6 корнем виртуального хоста или создавать симплинк в /var/www/мойкрутойсайт.ru?
Вопрос вкуса. Симлинк лучше, можно потом поменять содержимое, не трогая конфиг. В любом случае надо понимать, что некоторым приложениям нужны права на запись, поэтому просто так в /usr/. ссылаться нельзя.
Опять же, можно в хоме для юзеров класть например всё это.
В пакете ещё есть какая-то хрень в /etc/drupal
Или лучше не обращать внимание на существование таких пакетов и ставить php-движки обычным способом: скачиванием и распаковкой?
Мало пользы от этой страницы. И дело не в том, что «Краткий справочник по директивам» на английском, при желании всё прочитать и разобрать можно, а дело в том что отсутствуют примеры и пояснения почему оптимально именно так.
Смотреть на document root, всякие там directory и location в конфиге. В документации всё описано, там просто и логично.
Такая запись проканает:
> отсутствуют примеры и пояснения почему оптимально именно так
оптимально для чего или для кого?
для разных случаев оптимальные настройки могут кардинально отличаться.
сайт в /var/www/iskatel.dyndns.info работать будет.
для разных случаев оптимальные настройки могут кардинально отличаться.
Тогда наверное мне следует описать мой конкретный случай.
появилась уязвимость, а тебе надо только aptitude дёрнуть и всё починится.
Зачем городить сайты для 2х (wtorrent/phpmyadmin) скриптов? Поднимите ssl вариант сайта №1, положите их в диру на ssl версии сайта №1 и защитите ее паролем, который будете знать только вы.
могу лишь посоветовать для wtorrent и phpmyadmin увеличить memory_limit и max_execution_time. mpm-itk нужен только если работает mod_php, что подозреваю у тебя и будет.
>>появилась уязвимость, а тебе надо только aptitude дёрнуть и всё починится.
изменяя ядро Drupal, ты убиваешь котенка.
если не лезть куда не попадя — ничего не сломается.
> изменяя ядро Drupal, ты убиваешь котенка.
страшно подумать сколько котят убивает комьюнити друпал.
б-же, у них все руки в крови!
Странное название темы. Как для трех виртуалхостов домашнего назначения.
изменяя ядро Drupal, ты убиваешь котенка.
Кроме drupal есть и другие продукты. И неизменность ядра drupal никак не гарантирует 100% корректную работу после обновления.
если не лезть куда не попадя — ничего не сломается.
Это, мягко говоря, неправда. Примеров из жизни сколько угодно. Бездумное обновление всего подряд приводит к тому, что все перестает работать.
вот уже почти два года «бездумно обновляю» несколько сайтов на 6-м друпале. ничего не перестало работать. ЧЯДНТ?
Кроме drupal есть и другие продукты.
ТС говорил о нем (и о медиавики, который тоже прекрасно обновляется).
ТС говорил о нем (и о медиавики, который тоже прекрасно обновляется).
ТС вообще не понимает о чем говорит, поэтому ему надо знать, что бездумно делать что-либо в т.ч. обновлять _разное_ по не следует.
так кто бездумно обновится? drupal или php? вы уж определитесь.
в пределах одного релиза дебиана _внезапно_ не обновится php с 5.2 на 5.3, и drupal не станет вдруг седьмым из шестого. а до того времени формат ввода-вывода функций не изменится.
так кто бездумно обновится? drupal или php? вы уж определитесь.
Научитесь читать цитаты, на которые отвечаете.
«Бездумное обновление всего подряд приводит к тому..»
_внезапно_ не обновится php с 5.2 на 5.3,
Внезапно с 5.2 на 5.3 совершенно не обязательно. И drupal’у вашему вовсе не обязательно становится 7м, чтобы что-нибудь сломалось после обновления.
короче. все понятно. толстота превышает разумные пределы.
предлагаю отправиться. небездумно обновлять свой LFS.
ТС говорил о нем (и о медиавики, который тоже прекрасно обновляется).
Снести нафиг и поставить по-человечески официальную версию
думаю, прежде чем задаваться такими вопросами, не мешает узнать устройство дебиановской системы конфигов, почему так разложено по разным каталогам и файлам. очевидно же, в /etc/apache2/httpd.conf записываются те пользовательские директивы, которые не должны перезаписаться при обновлении apache ( и соответственно основного apache2.conf); в mods-available и sites-available записываются конфиги, относящиеся к доступным модулям и сайтам, конфиги которые активируюся командами a2enmod и a2ensite соответственно. в mods-enabled и sites-enabled названные команды создают симлинки. это все, конечно же, можно делать и руками, но зачем?
У меня сайт, находящийся на моём собственном сервере грузится за тоже время, что и сайты из Интернета. Разве это нормально?
нет, не нормально, но причина этого точно не в раскладках конфигов апача.
для начала почитать, как вообще друпал устроен. ох, не зря люди по нему (а иногда даже по его отдельным модулям) толстенные книжки пишут.
надо знать, что в друпале сайты (друпал поддерживает мультисайтинг) максимально отделены от основного движка. если скачать официальную версию, то можно обнаружить внутри с десяток каталогов. так вот, что-то править и что-то писать можно только в одном: в каталоге sites. туда кладутся все модули, темы и библиотеки сайтов. там же лежат и конфиги сайтов. если пользователь что-то поправит в каталоге include, к примеру, то отгребет неприятностей при следующем обновлении гарантировано.
соответственно, мейнтейнеры дебиана справедливо рассудили, что то, что доступно пользователю — кладем в /etc/drupal6/, что ему не подвластно — в /usr/share/drupal6
в общем случае, если принять что сайт на друпале на серваке у нас один, создаем в каталоге /etc/drupal/6 еще три директории: modules, themes, libraries и кладем в них соответствующее наполнение. если же нужно изменить что-то в файлах ядра, ручками своими погаными в /usr/share/drupal6 не лезем, а аккуратненько создаем новый модуль, в котором при помощи хуков ядра изменяем функции API.
фатально вредно не обновление без особых заморочек (если, конечно, это не gentoo), вредно бездумное изменение конфигов и структуры. если кто-то так сделал конфиги, значит так нужно.
У меня сайт, находящийся на моём собственном сервере грузится за тоже время, что и сайты из Интернета. Разве это нормально?
от многих факторов зависит. может тормозить само отображение в браузере а не сервер. протестируй время генерации страницы, для друпала готовые скрипты есть.
> то, что доступно пользователю — кладем в /etc/drupal6/
root-у разве что. пользователям писать в /etc глупо и вредно. даже если это /etc/drupal.
>root-у разве что. пользователям писать в /etc глупо и вредно. даже если это /etc/drupal
ну имеется в виду человеку, администратору. не машине
Да кстати, вы уж определитесь где сайты правильнее всего держать: ну то что не в /usr это понятно? А вот в /var или в /home?
>имхо правильнее всего не доверять установку веб-движков пакетменеджеру.
почему, если ядро движка все равно не доступно для записи пользователя?
веб-движок должен ставиться в /home/hostingusers/userXXX/www/
и отдать ему на откуп обновление дыр движка? если предлагать именно drupal-хостинг, то ему достаточно оставить возможность писать в /home/hostingusers/userXXX/drupalsite, то есть только в ту часть движка, которая нужна только ему, его модулям, темам и библиотекам. при этом можно у него забрать даже обновление «обязательных» модулей, вроде views, cck и token, установив их в /etc/drupal/6/sites/default/
права на запись и чтение этой директории должны быть только у userXXX,
проверю как-нить на досуге, можно ли мультисайтинговую схему реализовать через mpm-itk. по идее вроде можно.
>А вот в /var или в /home?
все юзерозависимое в /home. в /var/www должна лежать только дефолтная заглушка без всяких движков и проч.
это только в идиотском дебилиане подобное.
а ТС сперва документацию читать и аглицкий изучать