В настоящее время у меня есть четыре блога, в которых используется Wordpress, запущенный в компании общего хостинга. У этих блогов много посещений, и я постоянно получаю предупреждения от хостинговой компании о том, что я использую слишком много ЦП сервера.
Учитывая тот факт, что у меня есть выделенный сервер в другой компании с большим количеством простаивающих ресурсов (он имеет четырехъядерный процессор Xeon 2,5 ГГц и 8 ГБ оперативной памяти и работает на Win2008), я планирую переместить блоги на этот сервер, чтобы иметь немного больше свободы. В настоящее время я использую этот сервер для размещения некоторых веб-приложений с использованием ASP.Net и SQL Express.
Я установил блог для тестирования, и он работал нормально, но возникли некоторые проблемы и возникли некоторые вопросы в моей голове:
Я знаю, что некоторые люди посоветуют мне не запускать Wordpress в стеке Windows, но это мой единственный выбор. Я даже не знаю, как начать управлять стеком LAMP, у меня нет на это ни времени, ни денег на аренду другого сервера.
Как насчет ответов:
Я использую Wordpress на мой сервер IIS какое-то время без проблем. Напишите мне, если у вас возникнут дополнительные вопросы.
Исходное содержание сообщения в блоге (получено из http://web.archive.org/web/20100326200206/http://www.dscoduc.com/2009/11/acl-settings-for-wordpress-on-iis 2014/11/10):
Настройки ACL для WordPress на IIS
После получения блога WordPress я хотел убедиться, что списки управления доступом к файлам настроены правильно. Этот процесс немного отличается от настройки BlogEngine.NET, поскольку WordPress работает с олицетворением вместо отдельной учетной записи службы и анонимной учетной записи.
К сожалению, это усложнилось. Я обновил свой веб-сервер, чтобы использовать Windows 2008 R2, в которой установлена последняя версия IIS, версия 7.0. Улучшения IIS 7.0 включают фундаментальное изменение способа управления удостоверениями. В частности, IIS 7.0 использует две специальные учетные записи, которых не было в предыдущих версиях IIS: IUSR и IIS_IUSRS.
Более подробную информацию об этих специальных учетных записях можно найти на сайте IIS.NET в статье под названием Общие сведения о встроенных учетных записях пользователей и групп в IIS 7.0.
Таким образом, целью было настроить минимальный уровень доступа, необходимый для ведения блога. Чтобы помочь в этом, я провел время с Монитор процессов Sysinternals следить за сообщениями ЗАПРЕЩЕН В ДОСТУПЕ, пока я просматривал блог и выполнял административные задачи.
Я начал с удаления наследуемых разрешений в корневой папке. Затем я удалил все учетные записи, кроме двух основных учетных записей, необходимых для управления папкой: SYSTEM и Administrators. Затем я предоставил разрешения READ и LIST_FOLDER для IUSR и IIS_IUSR в корневой папке. Если унаследованные разрешения включены по умолчанию для вложенных папок, этот ACL будет распространяться вниз по дереву папок.
Если бы я остановился здесь, я бы смог обслуживать контент, но не смог бы изменять плагины и загружать сообщения с вложениями. Я хотел, чтобы все функции блога работали, поэтому я изменил разрешения для папки wp-content, добавив доступ MODIFY для учетной записи IUSR, который предоставляет доступ MODIFY и WRITE.
После последней настройки ACL я проверил блог и обнаружил, что все работает правильно. После того, как все было сказано и сделано, мне нужно было настроить ACL только в двух местах: в корне и в папке wp-content:
ОБНОВИТЬ: После того, как я написал этот пост, я решил удалить доступ на запись к папке / wp-content, за исключением случаев, когда мне нужно было обновить подключаемый модуль. Кроме того, мне нужно было предоставить доступ на запись к папке / wp-content / uploads, чтобы поддерживать сообщения в блоге с вложениями и изображениями.
Я также обнаружил, что дополнительные разрешения на запись необходимы на корневом уровне всякий раз, когда я хотел выполнить автоматическое обновление основных файлов WordPress, что я также могу предоставить вручную, когда требуется обновление.
В конце концов, единственные права, оставленные для учетной записи IUSR, - это разрешения на чтение / список для корня веб-сайта (который наследуется через папки сайта) и разрешение на чтение / список / запись в папке загрузок.