На электронных страницах хабра уже есть в достаточном количестве статей как по настройке вэб-сервера Nginx, так и связки его с различными CMS. Этой статьей хочу внести небольшую лепту примером настройки связки Nginx + WolfCMS. Помимо самой CMS будет уделено немного внимания настройкам nginx, php-fpm с уклоном в безопасность — по частым вопросам с тостера про то как обезопасить свой сайт.
Подробности об этом и немногом другом под катом.
WolfCMS написана на языке программирования php — это система управления содержанием в своё время выросшая из FrogCMS и имеющая дальнего родственника FlexoCMS.
Можно даже сказать, что это не система управления контентом по типу WordPress, MaxSite, Joomla и т. п. И не php-framework типа Yii, Laravel или Kohana. WolfCMS занимает промежуточную нишу между этими крайними точками. С одной стороны есть админка, с другой стороны всё нужно писать самому на php.
Административная панель Wolf CMS довольно проста и заточена под программиста, которая нужна для создания сайта и редкой корректировки контента.
Ядро данной CMS минималистично. Оно написано таким образом, что позволяет лишь собрать в единое целое части php и html кода, хранящегося в базе. При этом весь код доступен для прямого редактирования, то есть программист практически не ограничен в творчестве. Поэтому приделать свой функционал можно довольно просто. Тут даже шаблонизатора нет.
Получается CMS, которая выполняет те функции, которые обычно просто лень писать самому: поддержку регистрации и распределения прав пользователей, навороченную админку, взаимодействие с базой и т.п. При этом весь основной код сайта тем или иным способом виден прямо в панели администрирования. И когда просыпается «полет фантазии», можно править исходники прямо на сайте, а когда обуревает лень с хандрой и не хочется заморачиваться с программированием, то и такая возможность администрирования имеется. Помимо этого WolfCMS поддерживает работу с многими HTTP-серверами и базами данных.
С целью обезопасить систему от возможных неприятностей со стороны web-сервера nginx, так и сам web-сервер от системы, решено выделить отдельный раздел на диске (/www) и заодно задать на него права монтирования, чтобы поднять безопасность и немного поднять быстродействие. Вот такой в моём случае получилась строка с опциями монтирования раздела /www:
Чтобы иметь под рукой обновления, подключаю репозиторий nginx, обновляюсь и устанавливаю оного:
Чтобы подружить WolfCMS с nginx нужно содержимое файла .htaccess, а именно content (rewrite rules):
переконвертировать в правила для nginx. Для этих целей воспользовался конвертером сайта www.anilcetin.com. На выходе получил следующие правила:
которые добавил в файл server.conf
Задам профиль latency-performance (по умолчанию balanced):
С целью усиления сетевого стека в файл /etc/sysctl.conf добавлены следующие строчки:
Применение изменений:
Теперь надо создать каталоги на выделенной директории для файлов сайта:
И задать права доступа к ним:
Проверка правильности настроек nginx:
Прошло всё нормально, пришло время запускать сервер и добавить в автозапуск:
Свежатина php была замечена в обильных количествах в репозитории remi. Поэтому его неплохо было бы подключить и использовать в дальнейшем для обновления и возможного даже пополнения:
В самом файле надо навести немного настроек, чтобы был доступ к пакетам версии php-5.6. Для этого надо включить секцию [remi-php56].
Теперь можно устанавливать php-fpm:
Файл /etc/php-fpm.d/www.conf практически без изменений, только из всяческих (скучкованности в одном месте с файлами nginx-а, безопасности) соображений были перенесены каталоги временных файлов в раздел /www:
Файл /etc/php-fpm.conf без изменений.
На сервере для нужд не только самого сайта используется php, чтобы от него меньше было вреда в конфигурационный файл /etc/php.ini были привнесены следующие изменения:
Чтобы побороть один недугъ в файле /etc/php.ini изменена следующая строка к виду:
Старт и автозапуск:
Часто приходится читать, иногда слышать, что первым делом после установки надо обязательно выключать, а лучше сносить (если умеешь) ненавистный и мешающий всему SELinux. Давайте не будем кривить душой, парни из АНБ свою работу знают и делают хорошо. И что бы там не говорили про сильно хитро завуалированные закладки, пока ещё не встречал сообщений, что SELinux попался на наушничестве. К тому же исходники открыты да доступны для изучения.
Теперь вместо лирики. Для работы с контекстом SELinux нужна утилита semanage из пакета policycoreutils-python:
Какие есть в системе готовые политики для nginx, php и есть ли они вообще?
Ну, то есть валом. Ничего своего писать не надо будет. Можно взять готовое и переиначить на свой манер. Т. е. поменять файловый контекст применительно для нового варианта размещения файлов сайта по месту /www/nginx.
Ну и разрешить подключение к СУБД и к сети:
Есть ли какие-нибудь замечания?
Ничего особенного и тем более не имеющее отношение к данной установке.
Файл с актуальной версией CMS скачан и распакован в коревой директории будущего сайта /www/nginx/vist.
Теперь можно приступать к установке. В браузере заветный адресок.
Всё нормально? Тогда Continue to install.
Для случая с PostgreSQL поле «Table prefix» либо не трогать и оставить как есть, либо указать что-то своё, но не оставлять пустым. Иначе во время установки будут проблемы с заполнением базы данных.
Поскольку будем использовать http-сервер ngix, птичку с поля «Use clean URLs» надо убрать.
Можно запускать «Install now!».
Всё прошло нормально, можно записать временный пароль (он пригодится чуть позже) и перейти настройкам безопасности после установки.
Вот тут нам подробно рассказывают, что у нас есть опасного и как это побороть.
Но прежде чем к этому приступать, надо внести небольшие правки в файл /www/nginx/vist/config.php, чтобы CMS корректно работала с web-сервером nginx.
Для этого строки:
Привести к виду:
Теперь можно безопасить:
Установка закончена. Можно заходить и настраивать.
Панель администрирования находится по адресу example-test.org/admin. Для входа надо заполнить форму: указать свой логин и пароль, который был сгенерирован на этапе установки.
Первый вход выполняется на английской языке (по умолчанию), в настройках можно выбрать иной язык панели администрирования. Русский поддерживается.
Панель администрирования условно можно разделить на несколько частей: меню пользователя, основное меню с вкладками (табами), основной частью страницы и в самом низу страницы ссылки ведущие на форум и документацию по CMS.
Вкладка Страница (Page) может представлять собой статью, новость или заметку. Текст статьи может быть простым набором слов, либо кодом php или html. Так же у страниц есть ещё дополнительные поля метаданных: «Ключевые слова» (keywords) и «Описание» (descritpion) для SEO оптимизации, помимо этого на вкладке «Настройки» можно задавать внешний вид, права доступа, время публикации и т. д.
Вкладка Фрагмент (Snippet) — небольшая часть контента на php или html, которая может быть включена в другие страницы или макеты. Изначально в виде отдельных макетов выделены блоки header и footer, в качестве фрагмента могут быть небольшие блоки информации: рекламный блок, список последних статей в блоге.
Вкладка Макет (Layout) используется для придания внешнего вида странице. Здесь могут быть специальные тэги для включения определённого содержания страницы и другие элементы, такие как колонтитулы, подключаются css-файлы, прописывается код, требуемый стандартами. При этом в определённых местах вместо реального контента будут вставлены определённые функции самой WolfCMS. Поэтому макет выглядит как html-код стандартного сайта, но при этом короче и легко читаем за счёт замены основных блоков на функции CMS с понятными именами. Можно создавать макеты, которые могут быть применены к разным разделам сайта и даже к разным страницам.
Сами макеты делаются на чистом html+css+js со вставками на php. Понятное дело, что шаблонизатор отсутствует. Это с одной стороны улучшает производительность, но как следствие усложняется разработка. Поэтому уверенное знание php крайне желательно. Хотя есть в природе примеры кода, которые можно подсмотреть и адаптировать их под себя.
Перейдём на вкладку «Users» и сменим установочный пароль на свой секретный.
Вкладка «Администрирование» с перечнем плагинов.
Плагины — это подпрограммы на php, срабатывающие при наступлении определённых событий в панели администрирования или на сайте и по своей сути ближе к модулям Drupal. Условно их можно разделить на четыре группы: модуль с админкой, модуль без админки, новый тип страниц, новый фильтр текста.
Плагин Новый тип страниц позволяет наделить стандартные страницы новыми функциями — привязать к ним обработчик.
Плагин Новый фильтр текста — редактор, доступный в панели администрирования. При сохранении страницы в базу записывается последний использованный фильтр, поэтому при открытии страницы для повторного редактирования, автоматически подключится последний фильтр. Есть только в этом недостаток — все активные плагины фильтры текста, подключены постоянно к странице, оставаясь невидимыми. Поэтому обработка скриптов и правил css замедляет работу панели администрирования.
Вкладка «Настройка»
Принцип создания сайтов в данной CMS следующий: в начале создаётся базовая структура сайта с визуальным размещением страниц. Затем выполняется адаптация макета. При этом можно довольно гибко настроить любой макет из чистого html, здесь особых сложностей не должно возникать. А вот с php трудности могут быть поскольку готовые модули, плагины по созданию тех же меню здесь отсутствуют. Следующим этапом в создании макета будет выделение общих кусков кода и оформление их во фрагменты, программирование логики работы сайта на php и вывод нужного функционала.
На тостере иногда задаётся вопрос какую CMS лучше заюзать для небольшого или простенького проекта, станка ЧПУ. Часто в ответах одни рекомендуют взять WordPress другие советуют Joomla, Битрикс присоветывают тоже. Потом, бывает, у них случается небольшая стычка с выяснением чья петрушка зеленее. Ну и объяснением такого выбора также обычно бывают сетования, что инфы по настройкам данных систем валом, куча готовых конфигураций и такая же куча дополнительных модулей и расширений, ещё большое коммьюнити. Только наливай, пей и не о чём не думай.
Модные ныне CMS пытаются по возможности спрятать от пользователя чистый php и html код. Может оно и в какой-то мере оправдано, когда человек впервые взялся за web-разработку, чтобы не отбивать у него охоту. В WolfCMS администратор видит практически весь код в чистом виде, который аккуратно разложен по полочкам и подписан, так же имеет глубокий доступ к системе, что позволяет ему более гибко реализовать свои задумки вплоть до изменения под себя ядра системы. Плюс к всему данная CMS не требовательна к системным ресурсам.
Подробности об этом и немногом другом под катом.
WolfCMS написана на языке программирования php — это система управления содержанием в своё время выросшая из FrogCMS и имеющая дальнего родственника FlexoCMS.
Можно даже сказать, что это не система управления контентом по типу WordPress, MaxSite, Joomla и т. п. И не php-framework типа Yii, Laravel или Kohana. WolfCMS занимает промежуточную нишу между этими крайними точками. С одной стороны есть админка, с другой стороны всё нужно писать самому на php.
Административная панель Wolf CMS довольно проста и заточена под программиста, которая нужна для создания сайта и редкой корректировки контента.
Ядро данной CMS минималистично. Оно написано таким образом, что позволяет лишь собрать в единое целое части php и html кода, хранящегося в базе. При этом весь код доступен для прямого редактирования, то есть программист практически не ограничен в творчестве. Поэтому приделать свой функционал можно довольно просто. Тут даже шаблонизатора нет.
Получается CMS, которая выполняет те функции, которые обычно просто лень писать самому: поддержку регистрации и распределения прав пользователей, навороченную админку, взаимодействие с базой и т.п. При этом весь основной код сайта тем или иным способом виден прямо в панели администрирования. И когда просыпается «полет фантазии», можно править исходники прямо на сайте, а когда обуревает лень с хандрой и не хочется заморачиваться с программированием, то и такая возможность администрирования имеется. Помимо этого WolfCMS поддерживает работу с многими HTTP-серверами и базами данных.
0. Установка и настройка web-сервера nginx
С целью обезопасить систему от возможных неприятностей со стороны web-сервера nginx, так и сам web-сервер от системы, решено выделить отдельный раздел на диске (/www) и заодно задать на него права монтирования, чтобы поднять безопасность и немного поднять быстродействие. Вот такой в моём случае получилась строка с опциями монтирования раздела /www:
/www xfs rw,nosuid,nodev,auto,nouser,async,noatime,nodiratime,logbufs=8,biosize=16,allocsize=512m,filestreams,barrier
Чтобы иметь под рукой обновления, подключаю репозиторий nginx, обновляюсь и устанавливаю оного:
rpm -ivh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm
yum clean all && yum makecache && yum update && yum install nginx -y
Содержимое файла /etc/nginx/nginx.conf
user nginx;
worker_priority -5;
worker_processes 4;
worker_rlimit_nofile 16384;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
use epoll;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
charset utf-8;
fastcgi_cache_path /www/nginx/cache/fastcgi_temp levels=1:2 keys_zone=cache:48m inactive=30m max_size=2G;
client_body_temp_path /www/nginx/cache/client_temp 1 2;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
server_tokens off;
gzip on;
gzip_static on;
gzip_comp_level 1;
gzip_min_length 1024;
gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;
gzip_disable "MSIE [1-6]\.";
keepalive_timeout 65;
reset_timedout_connection on;
limit_conn_zone $binary_remote_addr zone=addr:5m;
limit_conn_zone $server_name zone=server:5m;
# Load config files from the /etc/nginx/conf.d directory
include /etc/nginx/conf.d/server.conf;
}
Чтобы подружить WolfCMS с nginx нужно содержимое файла .htaccess, а именно content (rewrite rules):
RewriteRule ^wolf/install/index.html$ wolf/install/index.php?rewrite=1 [L,QSA]
RewriteRule ^wolf/install/index.php$ wolf/install/index.php?rewrite=1 [L,QSA]
RewriteRule ^wolf/install/$ wolf/install/index.php?rewrite=1 [L,QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^(.*)$ index.php?WOLFPAGE=$1 [L,QSA]
переконвертировать в правила для nginx. Для этих целей воспользовался конвертером сайта www.anilcetin.com. На выходе получил следующие правила:
rewrite ^/wolf/install/index.html$ /wolf/install/index.php?rewrite=1 last;
rewrite ^/wolf/install/index.php$ /wolf/install/index.php?rewrite=1 last;
rewrite ^/wolf/install/$ /wolf/install/index.php?rewrite=1 last;
rewrite ^/(.*)$ /index.php?WOLFPAGE=$1 last;
if (!-f $request_filename){
set $rule_3 1$rule_3;
}
if (!-d $request_filename){
set $rule_3 2$rule_3;
}
if ($request_filename !~ "-l"){
set $rule_3 3$rule_3;
}
if ($rule_3 = "321"){
rewrite ^/(.*)$ /index.php?WOLFPAGE=$1 last;
}
которые добавил в файл server.conf
Содержимое файла /etc/nginx/conf.d/server.conf
server {
limit_conn addr 10;
listen 80;
server_name example-test.org www.example-test.org;
client_body_timeout 36s;
client_header_timeout 36s;
keepalive_timeout 36s;
send_timeout 36s;
access_log /var/log/nginx/host.access.log;
root /www/nginx/vist;
index index.php;
fastcgi_index index.php;
location / {
try_files $uri $uri/ /index.php?WOLFPAGE=$uri&$args;
}
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /www/nginx/vist/error;
rewrite ^/(.*)$ /index.php?WOLFPAGE=$1 last;
}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
location ~ \.php$ {
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
root /www/nginx/vist;
fastcgi_pass unix:/var/run/php-fpm/phpfpm.socket;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_cache cache;
fastcgi_cache_min_uses 3;
fastcgi_cache_valid 200 301 302 304 5m;
fastcgi_cache_key "$request_method|$host|$request_uri";
}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
location ~ /\.ht {
deny all;
}
# nginx configuration for .htaccess
rewrite ^/wolf/install/index.html$ /wolf/install/index.php?rewrite=1 last;
rewrite ^/wolf/install/index.php$ /wolf/install/index.php?rewrite=1 last;
rewrite ^/wolf/install/$ /wolf/install/index.php?rewrite=1 last;
if (!-f $request_filename){
set $rule_3 1$rule_3;
}
if (!-d $request_filename){
set $rule_3 2$rule_3;
}
if ($request_filename !~ "-l"){
set $rule_3 3$rule_3;
}
if ($rule_3 = "321"){
rewrite ^/(.*)$ /index.php?WOLFPAGE=$1 last;
}
}
Задам профиль latency-performance (по умолчанию balanced):
tuned-adm profile latency-performance
С целью усиления сетевого стека в файл /etc/sysctl.conf добавлены следующие строчки:
Содержимое файла /etc/sysctl.conf
# Enable TCP SYN Cookie Protection
net.ipv4.tcp_syncookies=1
# Tune of network system
net.core.somaxconn = 1024
net.ipv4.ip_local_port_range = 8192 65535
net.ipv4.tcp_congestion_control=illinois
# This setting optimizes the TCP stack for either high throughput, or low latency
net.ipv4.tcp_low_latency=1
# Patch safe
kernel.perf_event_paranoid = 2
Применение изменений:
sysctl -p
Теперь надо создать каталоги на выделенной директории для файлов сайта:
mkdir -p /www/nginx/vist
mkdir -p /www/nginx/cache
И задать права доступа к ним:
chown -R nginx.root /www/nginx/cache/*; chmod -R 700 /www/nginx/cache/*
chown -R nginx.nginx /www/nginx/vist/*
Проверка правильности настроек nginx:
nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Прошло всё нормально, пришло время запускать сервер и добавить в автозапуск:
systemctl start nginx && systemctl enable nginx
1. Установка и настройка компонентов РНР
Свежатина php была замечена в обильных количествах в репозитории remi. Поэтому его неплохо было бы подключить и использовать в дальнейшем для обновления и возможного даже пополнения:
rpm -ivh http://rpms.famillecollet.com/enterprise/7/remi/x86_64/remi-release-7.1-3.el7.remi.noarch.rpm
В самом файле надо навести немного настроек, чтобы был доступ к пакетам версии php-5.6. Для этого надо включить секцию [remi-php56].
[remi-php56]
name=Les RPM de remi de PHP 5.6 pour Enterprise Linux 7 - $basearch
#baseurl=http://rpms.famillecollet.com/enterprise/7/php56/$basearch/
mirrorlist=http://rpms.famillecollet.com/enterprise/7/php56/mirror
# WARNING: If you enable this repository, you must also enable "remi"
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-remi
Теперь можно устанавливать php-fpm:
yum install php-fpm -y
Файл /etc/php-fpm.d/www.conf практически без изменений, только из всяческих (скучкованности в одном месте с файлами nginx-а, безопасности) соображений были перенесены каталоги временных файлов в раздел /www:
mkdir -p /www/php/{session,wsdlcache}
chown nginx.nginx /www/php/session
chmod 770 /www/php/session
chown -R nginx.nginx /www/php/wsdlcache
chmod 770 /www/php/wsdlcache
Содержимое файла /etc/php-fpm.d/www.conf
[www]
listen = /var/run/php-fpm/socket
listen.allowed_clients = 127.0.0.1
listen.owner = nginx
listen.group = nginx
listen.mode = 0660
user = nginx
group = nginx
process.priority = -5
pm = dynamic
pm.max_children = 50
pm.start_servers = 20
pm.min_spare_servers = 5
pm.max_spare_servers = 35
pm.max_requests = 500
access.log = /var/log/php-fpm/$pool.access.log
slowlog = /var/log/php-fpm/www-slow.log
request_slowlog_timeout = 20s
php_admin_value[error_log] = /var/log/php-fpm/www-error.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 128M
; Set session path to a directory owned by process user
php_value[session.save_handler] = files
php_value[session.save_path] = /www/php/session
php_value[soap.wsdl_cache_dir] = /www/php/wsdlcache
Файл /etc/php-fpm.conf без изменений.
1.1 Небольшая донастройка РНР
На сервере для нужд не только самого сайта используется php, чтобы от него меньше было вреда в конфигурационный файл /etc/php.ini были привнесены следующие изменения:
# Disallow dangerous functions
disable_functions = popen, exec, system, passthru, proc_open, shell_exec, phpinfo, mail
# Maximum amount of memory a script may consume
memory_limit = 36M
# Restrict PHP information leakage
expose_php = Off
# Whether to allow the treatmant of URL as file
allow_url_fopen = Off
Чтобы побороть один недугъ в файле /etc/php.ini изменена следующая строка к виду:
cgi.fix_pathinfo=0
Старт и автозапуск:
systemctl start php-fpm && systemctl enable php-fpm
2. О грустном
Часто приходится читать, иногда слышать, что первым делом после установки надо обязательно выключать, а лучше сносить (если умеешь) ненавистный и мешающий всему SELinux. Давайте не будем кривить душой, парни из АНБ свою работу знают и делают хорошо. И что бы там не говорили про сильно хитро завуалированные закладки, пока ещё не встречал сообщений, что SELinux попался на наушничестве. К тому же исходники открыты да доступны для изучения.
Теперь вместо лирики. Для работы с контекстом SELinux нужна утилита semanage из пакета policycoreutils-python:
yum install policycoreutils-python -y
Какие есть в системе готовые политики для nginx, php и есть ли они вообще?
semanage fcontext -l | grep nginx
/etc/nginx(/.*)? all files system_u:object_r:httpd_config_t:s0
/var/run/nginx.* all files system_u:object_r:httpd_var_run_t:s0
/var/lib/nginx(/.*)? all files system_u:object_r:httpd_var_lib_t:s0
/var/log/nginx(/.*)? all files system_u:object_r:httpd_log_t:s0
/var/opt/rh/rh-nginx18/log(/.*)? all files system_u:object_r:httpd_log_t:s0
/etc/opt/rh/rh-nginx18/nginx(/.*)? all files system_u:object_r:httpd_config_t:s0
/usr/lib/systemd/system/nginx.* regular file system_u:object_r:httpd_unit_file_t:s0
/var/opt/rh/rh-nginx18/lib/nginx(/.*)? all files system_u:object_r:httpd_var_lib_t:s0
/var/opt/rh/rh-nginx18/run/nginx(/.*)? all files system_u:object_r:httpd_var_run_t:s0
/usr/sbin/nginx
semanage fcontext -l | grep php
/var/lib/php(/.*)? all files system_u:object_r:httpd_var_lib_t:s0
/var/www/html(/.*)?/sites/default/settings\.php regular file system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/wiki/.*\.php regular file system_u:object_r:mediawiki_content_t:s0
/var/cache/php-.* all files system_u:object_r:httpd_cache_t:s0
/var/log/php-fpm(/.*)? all files system_u:object_r:httpd_log_t:s0
/var/run/php-fpm(/.*)? all files system_u:object_r:httpd_var_run_t:s0
/var/log/suphp\.log.* regular file system_u:object_r:httpd_log_t:s0
/var/lib/php/session(/.*)? all files system_u:object_r:httpd_var_run_t:s0
/usr/share/wordpress/.*\.php regular file system_u:object_r:httpd_sys_script_exec_t:s0
/var/cache/php-mmcache(/.*)? all files system_u:object_r:httpd_cache_t:s0
/var/lib/php/wsdlcache(/.*)? all files system_u:object_r:httpd_var_run_t:s0
/var/log/php_errors\.log.* regular file system_u:object_r:httpd_log_t:s0
/var/cache/php-eaccelerator(/.*)? all files system_u:object_r:httpd_cache_t:s0
/usr/lib/systemd/system/php-fpm.* regular file system_u:object_r:httpd_unit_file_t:s0
/usr/share/wordpress/wp-includes/.*\.php regular file system_u:object_r:httpd_sys_script_exec_t:s0
/usr/sbin/php-fpm regular file system_u:object_r:httpd_exec_t:s0
/var/www/html/configuration\.php all files system_u:object_r:httpd_sys_rw_content_t:s0
/usr/zend/lib/apache2/libphp5\.so regular file system_u:object_r:textrel_shlib_t:s0
/usr/share/wordpress-mu/wp-config\.php
semanage fcontext -l | grep httpd
/usr/.*\.cgi regular file system_u:object_r:httpd_sys_script_exec_t:s0
/opt/.*\.cgi regular file system_u:object_r:httpd_sys_script_exec_t:s0
/srv/([^/]*/)?www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/srv/([^/]*/)?www/logs(/.*)? all files system_u:object_r:httpd_log_t:s0
/var/www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/www(/.*)?/logs(/.*)? all files system_u:object_r:httpd_log_t:s0
/etc/glpi(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/[^/]*/cgi-bin(/.*)? all files system_u:object_r:httpd_sys_script_exec_t:s0
/etc/horde(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/etc/htdig(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/etc/httpd(/.*)? all files system_u:object_r:httpd_config_t:s0
/etc/nginx(/.*)? all files system_u:object_r:httpd_config_t:s0
/etc/drupal.* all files system_u:object_r:httpd_sys_rw_content_t:s0
/etc/z-push(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/etc/apache(2)?(/.*)? all files system_u:object_r:httpd_config_t:s0
/var/lib/rt(3|4)/data/RT-Shredder(/.*)? all files system_u:object_r:httpd_var_lib_t:s0
/var/lib/dav(/.*)? all files system_u:object_r:httpd_var_lib_t:s0
/var/lib/php(/.*)? all files system_u:object_r:httpd_var_lib_t:s0
/var/lib/svn(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/svn(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/run/mod_.* all files system_u:object_r:httpd_var_run_t:s0
/var/run/wsgi.* socket system_u:object_r:httpd_var_run_t:s0
/etc/cherokee(/.*)? all files system_u:object_r:httpd_config_t:s0
/etc/owncloud(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/etc/lighttpd(/.*)? all files system_u:object_r:httpd_config_t:s0
/srv/gallery2(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/lib/glpi(/.*)? all files system_u:object_r:httpd_var_lib_t:s0
/var/lib/trac(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/log/glpi(/.*)? all files system_u:object_r:httpd_log_t:s0
/var/www/perl(/.*)? all files system_u:object_r:httpd_sys_script_exec_t:s0
/var/cache/rt(3|4)(/.*)? all files system_u:object_r:httpd_cache_t:s0
/var/www/html(/.*)?/uploads(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html(/.*)?/wp-content(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html(/.*)?/sites/default/files(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html(/.*)?/sites/default/settings\.php regular file system_u:object_r:httpd_sys_rw_content_t:s0
/var/run/httpd.* all files system_u:object_r:httpd_var_run_t:s0
/var/run/nginx.* all files system_u:object_r:httpd_var_run_t:s0
/etc/mock/koji(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/usr/lib/httpd(/.*)? all files system_u:object_r:httpd_modules_t:s0
/var/lib/htdig(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/lib/httpd(/.*)? all files system_u:object_r:httpd_var_lib_t:s0
/var/lib/nginx(/.*)? all files system_u:object_r:httpd_var_lib_t:s0
/var/log/cacti(/.*)? all files system_u:object_r:httpd_log_t:s0
/var/log/httpd(/.*)? all files system_u:object_r:httpd_log_t:s0
/var/log/nginx(/.*)? all files system_u:object_r:httpd_log_t:s0
/var/www/icons(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/cache/ssl.*\.sem regular file system_u:object_r:httpd_cache_t:s0
/var/www/html/[^/]*/cgi-bin(/.*)? all files system_u:object_r:httpd_sys_script_exec_t:s0
/var/cache/mod_.* all files system_u:object_r:httpd_cache_t:s0
/var/cache/php-.* all files system_u:object_r:httpd_cache_t:s0
/var/lib/drupal.* all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/run/apache.* all files system_u:object_r:httpd_var_run_t:s0
/etc/zabbix/web(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/usr/lib/apache(/.*)? all files system_u:object_r:httpd_modules_t:s0
/usr/share/glpi(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/lib/moodle(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/lib/z-push(/.*)? all files system_u:object_r:httpd_var_lib_t:s0
/var/log/z-push(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/spool/gosa(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/etc/apache-ssl(2)?(/.*)? all files system_u:object_r:httpd_config_t:s0
/var/log/apache(2)?(/.*)? all files system_u:object_r:httpd_log_t:s0
/usr/sbin/httpd(\.worker)? regular file system_u:object_r:httpd_exec_t:s0
/usr/lib/apache(2)?/suexec(2)? regular file system_u:object_r:httpd_suexec_exec_t:s0
/usr/sbin/apache(2)? regular file system_u:object_r:httpd_exec_t:s0
/etc/WebCalendar(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/usr/lib/cgi-bin(/.*)? all files system_u:object_r:httpd_sys_script_exec_t:s0
/usr/share/htdig(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/cache/httpd(/.*)? all files system_u:object_r:httpd_cache_t:s0
/var/cache/mason(/.*)? all files system_u:object_r:httpd_cache_t:s0
/var/lib/ipsilon(/.*)? all files system_u:object_r:httpd_var_lib_t:s0
/var/log/horizon(/.*)? all files system_u:object_r:httpd_log_t:s0
/var/log/php-fpm(/.*)? all files system_u:object_r:httpd_log_t:s0
/var/run/php-fpm(/.*)? all files system_u:object_r:httpd_var_run_t:s0
/var/www/cgi-bin(/.*)? all files system_u:object_r:httpd_sys_script_exec_t:s0
/etc/httpd/alias(/.*)? all files system_u:object_r:cert_t:s0
/usr/share/drupal.* all files system_u:object_r:httpd_sys_content_t:s0
/usr/share/joomla(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/usr/lib/cherokee(/.*)? all files system_u:object_r:httpd_modules_t:s0
/usr/lib/lighttpd(/.*)? all files system_u:object_r:httpd_modules_t:s0
/usr/share/z-push(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/lib/cherokee(/.*)? all files system_u:object_r:httpd_var_lib_t:s0
/var/lib/dokuwiki(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/lib/lighttpd(/.*)? all files system_u:object_r:httpd_var_lib_t:s0
/var/lib/owncloud(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/log/cherokee(/.*)? all files system_u:object_r:httpd_log_t:s0
/var/log/lighttpd(/.*)? all files system_u:object_r:httpd_log_t:s0
/var/run/lighttpd(/.*)? all files system_u:object_r:httpd_var_run_t:s0
/var/spool/viewvc(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/svn/conf(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/usr/lib/cgi-bin/(nph-)?cgiwrap(d)? regular file system_u:object_r:httpd_suexec_exec_t:s0
/var/log/suphp\.log.* regular file system_u:object_r:httpd_log_t:s0
/usr/share/icecast(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/cache/mod_ssl(/.*)? all files system_u:object_r:httpd_cache_t:s0
/var/lib/cacti/rra(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/lib/pootle/po(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/svn/hooks(/.*)? all files system_u:object_r:httpd_sys_script_exec_t:s0
/var/log/thttpd\.log.* regular file system_u:object_r:httpd_log_t:s0
/var/cache/lighttpd(/.*)? all files system_u:object_r:httpd_cache_t:s0
/var/www/moodledata(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/log/apache-ssl(2)?(/.*)? all files system_u:object_r:httpd_log_t:s0
/usr/lib/apache-ssl/.+ regular file system_u:object_r:httpd_exec_t:s0
/var/log/cgiwrap\.log.* regular file system_u:object_r:httpd_log_t:s0
/usr/sbin/apache-ssl(2)? regular file system_u:object_r:httpd_exec_t:s0
/srv/gallery2/smarty(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/usr/share/ntop/html(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/cache/mediawiki(/.*)? all files system_u:object_r:httpd_cache_t:s0
/var/cache/mod_proxy(/.*)? all files system_u:object_r:httpd_cache_t:s0
/var/lib/php/session(/.*)? all files system_u:object_r:httpd_var_run_t:s0
/var/run/user/apache(/.*)? all files system_u:object_r:httpd_tmp_t:s0
/var/www/moodle/data(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/stickshift/[^/]*/log(/.*)? all files system_u:object_r:httpd_log_t:s0
/var/cache/mod_gnutls(/.*)? all files system_u:object_r:httpd_cache_t:s0
/var/lib/graphite-web(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/lib/mod_security(/.*)? all files system_u:object_r:httpd_var_lib_t:s0
/var/www/miq/vmdb/log(/.*)? all files system_u:object_r:httpd_log_t:s0
/usr/share/wordpress/.*\.php regular file system_u:object_r:httpd_sys_script_exec_t:s0
/var/cache/php-mmcache(/.*)? all files system_u:object_r:httpd_cache_t:s0
/var/lib/php/wsdlcache(/.*)? all files system_u:object_r:httpd_var_run_t:s0
/var/lib/roundcubemail(/.*)? all files system_u:object_r:httpd_var_lib_t:s0
/var/log/roundcubemail(/.*)? all files system_u:object_r:httpd_log_t:s0
/var/log/php_errors\.log.* regular file system_u:object_r:httpd_log_t:s0
/usr/share/doc/ghc/html(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/www/gallery/albums(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/usr/lib/apache2/modules(/.*)? all files system_u:object_r:httpd_modules_t:s0
/usr/share/openca/htdocs(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/usr/share/selinux-policy[^/]*/html(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/run/dirsrv/admin-serv.* all files system_u:object_r:httpd_var_run_t:s0
/usr/share/jetty/bin/jetty.sh regular file system_u:object_r:httpd_exec_t:s0
/var/opt/rh/rh-nginx18/log(/.*)? all files system_u:object_r:httpd_log_t:s0
/var/log/dirsrv/admin-serv(/.*)? all files system_u:object_r:httpd_log_t:s0
/var/cache/php-eaccelerator(/.*)? all files system_u:object_r:httpd_cache_t:s0
/var/lib/squirrelmail/prefs(/.*)? all files system_u:object_r:httpd_squirrelmail_t:s0
/var/lib/openshift/\.httpd\.d(/.*)? all files system_u:object_r:httpd_config_t:s0
/var/www/html/owncloud/data(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/etc/opt/rh/rh-nginx18/nginx(/.*)? all files system_u:object_r:httpd_config_t:s0
/var/lib/stickshift/\.httpd\.d(/.*)? all files system_u:object_r:httpd_config_t:s0
/usr/lib/systemd/system/httpd.* regular file system_u:object_r:httpd_unit_file_t:s0
/usr/lib/systemd/system/jetty.* regular file system_u:object_r:httpd_unit_file_t:s0
/usr/lib/systemd/system/nginx.* regular file system_u:object_r:httpd_unit_file_t:s0
/var/lib/openshift/\.log/httpd(/.*)? all files system_u:object_r:httpd_log_t:s0
/usr/lib/systemd/system/thttpd.* regular file system_u:object_r:httpd_unit_file_t:s0
/var/www/openshift/console/tmp(/.*)? all files system_u:object_r:httpd_tmp_t:s0
/var/www/openshift/console/log(/.*)? all files system_u:object_r:httpd_log_t:s0
/usr/lib/systemd/system/php-fpm.* regular file system_u:object_r:httpd_unit_file_t:s0
/var/opt/rh/rh-nginx18/lib/nginx(/.*)? all files system_u:object_r:httpd_var_lib_t:s0
/var/opt/rh/rh-nginx18/run/nginx(/.*)? all files system_u:object_r:httpd_var_run_t:s0
/usr/share/wordpress/wp-includes/.*\.php regular file system_u:object_r:httpd_sys_script_exec_t:s0
/usr/share/wordpress-mu/wp-content(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/openshift/broker/httpd/run(/.*)? all files system_u:object_r:httpd_var_run_t:s0
/var/www/openshift/broker/httpd/logs(/.*)? all files system_u:object_r:httpd_log_t:s0
/var/www/openshift/console/httpd/run(/.*)? all files system_u:object_r:httpd_var_run_t:s0
/var/www/openshift/console/httpd/logs(/.*)? all files system_u:object_r:httpd_log_t:s0
/usr/share/wordpress/wp-content/uploads(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/usr/share/wordpress/wp-content/upgrade(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/opt/dirsrv/var/run/dirsrv/dsgw/cookies(/.*)? all files system_u:object_r:httpd_var_run_t:s0
/etc/vhosts regular file system_u:object_r:httpd_config_t:s0
/usr/bin/httpd regular file system_u:object_r:publicfile_exec_t:s0
/etc/httpd/logs all files system_u:object_r:httpd_log_t:s0
/usr/sbin/nginx regular file system_u:object_r:httpd_exec_t:s0
/etc/thttpd\.conf regular file system_u:object_r:httpd_config_t:s0
/usr/sbin/suexec regular file system_u:object_r:httpd_suexec_exec_t:s0
/usr/sbin/thttpd regular file system_u:object_r:httpd_exec_t:s0
/usr/sbin/php-fpm regular file system_u:object_r:httpd_exec_t:s0
/etc/httpd/modules all files system_u:object_r:httpd_modules_t:s0
/usr/bin/htsslpass regular file system_u:object_r:httpd_helper_exec_t:s0
/usr/sbin/cherokee regular file system_u:object_r:httpd_exec_t:s0
/usr/sbin/lighttpd regular file system_u:object_r:httpd_exec_t:s0
/var/run/thttpd\.pid regular file system_u:object_r:httpd_var_run_t:s0
/etc/init\.d/cherokee regular file system_u:object_r:httpd_initrc_exec_t:s0
/usr/sbin/rotatelogs regular file system_u:object_r:httpd_rotatelogs_exec_t:s0
/var/run/gcache_port socket system_u:object_r:httpd_var_run_t:s0
/usr/sbin/httpd\.event regular file system_u:object_r:httpd_exec_t:s0
/var/run/cherokee\.pid regular file system_u:object_r:httpd_var_run_t:s0
/etc/httpd/conf/keytab regular file system_u:object_r:httpd_keytab_t:s0
/etc/rc\.d/init\.d/httpd regular file system_u:object_r:httpd_initrc_exec_t:s0
/usr/bin/mongrel_rails regular file system_u:object_r:httpd_exec_t:s0
/usr/sbin/htcacheclean regular file system_u:object_r:httpd_exec_t:s0
/etc/rc\.d/init\.d/lighttpd regular file system_u:object_r:httpd_initrc_exec_t:s0
/var/run/piranha-httpd\.pid regular file system_u:object_r:piranha_web_var_run_t:s0
/var/www/html/configuration\.php all files system_u:object_r:httpd_sys_rw_content_t:s0
/usr/libexec/httpd-ssl-pass-dialog regular file system_u:object_r:httpd_passwd_exec_t:s0
/usr/share/wordpress-mu/wp-config\.php regular file system_u:object_r:httpd_sys_script_exec_t:s0
/usr/share/system-config-httpd/system-config-httpd regular file system_u:object_r:bin_t:s0
Ну, то есть валом. Ничего своего писать не надо будет. Можно взять готовое и переиначить на свой манер. Т. е. поменять файловый контекст применительно для нового варианта размещения файлов сайта по месту /www/nginx.
semanage fcontext -a -t httpd_sys_content_t "/www/nginx"
semanage fcontext -a -t var_t "/www/nginx/cache(/.*)?"
semanage fcontext -a -t httpd_sys_rw_content_t "/www/nginx/vist(/.*)?"
semanage fcontext -a -t httpd_var_lib_t "/www/php"
semanage fcontext -a -t httpd_var_run_t "/www/php/session(/.*)?"
semanage fcontext -a -t httpd_var_run_t "/www/php/wsdlcache(/.*)?"
restorecon -RF -v /www/
Ну и разрешить подключение к СУБД и к сети:
setsebool -P httpd_can_network_connect_db 1
setsebool -P httpd_can_network_connect 1
Есть ли какие-нибудь замечания?
audit2allow -a
#============= rpm_script_t ==============
#!!!! This avc is allowed in the current policy
allow rpm_script_t init_t:service disable;
#============= systemd_logind_t ==============
#!!!! This avc is allowed in the current policy
allow systemd_logind_t user_tmp_t:dir mounton;
#============= unconfined_t ==============
allow unconfined_t init_t:service enable;
Ничего особенного и тем более не имеющее отношение к данной установке.
3. Установка WolfCMS
Файл с актуальной версией CMS скачан и распакован в коревой директории будущего сайта /www/nginx/vist.
Теперь можно приступать к установке. В браузере заветный адресок.
Всё нормально? Тогда Continue to install.
Для случая с PostgreSQL поле «Table prefix» либо не трогать и оставить как есть, либо указать что-то своё, но не оставлять пустым. Иначе во время установки будут проблемы с заполнением базы данных.
Поскольку будем использовать http-сервер ngix, птичку с поля «Use clean URLs» надо убрать.
Можно запускать «Install now!».
Всё прошло нормально, можно записать временный пароль (он пригодится чуть позже) и перейти настройкам безопасности после установки.
Вот тут нам подробно рассказывают, что у нас есть опасного и как это побороть.
Но прежде чем к этому приступать, надо внести небольшие правки в файл /www/nginx/vist/config.php, чтобы CMS корректно работала с web-сервером nginx.
Для этого строки:
// Add a suffix to pages (simluating static pages '.html')
define('URL_SUFFIX', 'html');
// Change this setting to enable mod_rewrite. Set to "true" to remove the "?" in the URL.
// To enable mod_rewrite, you must also change the name of "_.htaccess" in your
// Wolf CMS root directory to ".htaccess"
define('USE_MOD_REWRITE', false);
Привести к виду:
// Add a suffix to pages (simluating static pages '.html')
define('URL_SUFFIX', '');
// Change this setting to enable mod_rewrite. Set to "true" to remove the "?" in the URL.
// To enable mod_rewrite, you must also change the name of "_.htaccess" in your
// Wolf CMS root directory to ".htaccess"
define('USE_MOD_REWRITE', true);
Теперь можно безопасить:
chmod -R a-w /www/nginx/vist/wolf/
chmod a-w /www/nginx/vist/index.php
chmod a-w /www/nginx/vist/
chmod 440 /www/nginx/vist/config.php
rm -f /www/nginx/vist/composer.json
rm -f /www/nginx/vist/CONTRIBUTING.md
rm -f /www/nginx/vist/README.md
rm -f -R /www/nginx/vist/docs
rm -f -R /www/nginx/vist/wolf/install
rm -f /www/nginx/vist/security.php
Установка закончена. Можно заходить и настраивать.
Панель администрирования находится по адресу example-test.org/admin. Для входа надо заполнить форму: указать свой логин и пароль, который был сгенерирован на этапе установки.
Первый вход выполняется на английской языке (по умолчанию), в настройках можно выбрать иной язык панели администрирования. Русский поддерживается.
Панель администрирования условно можно разделить на несколько частей: меню пользователя, основное меню с вкладками (табами), основной частью страницы и в самом низу страницы ссылки ведущие на форум и документацию по CMS.
Вкладка Страница (Page) может представлять собой статью, новость или заметку. Текст статьи может быть простым набором слов, либо кодом php или html. Так же у страниц есть ещё дополнительные поля метаданных: «Ключевые слова» (keywords) и «Описание» (descritpion) для SEO оптимизации, помимо этого на вкладке «Настройки» можно задавать внешний вид, права доступа, время публикации и т. д.
Вкладка Фрагмент (Snippet) — небольшая часть контента на php или html, которая может быть включена в другие страницы или макеты. Изначально в виде отдельных макетов выделены блоки header и footer, в качестве фрагмента могут быть небольшие блоки информации: рекламный блок, список последних статей в блоге.
Вкладка Макет (Layout) используется для придания внешнего вида странице. Здесь могут быть специальные тэги для включения определённого содержания страницы и другие элементы, такие как колонтитулы, подключаются css-файлы, прописывается код, требуемый стандартами. При этом в определённых местах вместо реального контента будут вставлены определённые функции самой WolfCMS. Поэтому макет выглядит как html-код стандартного сайта, но при этом короче и легко читаем за счёт замены основных блоков на функции CMS с понятными именами. Можно создавать макеты, которые могут быть применены к разным разделам сайта и даже к разным страницам.
Сами макеты делаются на чистом html+css+js со вставками на php. Понятное дело, что шаблонизатор отсутствует. Это с одной стороны улучшает производительность, но как следствие усложняется разработка. Поэтому уверенное знание php крайне желательно. Хотя есть в природе примеры кода, которые можно подсмотреть и адаптировать их под себя.
Перейдём на вкладку «Users» и сменим установочный пароль на свой секретный.
Вкладка «Администрирование» с перечнем плагинов.
Плагины — это подпрограммы на php, срабатывающие при наступлении определённых событий в панели администрирования или на сайте и по своей сути ближе к модулям Drupal. Условно их можно разделить на четыре группы: модуль с админкой, модуль без админки, новый тип страниц, новый фильтр текста.
Плагин Новый тип страниц позволяет наделить стандартные страницы новыми функциями — привязать к ним обработчик.
Плагин Новый фильтр текста — редактор, доступный в панели администрирования. При сохранении страницы в базу записывается последний использованный фильтр, поэтому при открытии страницы для повторного редактирования, автоматически подключится последний фильтр. Есть только в этом недостаток — все активные плагины фильтры текста, подключены постоянно к странице, оставаясь невидимыми. Поэтому обработка скриптов и правил css замедляет работу панели администрирования.
Вкладка «Настройка»
Принцип создания сайтов в данной CMS следующий: в начале создаётся базовая структура сайта с визуальным размещением страниц. Затем выполняется адаптация макета. При этом можно довольно гибко настроить любой макет из чистого html, здесь особых сложностей не должно возникать. А вот с php трудности могут быть поскольку готовые модули, плагины по созданию тех же меню здесь отсутствуют. Следующим этапом в создании макета будет выделение общих кусков кода и оформление их во фрагменты, программирование логики работы сайта на php и вывод нужного функционала.
4. Зачем всё это
На тостере иногда задаётся вопрос какую CMS лучше заюзать для небольшого или простенького проекта, станка ЧПУ. Часто в ответах одни рекомендуют взять WordPress другие советуют Joomla, Битрикс присоветывают тоже. Потом, бывает, у них случается небольшая стычка с выяснением чья петрушка зеленее. Ну и объяснением такого выбора также обычно бывают сетования, что инфы по настройкам данных систем валом, куча готовых конфигураций и такая же куча дополнительных модулей и расширений, ещё большое коммьюнити. Только наливай, пей и не о чём не думай.
Модные ныне CMS пытаются по возможности спрятать от пользователя чистый php и html код. Может оно и в какой-то мере оправдано, когда человек впервые взялся за web-разработку, чтобы не отбивать у него охоту. В WolfCMS администратор видит практически весь код в чистом виде, который аккуратно разложен по полочкам и подписан, так же имеет глубокий доступ к системе, что позволяет ему более гибко реализовать свои задумки вплоть до изменения под себя ядра системы. Плюс к всему данная CMS не требовательна к системным ресурсам.
Поделиться с друзьями
Комментарии (46)
Acuna
24.06.2016 02:05Ну наконец-то прибыл мануал по настройке сервера без апача, а-то в инете в былое время искал, дак это все сплошь настройки связок nginx c апачем для домохозяек, и притом 10-летней давности (серьезно, 10-летней!).
Можно даже сказать, что это не система управления контентом по типу WordPress, MaxSite, Joomla и т. п. И не php-framework типа Yii, Laravel или Kohana. WolfCMS занимает промежуточную нишу между этими крайними точками. С одной стороны есть админка, с другой стороны всё нужно писать самому на php.
Под Ваше описание полностью подходит определение CMF (Content Management Framework), по сути это каркас для CMS c админкой (и то не всегда).
P. S. Уж если статья 2016 года — надо сразу было ставить PHP 7. Реально, это практически другой двиг в плане производительности. Да и сам обновлялся недавно как раз с 5.6 — встал как влитой, ни одной ошибки не выдал, даже по phpinfo () проверял точно ли я на PHP 7)
bARmaleyKA
24.06.2016 11:37Не всё так гладко в плане работы на PHP 7. Причём не самой CMS, а той обвязки, которая к ней дописана.
Acuna
24.06.2016 17:25Хм… А известно ли в чем заключаются эти за проблемы? Просто когда я переезжал по-моему на 5.6 и когда в нем отменили модификатор «e» в регулярках, предлагая использовать preg_replace_callback () вместо него, и пришлось почти вручную переписывать пол проекта — это было действительно ощутимо. Но эти трудности были без особых проблем преодолены, в итоге PHP 7 лег как влитой, как я уже писал выше. Я не уверен, что в обвязке WolfCMS все так же запущенно.
bARmaleyKA
24.06.2016 17:44WolfCMS работала на седьмой версии от репозитория remi ещё до официального релиза PHP. Месяца за два до релиза у них появилась седьмая ветка с пакетами. Работу на этих пакетах проверял лично. Проблем не было. По крайней мере не выявил.
Просто к самой CMS прикручен application, когда-то сторонним разработчиком написанный, который местами не совсем работает нормально на семёрке.
Связывался ещё до релиза седьмого php с этим разработчиком, предлагал затестить новьё, но он отказался.
Поднимал быстродействие за счёт настройки сервисов и операционки.Acuna
26.06.2016 18:56Ясно… Просто я действительно до сих пор не могу понять в чем вообще могут быть сложности с PHP 7. Я свой проект начал писать почти что в школе, но я не думаю, что разраб WolfCMS более криворукий)
alexhouse
24.06.2016 02:53Новых версий WolfCMS нет с августа 2015. Есть ощущение, что проект забросили и новой версии не будет.
kolu4iy
24.06.2016 10:43Вы правильно написали про selinux и его policy. Только забыли упомянуть, что кроме безопасности selinux обязательно привносит и накладные расходы. Можно считать их ничтожными, однако при нагруженном сервере это заметно «тяжелее» включения https.
bARmaleyKA
24.06.2016 11:54Все аспекты связанные с безопасностью потребляют ресурсы в той или иной мере. Тот же iptables + iphost нагруженный кучей правил, а если ещё в связке с fail2ban, могут откушать достаточное количество ресурсов. По сравнению с теми расходами, которые берёт на себя selinux, и тем что берёт на себя антивирус, настоятельно рекомендуемый некоторыми к установке на linux web-сервер, ну небо и земля.
Основной накладной расход, требуемый такой подсистемой бесопасности как selinux — это хорошие знания операционной системы и ещё лушие знания принципа работы приложения (куда чего как и от кого пишет-читает, что слушает по портам, куда обращается и зачем,...). Вот с этим обычно и возникает проблема.
ToSHiC
27.06.2016 22:49Вы довольно много строк посвятили тюнингу, а уверены, что fastcgi_temp_path показывает в тот же раздел, что и fastcgi_cache_path?
И совершенно непонятно, зачем реврайт в локейшене, который показывает 5хх ошибки.
Зачем менять net.core.somaxconn, если размер backlog в nginx не меняли? Тем более, зачем net.ipv4.tcp_syncookies=1, если somaxconn такой небольшой?
Вы проверяли, на сколько ваши настройки быстрее по сравнению с полным дефолтом, только conf.d/server.conf ваш?bARmaleyKA
28.06.2016 17:45Вы довольно много строк посвятили тюнингу, а уверены, что fastcgi_temp_path показывает в тот же раздел, что и fastcgi_cache_path?
А вот за это огромное человеческое спасибо! Дельное замечание. Займусь им.
Зачем менять net.core.somaxconn, если размер backlog в nginx не меняли?
Изначально net.core.somaxconn = 128. Встречал рекомендованные цифры в диаппазоне 15000-20000. Здесь вообще накрутили 65535.
В nginx значение backlog по умолчанию 511. Изначальная величина максимального числа открытых сокетов в 128 явно малая с тем что идёт у nginx по умолчанию. Помимо этого в системе открыто порядком служебных сокетов: /run/systemd/journal/stdout, /var/run/dbus/system_bus_socket наверно с дюжину наберётся, не считая остальных. net.core.somaxconn = 1024 взято с заделом.
Тем более, зачем net.ipv4.tcp_syncookies=1, если somaxconn такой небольшой?
Вот с этим не так просто. С одной стороны есть рекомендация разработчиков ядра, но с другой стороны эта переменная нужна для предотвращения syn-flood атак. На момент первоначальной настройки CMS уже лезли. Думал поставить phpmyadmin, чтобы успокоились)
Вы проверяли, на сколько ваши настройки быстрее по сравнению с полным дефолтом, только conf.d/server.conf ваш?
Если вы имеете в виду настройки системы, то проверил, так сказать, на себе излишнюю буферезацию (всякие net.core.rmem_max, net.core.wmem_max и т. п. больше чем положено). Отказался от неё в итоге. Откатился к изначальным настройкам и пробовал на них. Применение профиля latency-performance даёт заметный прирост производительности.
jMas
Эх, наследие FrogCMS, жаль Philippe Archambault в свое время оставил разработку, у него определенно было хорошее видение проекта.
zenn
Не знаю какое там у кого виденье проекта, но под капотом код просто ужасен: в пример вам мега-супер-файл-фреймворк все в одном файле… Я каждый раз думаю, что хуже того, что я уже видел — не увидеть, но это не так…
jMas
zenn,… и? Эта CMS была изначально ориентирована на простые решения, это сюрприз, что внутри был MVC в каком то виде.
Зачем брать Leravel/Zend/Yii для проекта на котором будут работать достаточно простые сайты?
И давайте объективно, что вы нашли просто ужасное, с чем невозможно жить? Там все по спартански минималистично-просто, тем не менее необходимый минимум есть. А так же сделайте поправку на то, что система родом из 2007-2008 годов.
Тем более я о CMS и сообществе в целом, а не о коде.
zenn
Объяснить по пунктам что там не так? Хорошо, это мы умеем. Да, я понимаю что система 2007-2008 годов, но почему бы не провести рефакторинг или зачем тогда ее популяризировать, если она — труп? Опираться на доводы, что система написана в 2007 году, поэтому у нее сейчас, в 2016 плохой код и в это же время ее рекламировать — звучит крайне странно. Давайте даже отбросим все стандарты веб-программирования (про psr вообще молчу), composer (у вас лишь имитация его наличия), примитивный OOP и стандарты автозагрузки, отсутствие механизма адекватной шаблонизации и т.д. Поехали (см. Framework):
Даже в 2008 str_replace уже умел принимать в виде $needle и $replacement массивы, или вам это не известно?
Как я понимаю, об parse_url() вы тоже не слышали, хотя он был в php уже с 4 версии.
У вас же есть «хэлпер» в системе, упрощающий подобные извраты вида substr($action, 0, 1) == '_' но вы и его игнорируете…
Вопрос один — зачем такая извращенная проверка на права записи для «owner-group-all», код ведь работает под текущим пользователем? Почему функция может вернуть bool а может быть и void?
И это пожалуй только беглый взгляд «за 5 минут» с отброшенными вовсе претензиями на качество кода, его архитектуру и т.д. Зачем вы пиарите систему, которая осталась на уровне качества 2008 года?
bARmaleyKA
Простите меня, оговорюсь сразу, я не совсем сварщик в стезе php. Поэтому некоторых нюансов могу не знать. Предложил описание небольшой, не шибко навороченной, не столь прожорливой CMS.
Критикуя, предлагайте. Буду благодарен вам, думаю не один я. Только просьба небольшая система должна уметь нормально работать с nginx, postgresql. Действительно интересно.
Там ещё одним разделом рекламировал приблуду года 2002, в ядро протолкнутую в 2005-2006, писанную на питоне и невыносимо мудрённую, что многие её отрубают сразу же после инсталяции ОС. Как её многие за вредность хают… Но лучше пока не написали. Это я к тому что древний код не всегда сразу и однозначно плохо.
zenn
и тут же:
И что мне теперь вам предложить? Это звучит как будто вы взялись строить дом, накидали г*вна и палок и живете в нем, а когда вам кто-то говорит, что это «неправильно» вы говорите — «предлагайте как улучшить, только я иначе не умею» и аргумент вида «лучше построить заново» для вас не будет адекватным и вы продолжите жить в этом д*рьме не обращая внимания на логичные доводы со стороны.
Но вернемся к вашему(а точней, к автору wolfcms) коду — выглядит он с точки зрения изначальной архитектуры примерно так же, как и дом, описанный выше. Единственное пожалуй, что бы посоветовал — переписать все с 0, оставив только идею (и то сомнительно). Перед переписыванием я бы вам посоветовал следующее:
Так же я бы посоветовал вам(или автору cms) заиметь опыт разработки на:
После этого, имея хотя-бы небольшой опыт разработки на паре фреймворков и знакомству с их архитектурой вам(или автору цмс) вполне бы удалось написать более-менее адекватную CMS с адекватным, расширяемым и читабельным кодом для других разработчиков, а не любоваться и далее своим домом из г*вна и палок. Прошу извинить меня за ругательство, я далеко не первый раз привожу эти ссылки и доводы, но еще ни разу никто не решился что-либо радикально изменить в своем «детище» в лучшую, адекватную сторону.
jMas
Хорошо, если провести рефакторинг, например добавить PSR и composer — алгоритм работы системы изменится / изменится архитектура?
bARmaleyKA
Ну если проводить аналогию со строительством дома, то как раз фундамент и фасад дома в порядке. Операционка настроена и профилирована, сервисы настроены и загнаны в клетки Selinux, и под постоянным присмотром системы аудита (про настройки auditd связки iptables+iphost+fail2ban, тонкую настройку postgresql, systemctl писать не стал, длиннючей статья получалась). Да, с балконом, точнее балкончиком (именно он нужен был) шняга вышла на взгляд профи балконостроения. Хотя упирался до последнего предлагая Zotonic, но там erlang и его хрен кто знает в наших краях, а программеров на пыхе достаток. Выпала масть работать с этой, как вы говорите, суперпозицией говна и щепок (я усилил вашу мысль). Так или иначе благодарен критику (матом не крыли и не рассказывали ничего про моих предков — уже в ноги поклон и благодарность). Доводы учту.
zenn
Ну что же вы, мы как основное «строение» рассматриваем именно эту CMS и ее кодо-базу, а не продукты уровня linux, seLinux, pgsql, sysctrl и прочие — их пожалуй в нашем примере с «домом» можно назвать «землей», наличием гравитации, воздуха и т.д. И знаете почему они (linux, nginx, php-fpm) работают исправно и достаточно стабильно? Потому что их написали не авторы wolf cms. Пользователь и разработчик ведь приходит на сайт не для того, чтобы посмотреть на линукс, пгскл, не так ли?
А по поводу окружения — верно в комментариях Acuna отметил, что подобное «обсасывание» настройки веб-сервера было актуально бы лет 10 назад…
jMas
Похоже на обычный троллинг. Где информация, что WolfCMS работает не стабильно? Да и от багов и говнокода никто не застрахован даже в таких местах, которые работают уже много лет. Просто у вас если код не PSR и нет компосера — значит он непременно не стабильный, а авторы дураки.
Вот если бы вы вспомнили тесты… Тогда вопросов нет.
zenn
Какой троллинг? Вы просили факты — я вам их выше предоставил, но так и не получил никакого ответа, кроме «да оно мне не надо, все эти табы, разметка кода, композеры там и все другое». Еще раз — есть код, и он плохой, почему — описал выше.
jMas
Хороший код — протестированный код. Наличие компосера, PSR или модного фреймверка или методологии написания кода — ничего не гарантирует, поэтому это и похоже на троллинг.
zenn
Это гарантирует безболезненную его доработку другими людьми, кроме извращенного разума создателя в любой момент времени.
jMas
Тесты гарантируют что от версии к версии оно падать не будет, так же существуют мануальные тесты (тестирование людьми и сообществом на реальных проектах), есть UI тесты, которые гарантируют работу заявленного функционала. У WolfCMS есть сообщество, а значит есть протестированность отличная от нуля.
Например вы написали аналогичную систему с нуля с PSR и всем чем угодно, но у вашей системы один пользователь — то есть вы, и протестированность в реальной жизни на реальных пользователях — ноль.
Сравнивая вашу разработку и WolfCMS боюсь предположить что как раз последняя будет обладать плохим кодом (то есть плохо протестированным и с багами).
zenn
Мы сейчас говорим о моей разработке или wolf cms? Где я хоть раз здесь что-либо прорекламировал из «своих разработок»? Зачем вы каждый раз пытаетесь увести разговор в другое русло? Еще раз — я привел несколько фактов, где код даже со стороны junior'a вызывает недоумение (т.к. он откровенный велосипед, который изобрел человек не знающих базовых фу-ий php), привел и доводы ущербности архитектуры в плане доработки и совместной разработки без «боли» и зуда в заднице более чем одним человеком, о unit-тестировании я не говорил здесь вовсе (да да, ни о phpunit, ни о codeception). И каждый раз, вы пытаетесь отстоять право на поедание кактуса, вместо принятия вполне адекватной критики.
jMas
Я просто указываю, что код — это только часть проекта, есть концепция UI дизайна, концепция плагинов, концепция шаблонов, концепция управления контентом, архитектура сущностей, сообщество и так далее. И даже НЕ на примере WolfCMS — потому что там действительно все во всех отношениях плохо. А вы толдычите, что если код не PSR, значит все тлен (условно говоря).
Можно например посмотреть на популярный WordPress или Joomla, где не соблюдается ни один из ваших критериев идеального кода, но тем не менее приходится иногда брать и эти системы чтобы на коленке сделать сайт знакомым. Или вы предлагаете брать Leravel для сайта-визитки?
zenn
Что вы уцепились за этот PSR? Я вам в 3ий раз повторю — еще раз посмотрите на мои пост выше, там речь об одном psr и все? У вас какой-то фетиш к концепции psr? Мне по пунктам еще раз вам повторить, почему это продукт на текущие тенденции г*вно?
jMas
Посмотрел, три первых пункта в основном относятся к стилю написания и поддержки кода. Четвертый пункт (MVC) вы привели наверное для того чтобы намекнуть, что неплохо было бы писать в контексте этого паттерна, но система этот паттерн активно юзает.
Было бы здорово если бы автор умел телепортироваться в будущее и получать опыт. (FrogCMS — 2007 год, Yii — 2008).
Я просто немного знаком с кухней FrogCMS (WolfCMS) и поэтому помню как развивался проект, реально его разработка прекратилась в 2009 году, поэтому уместно обсуждать проект в контексте того времени.
Следующее, я разговаривал с разработчиком оригинальной версии еще до форка, Philippe Archambault, и товарищ не глупый, разработал и тащил проект до определенного состояния, потом в силу обстоятельств свернул разработку, отдав систему сообществу.
Тем не менее, я считаю, что для своих нужд (простая система для сайтов визиток) — эта система очень даже неплоха, даже на сегодняшний момент и для людей с определенным опытом.
Весь этот "жаркий спор" был реакцией на мою фразу:
И я дальше готов повторять, что проект — это не только код, а UI/UX, сообщество, экосистема, и вообще люди которые стоят за проектом.
zenn
В 4ый раз повторю — было бы хорошо, если бы автор немного был знаком с рефакторингом или проект-труп не рекламировали бы на хабре.
Серьезно? Мне бы было интересно взглянуть хоть на 1 проект на этой CMS, разработкой и поддержкой которого занималось более чем 2 разных разработчика, там бы и не такие «перлы» всплыли бы как в коде самой cms…
Вы думаете граф. интерфейсы этого проекта в лучшем состоянии? Я взглянул на них мельком, тут даже говорить не о чем… Экосистема? Плагины и расширения? Да это кроме как велосипедом с костылями назвать иначе нельзя. Полный обзор этого «шедевра» и тыканье носом в каждую «дурную» реализацию заняло бы достаточно много времени, которого у меня нет на написание отдельной статьи. Да и желания такого нет, смысл говорить о «мертвых»?
Пожалуй я удалюсь из дискуссии, смысла не вижу дальнейшего — ни на 1 мой аргумент вы не обратили внимания, пусть так и будет.
jMas
Проектов-трупов не бывает, всегда найдется пару сайтов которые все еще нужно вести, иногда они переезжают, иногда на nginx.
Проекты разные, не вам судить, но есть и такие которые велись несколькими людьми, и имели вполне сносную посещаемость.
У вас просто измерительный прибор немного хромает, вы измеряете проекты по стилю написания кода и немного по внешнему виду. Только никогда не применяйте его к интерпрайзу.
bARmaleyKA
Кстати, касательно моей просьбы ранее. Приведите, пожалуйста, примеры годных по вашему мнению CMS, которые могут качественно и быстро работать с веб-серверами apache, nginx с СУБД mysql, postgresql, чтобы они были как вы ратуете качественно и грамотно написаны и не ресурсоёмки. А отсылки мне и разработчикам WolfCMS как надо правильно кодить — это не ответ.
bARmaleyKA
Вы абсолютно уверены, что зависимость именно такая?
Я вот перечитал этот комент от Acuna. Потом ещё раз. Даже приведу ту самую часть повторно ниже:
Напомню, что веб-сервер — это nginx, а никак не WolfCMS. И вот как-то совсем не вижу суждения, что приведённая в статье настройка nginx архаична и уподоблена 10-ти летней давности. У вас лично есть какие-то замечания к настройке nginx, приведённой к статье? Может быть надо было другой контект применить к его файлам и директориям, или планировщик обработки сетевых пакетов лучше иной использовать?
Единственное на что он посетовал в заключении своего комментария, так это на использование пыха 5.6 вместо седьмого. По вашему это тоже весомая ошибка с моей стороны?
zenn
Да, есть одно замечание — вбив в гугл configure nginx php-fpm я получу аналогичных 500 тыс статей с аналогичным обсасыванием настроек, начиная 2000-бородатых годов. Вы серьезно считаете, что пользователям хабра не известно как создать директорию в си-ме linux, выставить ей нужный чмод и указать к ней путь в конфиге? Вы думаете на хабре люди так и не знают, как настроить подключение к бд в граф. интерфейсе? Вообще, практическая ценность этой статьи близка к 0. Но вопрос основной как-раз таки в том, что вы рекламируете проект, кодо-база которого морально и практически осела на уровне 2008 года, а когда получаете какие-либо аргументы о качестве продукта, о текущих стандартах начинаете говорить о том, что «мол ну проект это 2008 года, ему можно, используйте ребята на здоровье».
jMas
Ссылки ведут только на сайт проекта, да и мануалов на русском нет. Хабру от лишней статьи хуже не станет, я уверен, ну потеряется она в списке статей, зато новичкам будет профит в виде мануала на популярном ресурсе.
Вы сильно опрометчиво думаете, что хабр читают только те кто админит linux.
Это можно сказать о многих проектах у которых большое комьюнити, но вы про это почему то не упоминаете.
zenn
Ну да, конечно. Ну давайте ткну вас носом:
То есть, чтобы выполнить chmod, chown, mkdir, yum install, move/cp, vim нужно быть админом linux? Занятно однако.
bARmaleyKA
Ну как бы человек вас спрашивал о:
А вы ткнули носом его в своё:
Понимаете какая вещь… Вообще
да, действительно выполнить сии команды может даже ребёнок. Вот как научится на клавиатуре набирать, так и сможет.
Я для вас открою большущий секрет — их надо в определённой последовательности набирать и после них в поле операндов надо знать что писать.
bARmaleyKA
Какие интересные замечания к настройкам веб-сервера.
Обратите внимание — это вы написали. Лично.
Почему? И для кого конкретно?
Вы дальше будете от прямых вопрос вертеть аки шмара задом или нечего сказать по существу?
zenn
Что ж, на личности перешли? Ну этого и стоило ждать, пусть читатель сам делает вывод кто и где крутит задом, удалюсь из топика о трупе.
bARmaleyKA
На констатацию фактов перешёл. Кому по вашему свойственно на вопрос: «Два плюс два?» отвечать «Стеариновая свечка», а потом ещё окрысившись кричать — «Ой, всё!!!»? Истерика да и только.
Труп? Пусть будет по вашему. Настройки системы дрова архаичные — да будет так. Аминь.
А вы сами много веб-серверов настроили на линуксе? Можно на настройки глянуть. Ну чтоб просветиться и проникнуться. Понятное дело о реально рабочих проектах вопрошаю.
bARmaleyKA
Судя по обилию минусов и адекватных ответов у кого-то эти дни.
MetaDone
https://github.com/bolt/bolt
bARmaleyKA
Спасибо вам, добрый человек. Возьму на заметку.
jMas
Давайте не будем о Psr, любая система с историей внутри содержит кучу legacy. Само собой что мыть руки полезно, но посыпать солью не-архитектуру, а так сказать стиль написания — не совсем корректно. Можно дойти до крайностей — например ругаться, что нет autoload, что файлы названы не в CamalCase или не в Underscore, да и табы, а не пробелы. На самом деле это не сильно влияет на работу алгоритмов в целом.
Например, composer не поддерживается просто потому что ЦА данной CMS по просту не имеет возможности сделать
composer installдаже локально. Обычно это Windows-пользователи с минимальными знаниями PHP.И по поводу критики, вы видите мелкие проблемы, которые можно решить рефакторингом, тем не менее структурно все не так плохо — есть полноценный MVC, который соблюдается (не говорю о плагинах). Модельки не сильно глупые.
jMas
Ах да, и я сейчас о https://github.com/philippe/FrogCMS/blob/master/frog/Framework.php
WolfCMS форкнуло сообщество, и мейнтайнер судя по всему, начал аппрувить что не попадя, поэтому говорить о FrogCMS и показывать на исходники WolfCMS некорректно.