Nginx | Информационный портал К2®

Category Archives: Nginx

Урок 5 Создание домена

Posted on 27.09.2016 by rudjuk Leave a comment

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

nginx + php-fpm + PHP APC + WordPress multisite (subdirectory) + WP Super

Posted on 14.10.2015 by rudjuk Leave a comment

У меня на хостинге использовался Nginx+Apache. Однако, в один прекрасный момент я столкнулся с тем, что интернет-магазины на WordPress не закидывали в корзину товары. Вначале я думал, что это проблема в CMS, потом, что проблема PHP. Но, в результате, после длительной борьбы с проблемой я увидел, что проблема в Nginx. Просто при ЧПУ нужно исправить настройки. В результате, получилось решение Nginx + PHP-FPM.

Вот настройки /etc/nginx/nginx.conf:

# Generic startup file.
user {user} {group};
worker_processes  3;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

# Keeps the logs free of messages about not being able to bind().
#daemon     off;

events {
	worker_connections  1024;
}

http {
#	rewrite_log on;

	include mime.types;
	default_type       application/octet-stream;
	access_log         /var/log/nginx/access.log;
	sendfile           on;
#	tcp_nopush         on;
	keepalive_timeout  3;
#	tcp_nodelay        on;
#	gzip               on;
	index              index.php index.html index.htm;

	# Upstream to abstract backend connection(s) for PHP.
	upstream php {
#        	server unix:/tmp/php-fpm.sock;
       	     server 127.0.0.1:9000;
	}

	include sites-enabled/*;
}

# Generic startup file.

user {user} {group};

worker_processes 3;

error_log /var/log/nginx/error.log;

pid /var/run/nginx.pid;

# Keeps the logs free of messages about not being able to bind().

#daemon off;

events {

worker_connections 1024;

}

http {

# rewrite_log on;

include mime.types;

default_type application/octet-stream;

access_log /var/log/nginx/access.log;

sendfile on;

# tcp_nopush on;

keepalive_timeout 3;

# tcp_nodelay on;

# gzip on;

index index.php index.html index.htm;

# Upstream to abstract backend connection(s) for PHP.

upstream php {

# server unix:/tmp/php-fpm.sock;

server 127.0.0.1:9000;

}

include sites-enabled/*;

}

Настройка виртуального хостинга:

# WordPress multisite subdirectory rules.
# Designed to be included in any server {} block.

# This order might seem weird - this is attempted to match last if rules below fail.
# http://wiki.nginx.org/HttpCoreModule
location / {
	try_files $uri $uri/ /index.php?$args;
}

# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;

# Directives to send expires headers and turn off 404 error logging.
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
	expires 24h;
	log_not_found off;
}

# Pass uploaded files to wp-includes/ms-files.php.
rewrite /files/$ /index.php last;

# For multisite:  Use a caching plugin/script that creates symlinks to the correct subdirectory structure to get some performance gains.
set $cachetest "$document_root/wp-content/cache/ms-filemap/${host}${uri}";
if ($uri ~ /$) {
	set $cachetest "";
}
if (-f $cachetest) {
	# Rewrites the URI and stops rewrite processing so it doesn't start over and attempt to pass it to the next rule.
	rewrite ^ /wp-content/cache/ms-filemap/${host}${uri} break;
}

if ($uri !~ wp-content/plugins) {
	rewrite /files/(.+)$ /wp-includes/ms-files.php?file=$1 last;
}

# Uncomment one of the lines below for the appropriate caching plugin (if used).
# include global/wordpress-ms-subdir-wp-super-cache.conf;
# include global/wordpress-ms-subdir-w3-total-cache.conf;

# Rewrite multisite '.../wp-.*' and '.../*.php'.
if (!-e $request_filename) {
	rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 last;
	rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$ $1 last;
}

# Pass all .php files onto a php-fpm/php-fcgi server.
location ~ \.php$ {
	# Zero-day exploit defense.
	# http://forum.nginx.org/read.php?2,88845,page=3
	# Won't work properly (404 error) if the file is not stored on this server, which is entirely possible with php-fpm/php-fcgi.
	# Comment the 'try_files' line out if you set up php-fpm/php-fcgi on another machine.  And then cross your fingers that you won't get hacked.
	try_files $uri =404;

	fastcgi_split_path_info ^(.+\.php)(/.+)$;
	include fastcgi_params;
	fastcgi_index index.php;
	fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
#	fastcgi_intercept_errors on;
	fastcgi_pass php;
}

# WordPress multisite subdirectory rules.

# Designed to be included in any server {} block.

# This order might seem weird - this is attempted to match last if rules below fail.

# http://wiki.nginx.org/HttpCoreModule

location / {

try_files $uri $uri/ /index.php?$args;

}

# Add trailing slash to */wp-admin requests.

rewrite /wp-admin$ $scheme://$host$uri/ permanent;

# Directives to send expires headers and turn off 404 error logging.

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {

expires 24h;

log_not_found off;

}

# Pass uploaded files to wp-includes/ms-files.php.

rewrite /files/$ /index.php last;

# For multisite: Use a caching plugin/script that creates symlinks to the correct subdirectory structure to get some performance gains.

set $cachetest "$document_root/wp-content/cache/ms-filemap/${host}${uri}";

if ($uri ~ /$) {

set $cachetest "";

}

if (-f $cachetest) {

# Rewrites the URI and stops rewrite processing so it doesn't start over and attempt to pass it to the next rule.

rewrite ^ /wp-content/cache/ms-filemap/${host}${uri} break;

}

if ($uri !~ wp-content/plugins) {

rewrite /files/(.+)$ /wp-includes/ms-files.php?file=$1 last;

}

# Uncomment one of the lines below for the appropriate caching plugin (if used).

# include global/wordpress-ms-subdir-wp-super-cache.conf;

# include global/wordpress-ms-subdir-w3-total-cache.conf;

# Rewrite multisite '.../wp-.*' and '.../*.php'.

if (!-e $request_filename) {

rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 last;

rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$ $1 last;

}

# Pass all .php files onto a php-fpm/php-fcgi server.

location ~ \.php$ {

# Zero-day exploit defense.

# http://forum.nginx.org/read.php?2,88845,page=3

# Won't work properly (404 error) if the file is not stored on this server, which is entirely possible with php-fpm/php-fcgi.

# Comment the 'try_files' line out if you set up php-fpm/php-fcgi on another machine. And then cross your fingers that you won't get hacked.

try_files $uri =404;

fastcgi_split_path_info ^(.+\.php)(/.+)$;

include fastcgi_params;

fastcgi_index index.php;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

# fastcgi_intercept_errors on;

fastcgi_pass php;

}

Для WP Super Cache:

# WP Super Cache rules.
# Designed to be included from a 'wordpress-ms-...' configuration file.

# Enable detection of the .gz extension for statically compressed content.
# Comment out this line if static gzip support is not compiled into nginx.
gzip_static on;

set $supercacheuri "";
set $supercachefile "$document_root/wp-content/cache/supercache/${http_host}${uri}index.html";
if (-e $supercachefile) {
	set $supercacheuri "/wp-content/cache/supercache/${http_host}${uri}index.html";
}

# If this is a POST request, pass the request onto WordPress.
if ($request_method = POST) {
	set $supercacheuri "";
}

# If there is a query string, serve the uncached version.
if ($query_string) {
	set $supercacheuri "";
}

# Logged in users and those who have posted a comment get the non-cached version.
if ($http_cookie ~* comment_author_|wordpress_logged_in|wp-postpass_) {
	set $supercacheuri "";
}

# Mobile browsers get the non-cached version.
# Wastes CPU cycles if there isn't a mobile browser WP theme for the site.
if ($http_x_wap_profile) {
	set $supercacheuri "";
}

if ($http_profile) {
	set $supercacheuri "";
}

if ($http_user_agent ~* (2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800)) {
	set $supercacheuri "";
}

if ($http_user_agent ~* (w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-)) {
	set $supercacheuri "";
}

# Stop processing if the supercache file is valid.
if ($supercacheuri) {
	rewrite ^ $supercacheuri break;
}

# WP Super Cache rules.

# Designed to be included from a 'wordpress-ms-...' configuration file.

# Enable detection of the .gz extension for statically compressed content.

# Comment out this line if static gzip support is not compiled into nginx.

gzip_static on;

set $supercacheuri "";

set $supercachefile "$document_root/wp-content/cache/supercache/${http_host}${uri}index.html";

if (-e $supercachefile) {

set $supercacheuri "/wp-content/cache/supercache/${http_host}${uri}index.html";

}

# If this is a POST request, pass the request onto WordPress.

if ($request_method = POST) {

set $supercacheuri "";

}

# If there is a query string, serve the uncached version.

if ($query_string) {

set $supercacheuri "";

}

# Logged in users and those who have posted a comment get the non-cached version.

if ($http_cookie ~* comment_author_|wordpress_logged_in|wp-postpass_) {

set $supercacheuri "";

}

# Mobile browsers get the non-cached version.

# Wastes CPU cycles if there isn't a mobile browser WP theme for the site.

if ($http_x_wap_profile) {

set $supercacheuri "";

}

if ($http_profile) {

set $supercacheuri "";

}

if ($http_user_agent ~* (2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800)) {

set $supercacheuri "";

}

if ($http_user_agent ~* (w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-)) {

set $supercacheuri "";

}

# Stop processing if the supercache file is valid.

if ($supercacheuri) {

rewrite ^ $supercacheuri break;

}

Источник: https://wordpress.org/support/topic/nginx-php-fpm-php-apc-wordpress-multisite-subdirectory-wp-super-cache

Ubuntu: установка и настройка связки nginx + apache + php + mysql

Posted on 13.10.2015 by rudjuk 10 комментариев

В это статье я расскажу как быстро развернуть LAMP сервер на Ubuntu с кеширующим nginx

Для всех команд необходим sudo, потому сразу войдем для удобства в этот режим:

sudo su

sudo su

Далее, обновляем данные из репозитариев:

apt-get -y update

1	apt-get -y update

Установка MySQL сервер:

apt-get install mysql-server mysql-client

1	apt-get install mysql-server mysql-client

Во время установки нас попросят ввести пароль root для сервера MySQL, вводим 2 раза. Дожидаемся окончания установки.

Установка Apache, nginx, php:

apt-get install apache2 nginx apache2-mpm-prefork apache2-utils libapache2-mod-php5 php5 php5-dev php5-mysql php5-common php5-curl php5-gd php5-idn php-pear php5-imagick php5-imap php5-mcrypt php5-mhash php5-ming php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl

1	apt-get install apache2 nginx apache2-mpm-prefork apache2-utils libapache2-mod-php5 php5 php5-dev php5-mysql php5-common php5-curl php5-gd php5-idn php-pear php5-imagick php5-imap php5-mcrypt php5-mhash php5-ming php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl

Дожидаемся окончания установки.
Включаем модули rewrite и include в apache2 при помощи утилиты — a2enmod:

a2enmod rewrite
a2enmod include

1 2	a2enmod rewrite a2enmod include

Меняем порт в apache2 со стандартного 80 на 8080 (2 строчки):

nano /etc/apache2/ports.conf
NameVirtualHost *:8080
Listen 8080

nano /etc/apache2/ports.conf

NameVirtualHost *:8080

Listen 8080

Создаем новый веб сервер (VirtualHost), создаем файл конфигурации:

touch /etc/apache2/sites-available/domain.com

1	touch /etc/apache2/sites-available/domain.com

И вставляем в него следующий текст:

<VirtualHost *:8080>
ServerName domain.com
ServerAlias www.domain.com
ServerAdmin admin@domain.com
DocumentRoot /var/www/domain.com
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/domain.com/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
ErrorLog /var/log/domain.com_error.log
LogLevel warn
CustomLog /var/log/domain.com_access.log combined
</VirtualHost>

ServerName domain.com

ServerAlias www.domain.com

ServerAdmin admin@domain.com

DocumentRoot /var/www/domain.com

Options FollowSymLinks

AllowOverride None

</Directory>

Options Indexes FollowSymLinks MultiViews

AllowOverride All

Order allow,deny

allow from all

</Directory>

ErrorLog /var/log/domain.com_error.log

LogLevel warn

CustomLog /var/log/domain.com_access.log combined

</VirtualHost>

Далее, создаем папку сайта и запускаем сайт:

mkdir -p /var/www/domain.com
a2ensite domain.com

1 2	mkdir -p /var/www/domain.com a2ensite domain.com

Проверяем в браузере — http://domain.com:8080

Конфигурируем nginx:

nano /etc/nginx/nginx.conf

1	nano /etc/nginx/nginx.conf

Приводим конфиг к такому виду:

    user www-data;
    worker_processes 4; #По количеству ядер
    pid /var/run/nginx.pid;
    error_log /sites/nginx/error.log;
    events {
    worker_connections 4096;
    multi_accept on;
    }

    http {

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    server_tokens off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    access_log /var/log/nginx-access.log;
    error_log /var/log/nginx-error.log;

    gzip on;
    gzip_disable «msie6″;
    gzip_proxied any;
    gzip_min_length 500;
    gzip_proxied expired no-cache no-store private auth;
    gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
    }

user www-data;

worker_processes 4; #По количеству ядер

pid /var/run/nginx.pid;

error_log /sites/nginx/error.log;

events {

worker_connections 4096;

multi_accept on;

}

http {

sendfile on;

tcp_nopush on;

tcp_nodelay on;

keepalive_timeout 65;

types_hash_max_size 2048;

server_tokens off;

include /etc/nginx/mime.types;

default_type application/octet-stream;

access_log /var/log/nginx-access.log;

error_log /var/log/nginx-error.log;

gzip on;

gzip_disable «msie6″;

gzip_proxied any;

gzip_min_length 500;

gzip_proxied expired no-cache no-store private auth;

gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;

include /etc/nginx/conf.d/*.conf;

include /etc/nginx/sites-enabled/*;

}

Далее создаем и правим конфиг нашего сайта:

nano /etc/nginx/sites-enabled/domain.com

1	nano /etc/nginx/sites-enabled/domain.com

Вносим в него следующие записи:

    upstream backend {
    server 127.0.0.1:8080;
    }
    server {
    listen 80;
    server_name domain.com www.domain.com;

    access_log /var/log/nginx-access.log;
    error_log /var/log/nginx-error.log;

    location / {
    proxy_pass http://backend;
    include /etc/nginx/proxy.conf;
    }
    location ~* .(jpg|jpeg|gif|png|ico|css|bmp|swf|js|mov|avi|mp4|mpeg4) {
    root /var/www/domain.com;
    }

    location ~ /.ht {
    deny all;
    }
    }

upstream backend {

server 127.0.0.1:8080;

}

server {

listen 80;

server_name domain.com www.domain.com;

access_log /var/log/nginx-access.log;

error_log /var/log/nginx-error.log;

location / {

proxy_pass http://backend;

include /etc/nginx/proxy.conf;

}

location ~* .(jpg|jpeg|gif|png|ico|css|bmp|swf|js|mov|avi|mp4|mpeg4) {

root /var/www/domain.com;

}

location ~ /.ht {

deny all;

}

Перезапускаем сервисы и проверяем работу:

service apache2 restart
service nginx restart

1 2	service apache2 restart service nginx restart

Источник: http://evolan.org/linux/ubuntu-ustanovka-i-nastrojka-svyazki-nginx-apache-php-mysql/

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Nginx, блокировка доступа по IP

Posted on 13.07.2015 by rudjuk Leave a comment

Продолжаем ковырять nginx и перекладывать на него функции с apache. В общем-то, у апача я давно не использую описанную здесь функцию, поэтому и забыл написать.

Формально, в nginx существует 2 способа ограничить доступ по ip. Первый — вполне привычные директивы — deny/allow. Второй — очень удобный для ограничения доступа в куче мест — geo переменные.

С deny/allow всё понятно, использовать их можно-нужно так же, как в любом другом веб-сервере:

deny 192.168.0.1; 
allow 192.168.0.1/24; 
allow 8.8.8.8; 
deny all;

deny 192.168.0.1;

allow 192.168.0.1/24;

allow 8.8.8.8;

deny all;

Эти строчки можно вписать почти в любой кусок конфига — начиная с http {} (тогда правила распространятся на весь сервер) и заканчивая отдельным location {}.

Второй способ уже интереснее и не встречается в apache. Как вы знаете, в nginx можно очень удобно работать с любыми переменными. А в переменные писать что угодно. Так вот — почему бы не делать что-либо в зависимости от того, какой IP адрес у посетителя? Прелесть такого варианта в том, что мы можем отдавать не 403ю ошибку, как в первом способе, а 404ю. Или редиректить на другой сайт. Или ещё-что нибудь… ну и так далее.

Собственно говоря, выглядит это так. Пишем в секцию http {} (для того, чтобы эту переменную мы могли использовать в любом server {} ):

geo $accessvar { 
default 0;
# 1 = бухгалтеры 
192.168.1.0/24 1; 
# 2 = манагеры 
192.168.2.0/24 2; 
# 3 = веб-серверы 
1.1.1.1 3; 
2.2.2.2 3; 
4.4.4.4 3; 
}

geo $accessvar {

default 0;

# 1 = бухгалтеры

192.168.1.0/24 1;

# 2 = манагеры

192.168.2.0/24 2;

# 3 = веб-серверы

1.1.1.1 3;

2.2.2.2 3;

4.4.4.4 3;

}

Что мы в итоге написали. Если кто-то придет из подсети 192.168.1.0/24 — то переменная $accessvar выставляется в 1. Если из 192.168.2.0/24 — то в 2. Если пришла машина с IP адресом 1.1.1.1/2.2.2.2/4.4.4.4 — то переменная выставляется в 3. Если какой-то другой адрес — то 0.
При помощи if-ов мы можем юзать эти штуки уже как угодно. Например, у нас есть сайт internal.company.name для сотрудников (и для серверов, чтобы они забирали оттуда какую-либо информацию для обновления сайтов). И сайт compmany.com, на который должны попадать посетители.
Случайных посетителей сайта internal будем редиректить на правильный сайт:

server { 
... 
if ($accessvar = 0) 
{ 
  rewrite ^/(.*) http://company.name permanent; 
} 
... 
}

server {

...

if ($accessvar = 0)

{

rewrite ^/(.*) http://company.name permanent;

}

...

}

Это, кстати, спасет и от надоедливых ботов, которые игнорируют robots.txt.
Далее. У нас есть 3 location:
/buh — сюда нам нужно пускать только бухгалтеров (ну там морда 1с, например)
/manager — сюда только менеджеров
/export — сюда только серверы.

Представляете, какой вам ад пришлось бы разводить в конфигах, чтобы добиться этого с access/deny )? А тут вам нужно только поддерживать актуальный список адресов в одном месте. Можно сочетать с VPN, чтобы адреса точно нужные были =)

server { 
... 
location /buh { 
  if ($accessvar != 1) { 
      return 404; 
  } 

  location /manager{ 
   if ($accessvar != 2) { 
      return 404; 
   } 

   location /export { 
    if ($accessvar != 3) { 
      return 404; 
   } 
... 
}

server {

...

location /buh {

if ($accessvar != 1) {

return 404;

}

location /manager{

if ($accessvar != 2) {

return 404;

}

location /export {

if ($accessvar != 3) {

return 404;

}

...

}

Ну и не забываем порестартить nginx:

/etc/init.d/nginx restart

1	/etc/init.d/nginx restart

Помните, deny/access работает быстрее, но обладает очень узким функционалом. Но от ddos’a оно не спасет тоже — от ддоса лучше защищаться файрволлом. Поэтому переменные geo имеют право на существование. При этом они куда более удобны при правильном использовании. Кстати, можно создавать сразу именованные переменные — buh, manager, server, например =)

Джерело: https://debian.pro/726

Nginx

Защита файла wp-config.php в nginx

Posted on 26.06.2015 by rudjuk Leave a comment

А в т о р : Р у д ю к С . А .
https://corp2.net
E-Mail: rs@corp2.net

В файле wp-config.php CMS WordPress хранит пароли и логины для доступа к базе данных. Это очень безопасная информация. Есть вероятность, что в момент отладки приложения или веб-сервера данный файл может быть доступен злоумышленникам, поэтому, рекомендуется защищать данный файл от доступа в веб-серверах.

Защита в веб-сервере Apache указывается в файле .htaccess:

# Deny public access to wp-config.php
<Files wp-config.php>
    Order allow,deny
    Deny from all
</Files>

# Deny public access to wp-config.php

Order allow,deny

Deny from all

</Files>

Защита в веб-сервере Nginx:

# Deny public access to wp-config.php
location ~* wp-config.php { 
    deny all; 
}

# Deny public access to wp-config.php

location ~* wp-config.php {

deny all;

}

А в т о р : Р у д ю к С . А . https://corp2.net

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Безопасность WordPress. 3 самых эффективных способа защиты от брутфорса

Posted on 26.06.2015 by rudjuk Leave a comment

По статистике, около 19% от общего количества всех сайтов Интернета, работают на WordPress — это почти каждый пятый сайт. Успех платформы вполне логичен и закономерен, не зря еще 5 лет назад я сделал ставку именно на нее. Но сегодня речь пойдет не о преимуществах WordPress, а о его безопасности. Высокая популярность платформы активизировала злые силы, и вот уже на протяжении нескольких месяцев в Рунете идут массовые атаки на сайты, работающие на WordPress. Атаки настолько серьезные и настолько массовые, что не выдерживают даже самые мощные серверы. Хостинг-провайдеры, конечно, принимают меры, порой даже самые радикальные, вплоть до полной блокировки администраторских консолей WordPress. Поэтому, если вас еще не заблокировали, лучше самостоятельно провести ряд несложный действий по укреплению обороны вашего WordPress.

В этой статье я расскажу о самых эффективных способах защиты вашего сайта именно от брутфорса (brute force) — метода подбора и взлома пароля путем перебора всех теоретически возможных вариантов. Так как все последние массовые атаки работают по этому методу.

1. Первое с чего нужно начать — это избавиться от пользователя admin. Если у вас нет пользователя admin, можете сразу переходить к пункту 2. В WordPress начиная с 3 версии это делается очень просто. Достаточно создать нового пользователя, наделить его администраторскими правами, а старого пользователя «admin» — удалить. При его удалении, WordPress предложит вам выбрать нового пользователя, который станет автором публикаций старого администратора.

В старых версиях WordPress эта процедура проделывается с помощью пары SQL-запросов:

UPDATE wp_users SET user_login = 'Ваш новый логин' WHERE user_login = 'Admin';
UPDATE wp_posts SET post_author = 'Ваш новый логин' WHERE post_author = 'admin';

1 2	UPDATE wp_users SET user_login = 'Ваш новый логин' WHERE user_login = 'Admin'; UPDATE wp_posts SET post_author = 'Ваш новый логин' WHERE post_author = 'admin';

2. Очень важно обратить внимание на пароль администратора. Лучше если это будет хаотичная комбинация заглавных и строчных букв, знаков и цифр не менее чем из 10-12 символов.

3. При бутфорсе WordPress, производится огромное количество запросов к файлу авторизации «wp-login.php», и будет правильно обеспечить ему двойную защиту.

Если вы работаете с сайтом один, и ваш интернет-провайдер предоставляет вам статичный IP-адрес, вы можете разрешить доступ к директории «wp-admin» только с вашего IP-адреса, заблокировав тем самым для всех остальных даже возможность авторизации. Делается это следующим образом. В директории «wp-admin» создаем файл «.htaccess» следующего содержания:

order deny,allow
deny from all
allow from IP

order deny,allow

deny from all

allow from IP

Где IP — это ваш IP-адрес. Узнать его вы можете, например, здесь.

Если же, кроме вас с сайтом работают еще люди со статическими IP-адресами, вы можете просто добавить их в список ниже. Например, так:

order deny,allow
deny from all
allow from IP1
allow from IP2
allow from IP3

order deny,allow

deny from all

allow from IP1

allow from IP2

allow from IP3

Где, IP1, IP2, IP3 — разрешенные IP-адреса.

Благодаря этому, все пользователи (боты) с IP-адресами, не указанными в списке разрешенных, просто не получат доступа к директории «wp-admin» и, соответственно, не смогут брутфорсить файл «wp-login.php». Всем им будет возвращаться ошибка 403.

Если провайдер вам выдает динамический IP-адрес, меняющийся с каждым новым подключением к Интернету, тогда этот способ не пройдет, т.к «.htaccess» придется редактировать при каждом вашем подключении к Сети. С помощью все того же «.htaccess» мы можем установить дополнительную серверную HTTP-авторизацию. Делается это следующим образом.

Все в той же директории «wp-admin» создаются два файла: «.htaccess» и «.htpasswd». В первом будут храниться инструкции, во втором разрешенные данные для доступа к директории.

В «.htaccess» пишем следующее:

AuthType basic
AuthName 'Access Denied'
AuthUserFile '/fullpath/.htpasswd'
Require valid-user
DirectoryIndex index.php

AuthType basic

AuthName 'Access Denied'

AuthUserFile '/fullpath/.htpasswd'

Require valid-user

DirectoryIndex index.php

Где fullpath — полный путь к файлу «.htpasswd». Обратите на это должное внимание, т.к это самая частая ошибка. Полный путь вы можете узнать у своего хостинг-провайдера или с помощью небольшого php-скрипта:

$dir = dirname(__FILE__);
echo '<p>Полный путь: ' . $dir . '/</p>';

1 2	$dir = dirname(__FILE__); echo '<p>Полный путь: ' . $dir . '/</p>';

Или другим способом:

echo '<p>Полный путь: ' . $_SERVER['DOCUMENT_ROOT'] . '/</p>';

1	echo '<p>Полный путь: ' . $_SERVER['DOCUMENT_ROOT'] . '/</p>';

Если вы по каким-то причинам не хотите паролить всю директорию «wp-admin», вы можете запаролить непосредственно файл «wp-login.php». Делается это аналогично, но в «.htaccess» нужно написать следующее:

<filesmatch "wp-login.php"="">
AuthName 'Access Denied'
AuthType Basic
AuthUserFile '/fullpath/.htpasswd'
require valid-user
</filesmatch>

AuthName 'Access Denied'

AuthType Basic

AuthUserFile '/fullpath/.htpasswd'

require valid-user

</filesmatch>

Файл «.htpasswd» в обоих случаях должен выглядеть следующим образом:

username:password

1	username:password

Где username — это имя разрешенного пользователя, а password — это пароль. Обратите внимание, что пароль хранится в зашифрованном виде. Поэтому, предварительно ваш пароль нужно зашифровать. Сделать это можно, например, с помощью этого сервиса. На пароль действуют те же правила, что указаны в пункте 2 данной публикации.

Для использования нескольких пользователей с паролями, вы можете просто перечислить их по-порядку. Например, вот так:

username1:password1
username2:password2
username3:password3

username1:password1

username2:password2

username3:password3

Если вы сделаете все правильно, перед авторизацией в WordPress вам будет предложено ввести логин и пароль доступа к директории (файлу). И только после успешного входа вы сможете авторизоваться и войти в администраторскую консоль.

В Safari 6.0.5 на Mac OS это выглядит примерно так:

В других браузерах возможно немного иначе.

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

Дополнительные меры по защите WordPress

Дополнительно вы можете защитить таким же образом файл настроек WordPress «wp-config.php». Я бы рекомендовал его защитить, потому что в нем содержатся данные для подключения к БД MySQL. Делается это аналогично:

<files wp-config.php="">
order allow,deny
deny from all
</files>

order allow,deny

deny from all

</files>

Также, я бы рекомендовал вам проверить директории вашего сайта. Дело в том, что очень многие хостеры и безалаберные сисадмины не закрывают по-дефолту просмотр директорий сайтов своих клиентов. Если, к примеру, ввести в адресную строку браузера: http://вашсайт/wp-includes/ и вы увидете содержимое этой директории — нужно бить тревогу и срочно закрывать просмотр. Для этого можно создать в директориях, которые вы хотите закрыть от просмотра, пустые файлы «index.html» или дописать в ваш «.htaccess» всего одну строку:

Options All -Indexes

1	Options All -Indexes

Которая запретит серверу показывать содержимое директорий.

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

Их обзор в рамках данной публикации я проводить не буду.

Если в процессе настройки защиты WordPress от брутфорса у вас возникнут сложности — вы всегда можете обратиться ко мне за помощью. Контакты здесь.

Кстати

Оптимизация веб-сервера

Posted on 08.06.2015 by rudjuk Leave a comment

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

1. Оптимизация CMS-системы.

Как было показано опытами, которые я проводил несколько лет назад, наибольшая скорость загрузки и пропускная система — у статических файлов. Скорость cms-систем и статических файлов отличается в 1000-10 000 раз. Причем, это еще сильней сказывается при применении системы веб-сервера NGinx.

Зная это, я переработал систему кеширования в нашей cms-системе Корпорация 2 таким образом, чтоб генерировался статический сайт из динамического содержимого. Это дало значительный прирост скорости и значительное уменьшение нагрузки на сервере.

2. Оптимизация работы веб-сервера. Связка Apache-Nginx.

Мы давно практикуем систему 2-х уровневого веб-сервера. Эта система дает устойчивость к большому количеству посещений, и как результат — скорость работы веб-сервера.
3. Оптимизация работы базы данных. Связка PostgreSQL-PGBouncer.

Связка о которой многие забывают, но которая просто необходима при большом количестве работающих пользователей в online. Эта связка прекрасно себя проявила и сейчас реально у нас реально выдерживается более 500 пользователей в online. Причем, есть возможность выдерживать еще гораздо большие нагрузки!
4. Оптимизация работы с файлами Nginx.

Если не правильно настроить Nginx, то он будет загружать не нужной работой Apache. Поэтому, мы настроили Nginx так, чтоб он как можно реже переводил управление на Apache. В идеале — работая вообще без Apache!

5. Системы кеширования PHP. Остановились на xCache.

Значительное время веб-сервера тратится на компиляцию PHP-кода. Поэтому, я решил установить систему кеширования PHP-кода. Рассматривая ряд вариантов остановился на xCache. Но, ниже дам выдержки из статей для настройки нескольких разных систем кеширования php-кода. Может, в некоторых случаях, они будут более эффективны…

По настройке админки xcache, советую прочитать документацию: http://xcache.lighttpd.net/wiki/InstallAdministration

Установка и настройка xCache

Оптимизация работы вебсерверов, ускорение их работы тема очень интересная, возможности развернуться в этой области предостаточно, инструментов тоже хватает. XCache относится к средствам ускорения работы PHP. Устанавливается XCache как дополнительный модуль PHP и служит для кеширования результатов выполнения скриптов в шаред мемори. По сравнению с eAccelerator, XCache показывает более ощутимые результаты, но в проектах, где объемы кеша очень большие – не совсем подходит. Все таки оперативная память не бесконечна. Установим XCache из портов:

cd /usr/ports/www/xcache/
make install clean

При установке доступен диалог настройки сборки, с единственным пунктом Enable code coverage dumper, по умолчанию она включена и служит для определения.предотвращения переполнения памяти.
По окончании установки, нужно скопировать файл настройки xcache.ini в /usr/local/etc/php/:

cp /usr/local/share/examples/xcache/xcache.ini /usr/local/etc/php/

и немного исправить.
У меня получился такой файл настроек:

[xcache-common]
extension = xcache.so
#Включим админ интерфейс
[xcache.admin]
xcache.admin.enable_auth = On
xcache.admin.user = «admin»
#В качестве пароля укажем md5 хеш, создать его можно с
#помощью команды md5 -s «ваш пароль»
xcache.admin.pass = «XXXXXX»

[xcache]
xcache.shm_scheme = «mmap»
#Выделим для кеша 128 мегабайт
xcache.size = 128M
xcache.count = 1
xcache.slots = 8K
xcache.ttl = 0
xcache.gc_interval = 0
xcache.var_size = 0M
xcache.var_count = 1
xcache.var_slots = 8K
xcache.var_ttl = 0
xcache.var_maxttl = 0
xcache.var_gc_interval = 300
xcache.test = Off
xcache.readonly_protection = Off
xcache.mmap_path = «/dev/zero»
xcache.coredump_directory = «»
xcache.cacher = On
xcache.stat = On
xcache.optimizer = On

[xcache.coverager]
xcache.coverager = On
xcache.coveragedump_directory = «»

Настройка самого XCache закончена, остается сделать доступным админ интерфейс. Для этого я у себя скопировал /usr/local/share/examples/xcache/admin в документ рут своего вебсервера www.hilik.org.ua
После этого админ интерфейс станет доступным по URL http://www.hilik.org.ua/admin/
Конечно через этот интерфейс доступна только статистика, но все равно, это полезная функция.
Да и авторизация определена вами в xcache.ini.

Взято на сайте http://www.hilik.org.ua
Установка Eaccelerator

PHP — язык интерпретируемый. Это значит, что каждый раз, когда происходит вызов скрипта на этом языке, запускается PHP-интерпретатор, который проводит полный анализ исходного кода. Причем, если спустя секунду произойдет второй запуск того же скрипта, вся процедура будет повторена заново. Это нерациональное использование ресурсов, поэтому мы применим инструмент под названием eAccelerator, который скомпилирует исходные тексты PHP в двоичное представление, оптимизирует их и будет бережно хранить в оперативной памяти для более быстрого доступа. Благодаря только этому скорость обработки PHP-скриптов вырастет в десятки раз (подтверждено тестами).

Пакета eAccelerator нет в репозиториях популярных дистрибутивов, поэтому его придется собрать самостоятельно. Сначала устанавливаем необходимые для сборки утилиты:

$ sudo apt-get install php5-dev build-essential

Далее получаем исходные тексты eAccelerator:

$ cd /tmp/
$ wget http://bart.eaccelerator.net/source/0.9.6.1/
eaccelerator-0.9.6.1.tar.bz2
$ tar xvjf eaccelerator-0.9.6.1.tar.bz2
$ cd eaccelerator-0.9.6.1
$ phpize
$ ./configure —enable-eaccelerator=shared
$ make
$ sudo make install

Создаем каталог для хранения кэша:

$ sudo mkdir -p /var/cache/eaccelerator
$ sudo chmod 0777 /var/cache/eaccelerator
И, наконец, подключаем eAccelerator к PHP (добавить в начало файла):
# vi /etc/php5/apache2/php.ini
[PHP]
; Подключаем расширение
extension = «eaccelerator.so»
eaccelerator.enable = «1»
; Максимальный размер дискового кэша (Мб)
eaccelerator.shm_size = «64»
; Каталог для хранения кэша
eaccelerator.cache_dir = «/var/cache/eaccelerator»
; Включаем оптимизатор кода
eaccelerator.optimizer = «1»
; Перекомпилировать модифицированные скрипты
eaccelerator.check_mtime = «1»
; Отключаем режим отладки
eaccelerator.debug = «0»
; Кэшировать все файлы (пустой фильтр)
eaccelerator.filter = «»
; Неограниченный размер кэша в памяти
eaccelerator.shm_max = «0»
; В случае отсутствия места в кэше удалять объекты старше
1 часа (3600 секунд)
eaccelerator.shm_ttl = «3600»
eaccelerator.shm_prune_period = «0»
; Кэшировать данные и в памяти, и на диске
eaccelerator.shm_only = «0»
; Сжимать кэшированные данные с максимальным уровнем компрессии
eaccelerator.compress = «1»
eaccelerator.compress_level = «9»

Установка APC

Статья по адресу: http://phpcoder.ws/2009-02/apc-setup.html

APC (Alternative PHP Caching – это Альтернативный ПХП Кешер, руководство по использованию на английском языке). Входит в число трех наиболее популярных способов кеширования опкодов для выполненных php скриптов. Его ближайшими конкурентами являются XCache и eAccelerator. О последнем я уже писал недавно на этом блоге, а статья об XCache, который имеет несколько очень существенных преимуществ перед конкурентами, будет опубликована здесь в ближайшее время. Короче говоря, APC это еще один способ повысить быстродействие вашего сайта в том случае если он расположен на вашем сервере, вы являетесь админом своего хостинга и вас волнуют вопросы быстродействия размещенных на нем сайтов…

Установка APC

Одним из основных преимуществ APC является его простота установки. Если вы являетесь пользователем Debian/Ubuntu, то вполне вероятно что для установки вам будет достаточно набрать в консоли команду sudo aptitude install php-apc или установить этот пакет через synaptic. Если вы используете другой дистрибутив, или по какой-то причине не можете установить “родной” deb-пакет, то у вас есть другой путь – установка из PECL. Для этого нужно набрать команду: sudo pecl install apc, которая скачает нужные архивы из сети, распакует, откомпилирует и установит полученный файл apc.so в нужную директорию.
Проверка установки APC

Во-первых, проверьте что строчка загрузки расширения extension=apc.so действительно прописалась в php.ini (или создан файл apc.ini с этой строчкой в папке с конфигами расширений php – зависит от вашего дистрибутива. Для Debian, например, этой папкой будет /etc/php5/apache2/conf.d/

Если строчка успешно найдена/добавлена, то перезапускаем сервер apache и переходим к проверке самого расширения. Для этого находим папку в которую было установлено расширение. В этой папке будет лежать файл apc.php (файл так же можно взять в архиве установки), копируем его в public директорию любого из сайтов на этом веб-сервере и заходим браузером по адресу http://сайт/apc.php. Если расширение было установлено корректно, то вы увидите на загруженной странице статистику по APC (скриншоты приведены ниже).
Общая информация об APC

Общая информация об APC
Подробная информация об APC

Подробная информация об APC
Информация о хосте

Информация о хосте
Замеры изменения производительности

Для проверки была выбрана CMS Joomla1.5.9 с демонстрационным набором данных после установки и с шаблоном дизайна по умолчанию. При тестировании производительности при помощи утилиты ab2 (было выполнено 1000 обращений к главной странице сайта в 5 потоков) скорость генерации страниц увеличилась на 40%
Недостатки APC

Объективности ради отмечу и недостатки APC…

* отсутствует поддержка FastCGI
* кеширование работает только с модулем apache mod_php (в режиме cli ускорения не будет)
* работает с версиями PHP<=5.2 С версией 5.3 отмечаются проблемы, а что касается 6.0 — будущее совсем туманно. Возможно какой-то механизм кеширования будет интегрирован в само ядро…

Заключение

По-моему стоит установить APC на своем веб-сервере и попробовать – подойдет ли оно именно вам. Несмотря на ряд описанных выше ограничений APC считается наиболее надежным из тройки основных реализаций кеширования для языка PHP…

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

2-й экземпляр apache

Posted on 08.06.2015 by rudjuk Leave a comment

А в т о р : Р у д ю к С . А .
https://corp2.net
E-Mail: rs@corp2.net

Иногда, возникает необходимость запустить 2-ю копию apache. Понятное дело, хочется использовать один и тот же исполняемый файл apache и не заниматься установкой различных версий продукта.

Определимся, чем должны, отличаться наши экземпляры.
Это конфигурационными файлами:
/etc/apache2/apache2.conf — указаны порты и специфичные для каждого из Апачей виртуальные хосты
/etc/apache2/ports.conf — содержит прослушиваемые порты.
/etc/apache2/envvars — путь к файлу для сохранения pid запущенного демона.

Стоит разделить логи директивами в в apache2.conf:
ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/other_vhosts_access.log vhost_combined

Идем в папку init скриптов:
cd /etc/init.d

Создаем копию init скрипта родного Apache:
cp apache2 apache2_srv

Где apache2_srv — это название нового экземпляра Apache.

Сразу Добавляем фейловер Апача в автозапуск:
update-rc.d apache2_srv defaults

Корректируем скрипт apache2_srv:

Вместо блока:
PIDFILE=. /etc/apache2/envvars ; echo $APACHE_PID_FILE
if [ -z «$PIDFILE» ] ; then
echo ERROR: APACHE_PID_FILE needs to be defined in /etc/apache2/envvars >&2
exit 2
fi

Вставляем:
PIDFILE=. /etc/apache2/envvars_apache2_srv ; echo $APACHE_PID_FILE
if [ -z «$PIDFILE» ] ; then
echo ERROR: APACHE_PID_FILE needs to be defined in /etc/apache2/envvars_apache2_srv >&2
exit 2
fi

Чуть выше корректируем ENV:
ENV=»env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin APACHE_ENVVARS=/etc/apache2/envvars_apache2_srv»

Корректируем конфиги:
cp /etc/apache2/envvars /etc/apache2/envvars_apache2_srv

Заменяем
export APACHE_PID_FILE=/var/run/apache2.pid
на
export APACHE_PID_FILE=/var/run/apache2_apache_2.pid

Создаем файл портов /etc/apache2/ports_apache_srv.conf:
В нем пишем:
Listen 81

Создаем файлы логов:
touch /var/log/apache2/error_apache2_srv.log
touch /var/log/apache2/other_vhosts_access_apache2_srv.log
chown root:root /var/log/apache2/other_vhosts_access_apache2_srv.log
chown root:adm /var/log/apache2/error_apache2_srv.log
chmod 640 /var/log/apache2/error_apache2_srv.log

Теперь давайте посмотрим, как осуществляется управление демоном Апача. Сразу скажу, что кэш мы не используем и следовательно «check_htcacheclean» всегда будет выдавать ложь.
Запуск:

start)
log_daemon_msg «Starting web server» «apache2»
if $APACHE2CTL start; then
if check_htcacheclean ; then
log_progress_msg htcacheclean
start_htcacheclean || log_end_msg 1
fi
log_end_msg 0
else
log_end_msg 1
fi
;;

То есть все вопросы к: $APACHE2CTL, его мы будем использовать не как SysV инит скрипт, а будем им проксировать все наши вопросы к apache

Для этого в верху скрипта делаем замену:

APACHE2CTL=»$ENV /usr/sbin/apache2ctl»

на

APACHE2CTL=»$ENV /usr/sbin/apache2ctl -f /etc/apache2/apache2_srv.conf»

Далее изменяем все параметры вызов APACHE2CTL:

$APACHE2CTL start на $APACHE2CTL -k start
$APACHE2CTL stop на $APACHE2CTL -k stop
$APACHE2CTL graceful на $APACHE2CTL -k graceful
$APACHE2CTL configtest на $APACHE2CTL -t

Теперь надо скорректировать функцию pidof_apache, иначе при stop мы будем убивать всех Апаче разом:

Делаем замену:

pidof_apache() {
# if pidof is null for some reasons the script exits automagically
# classified as good/unknown feature
PIDS=pidof apache2 || true

на:

pidof_apache() {
# if pidof is null for some reasons the script exits automagically
# classified as good/unknown feature
PIDS=ps aux | grep 'apache2_srv' | grep -v 'grep' | awk '{print $2}' | xargs || true

Теперь попробуем запустить второго Апача:

/etc/init.d/apache2_srv start
Starting web server: apache2apache2: Could not open configuration file /etc/apache2/apache2_failover.conf: No such file or directory
failed!

Теперь необходимо на основе apache2.conf составить /etc/apache2/apache2_srv.conf

Скопируем оригинал

cp /etc/apache2/apache2.conf /etc/apache2/apache2_srv.conf

И далее корректируем пути к файлами, которые обсуждали выше.

CustomLog /var/log/apache2/other_vhosts_access_apache2_srv.log vhost_combined
ErrorLog /var/log/apache2/error_apache2_srv.log
Include /etc/apache2/ports_apache2_srv.conf

Теперь надо поменять порты у директив NameVirtualHost xx.xx.xx.xx:80 и VirtualHost xx.xx.xx.xx:81.

Повторяем попытку запуска:

/etc/init.d/apache2_srv start
Starting web server: apache2.

А в т о р : Р у д ю к С . А . https://corp2.net

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Налаштування Nginx – PHP-FPM для роботи багато-сайтовості в WordPress

Posted on 08.06.2015 by rudjuk Leave a comment

По замовчуванню, WordPress працює в одно-сайтовому режимі. Якщо Ви бажаєте включити багато-сайтовість, то зробіть наступні дії:

1. Відкрийте файл wp-config.php. В нього додайте програмний код:

/* Multisite */
define( 'WP_ALLOW_MULTISITE', true );

1 2	/* Multisite */ define( 'WP_ALLOW_MULTISITE', true );

2. Налаштуйте мережу. Для цього, зайдіть в Administration > Tools > Network Setup (Инструменты — Установка сети).

3. WordPress вам повідомить скрипт, призначений для роботи в Apache2.

Скрипт для додавання в wp-config.php (він підходить як для нашого випадку, так і для Apache2).

define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'nerusoft.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

define('MULTISITE', true);

define('SUBDOMAIN_INSTALL', true);

define('DOMAIN_CURRENT_SITE', 'nerusoft.com');

define('PATH_CURRENT_SITE', '/');

define('SITE_ID_CURRENT_SITE', 1);

define('BLOG_ID_CURRENT_SITE', 1);

Скрипт для Apache2, який потрібно додати в файл .htaccess в корні сайту (не підходить для варіанта Nginx, бо від не виконує ці файли :))

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin

RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule ^ - [L]

RewriteRule ^(wp-(content|admin|includes).*) $1 [L]

RewriteRule ^(.*\.php)$ $1 [L]

RewriteRule . index.php [L]

Для зв’язки Nginx — PHP-FPM необхідно вставляти інший скрипт в налаштування домену Nginx. Цей скрипт різний в залежності від вибраної Вами схеми багато-сайтовості WordPress.

Скрипт для Nginx для багато-сайтового WordPress, що використовує підкаталоги:

map $uri $blogname{
 ~^(?P<blogpath>/[^/]+/)files/(.*) $blogpath ;
}
 
map $blogname $blogid{
 default -999;
 
 #Ref: http://wordpress.org/extend/plugins/nginx-helper/
 #include /var/www/wordpress/wp-content/plugins/nginx-helper/map.conf ;
}
 
server {
 server_name example.com ;
 
 root /var/www/example.com/htdocs;
 index index.php;
 
 location ~ ^(/[^/]+/)?files/(.+) {
  try_files /wp-content/blogs.dir/$blogid/files/$2 /wp-includes/ms-files.php?file=$2 ;
  access_log off; log_not_found off; expires max;
 }
 
 #avoid php readfile()
 location ^~ /blogs.dir {
  internal;
  alias /var/www/example.com/htdocs/wp-content/blogs.dir ;
  access_log off; log_not_found off; expires max;
 }
 
 if (!-e $request_filename) {
  rewrite /wp-admin$ $scheme://$host$uri/ permanent; 
  rewrite ^(/[^/]+)?(/wp-.*) $2 last; 
  rewrite ^(/[^/]+)?(/.*\.php) $2 last; 
 }
 
 location / {
  try_files $uri $uri/ /index.php?$args ;
 }
 
 location ~ \.php$ {
  try_files $uri =404;
  include fastcgi_params;
  fastcgi_pass php;
 }
 
 #add some rules for static content expiry-headers here
}

map $uri $blogname{

~^(?P<blogpath>/[^/]+/)files/(.*) $blogpath ;

}

map $blogname $blogid{

default -999;

#Ref: http://wordpress.org/extend/plugins/nginx-helper/

#include /var/www/wordpress/wp-content/plugins/nginx-helper/map.conf ;

}

server {

server_name example.com ;

root /var/www/example.com/htdocs;

index index.php;

location ~ ^(/[^/]+/)?files/(.+) {

try_files /wp-content/blogs.dir/$blogid/files/$2 /wp-includes/ms-files.php?file=$2 ;

access_log off; log_not_found off; expires max;

}

#avoid php readfile()

location ^~ /blogs.dir {

internal;

alias /var/www/example.com/htdocs/wp-content/blogs.dir ;

access_log off; log_not_found off; expires max;

}

if (!-e $request_filename) {

rewrite /wp-admin$ $scheme://$host$uri/ permanent;

rewrite ^(/[^/]+)?(/wp-.*) $2 last;

rewrite ^(/[^/]+)?(/.*\.php) $2 last;

}

location / {

try_files $uri $uri/ /index.php?$args ;

}

location ~ \.php$ {

try_files $uri =404;

include fastcgi_params;

fastcgi_pass php;

}

#add some rules for static content expiry-headers here

}

Скрипт для Nginx, що використовує багато-доменність для WordPress:

map $http_host $blogid {
    default       -999;
 
    #Ref: http://wordpress.org/extend/plugins/nginx-helper/
    #include /var/www/wordpress/wp-content/plugins/nginx-helper/map.conf ;
 
}
 
server {
 server_name example.com *.example.com ;
 
 root /var/www/example.com/htdocs;
 index index.php;
 
 location / {
  try_files $uri $uri/ /index.php?$args ;
 }
 
 location ~ \.php$ {
  try_files $uri =404;
  include fastcgi_params;
  fastcgi_pass php;
 }
 
 #WPMU Files
        location ~ ^/files/(.*)$ {
                try_files /wp-content/blogs.dir/$blogid/$uri /wp-includes/ms-files.php?file=$1 ;
                access_log off; log_not_found off;      expires max;
        }
 
 #WPMU x-sendfile to avoid php readfile()
 location ^~ /blogs.dir {
  internal;
  alias /var/www/example.com/htdocs/wp-content/blogs.dir;
  access_log off; log_not_found off; expires max;
 }
 
 #add some rules for static content expiry-headers here
}

map $http_host $blogid {

default -999;

#Ref: http://wordpress.org/extend/plugins/nginx-helper/

#include /var/www/wordpress/wp-content/plugins/nginx-helper/map.conf ;

}

server {

server_name example.com *.example.com ;

root /var/www/example.com/htdocs;

index index.php;

location / {

try_files $uri $uri/ /index.php?$args ;

}

location ~ \.php$ {

try_files $uri =404;

include fastcgi_params;

fastcgi_pass php;

}

#WPMU Files

location ~ ^/files/(.*)$ {

try_files /wp-content/blogs.dir/$blogid/$uri /wp-includes/ms-files.php?file=$1 ;

access_log off; log_not_found off; expires max;

}

#WPMU x-sendfile to avoid php readfile()

location ^~ /blogs.dir {

internal;

alias /var/www/example.com/htdocs/wp-content/blogs.dir;

access_log off; log_not_found off; expires max;

}

#add some rules for static content expiry-headers here

}

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Nginx
PHP