apache выдаёт ошибку

[cc lang=”bash”]
[crit] (28)No space left on device: mod_rewrite: could not create rewrite_log_lock[/cc]

На что помогла уличная консольная магия

[cc lang=”bash”]ipcs -s | grep www | perl -e ‘while () { @a=split(/\s+/);
print `ipcrm sem $a[1]`}’
[/cc]
Где www это имя пользователя от которого работает Apache
У меня это www-data

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘USING BTREE

Когда мне mysql заругался на дамп сайта вот такой строкой

[cc lang=”bash”]You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘USING BTREE[/cc]

Я показал ему магию, уличную консольную магию

[cc lang=”bash”]sed -i -r ‘s/\(([^)]+)\) USING BTREE/USING BTREE (\1)/g’ backup.sql[/cc]

После чего дамп съелся наура 🙂

Дружим nginx + ssl

Понадобилось к одному из сайтов прикрутить ssl
Напомню, что nginx у меня выступает как фронт-энд к Apache2
чтоб в дальнейшем было меньше проблем, при отказе от apache2 доверим шифрование nginx

Для этого создаём конфигурационный файл

[cc lang=”bash”]touch /etc/nginx/ssl.conf[/cc]

Добавляем в него содержимое
[cc lang=”bash”]# Подключение самоподписанного сертификата
# генерация сертификата:
# openssl req -new -x509 -days 9999 -nodes -out cert.pem -keyout cert.key

ssl on;
ssl_protocols SSLv3 TLSv1;
ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/cert.key;
[/cc]

Создадим папку где будем хранить сертификаты:

[cc lang=”bash”]mkdir /etc/nginx/ssl[/cc]

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

[cc lang=”bash”]chown www-data:www-data /etc/nginx/ssl
chmod 700 /etc/nginx/ssl[/cc]

Перейдем в эту папку и с генерируем сертификат:

[cc lang=”bash”]cd /etc/nginx/ssl
openssl req -new -x509 -days 9999 -nodes -out cert.pem -keyout cert.key[/cc]

При генерации вас попросят указать некоторые данные, заполнять не обязательно но желательно.

Теперь добавим в конфигурацию Виртального хоста в секцию server

[cc lang=”bash”] listen 443; # порт https
include /etc/nginx/ssl.conf; # подключение конфигурации ssl[/cc]

Дальше для примера привожу итоговый вариант файла конфигурации.
[cc lang=”bash”]
server {
listen 80;
listen 443;
server_name domen.ru www.domen.ru;
include /etc/nginx/ssl.conf; # подключение конфигурации ssl

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

location / {
proxy_pass http://127.0.0.1:8086/;
proxy_redirect off;
proxy_set_header Host $host;
………….
…………
……….[/cc]

проверяем
[cc lang=”bash”]nginx -t[/cc]

Если всё Ok то перезапускаем nginx и радуемся

как найти спаммера в LAN сети

Перестали уходить письма с почтового сервера с вот таким сообщением

[cc lang=”bash”]Subject: Undelivered Mail Returned to Sender

This is the mail system at host example.ru.

I’m sorry to have to inform you that your message could not
be delivered to one or more recipients. It’s attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

: host mail.blabla.ru[89.188.122.122] said: 554 5.7.1
Service unavailable; Client host [111.111.176.99] blocked using
cbl.abuseat.org; Blocked – see
http://cbl.abuseat.org/lookup.cgi?ip=111.111.176.99 (in reply to RCPT TO
command)[/cc]

Сеть за нашим натом большая, и вполне возможно кто-то подхватил троян.
Как найти кто?

Сначала смотрим начнём вести лог кто пользуется 25м портом шлюза
[cc lang=”bash”]iptables -A FORWARD -p tcp -m tcp -s 192.168.0.0/16 –dport 25 -j LOG –log-level debug –log-prefix “outgoing mail “[/cc]

Теперь посмотрим кто будет нам светится.
[cc lang=”bash”]tail -f /var/log/syslog | grep outgoing[/cc]

Долго ждать не пришлось, супермега активность идёт от.[cc lang=”bash”]
Nov 12 09:38:57 kernel: [1502790.410756] outgoing mail IN=eth0 OUT=eth1 SRC=192.168.5.133 DST=205.188.186.137 LEN=54 TOS=0x00 PREC=0x00 TTL=127 ID=47636 DF PROTO=TCP SPT=4779 DPT=25 WINDOW=64886 RES=0x00 ACK PSH URGP=0
Nov 12 09:38:57 kernel: [1502790.607265] outgoing mail IN=eth0 OUT=eth1 SRC=192.168.5.133 DST=205.188.186.137 LEN=58 TOS=0x00 PREC=0x00 TTL=127 ID=47671 DF PROTO=TCP SPT=4779 DPT=25 WINDOW=64868 RES=0x00 ACK PSH URGP=0
Nov 12 09:38:57 kernel: [1502790.833908] outgoing mail IN=eth0 OUT=eth1 SRC=192.168.5.133 DST=205.188.186.137 LEN=70 TOS=0x00 PREC=0x00 TTL=127 ID=47706 DF PROTO=TCP SPT=4779 DPT=25 WINDOW=64804 RES=0x00 ACK PSH URGP=0[/cc]

идём лечим комп от вирусов.

Дальше на будущее можно поставить так
Создаём цепочку
[cc lang=”bash”]
iptables -N LOGDROP > /dev/null 2> /dev/null
iptables -F LOGDROP
iptables -A LOGDROP -j LOG –log-prefix “LOGDROP ”
iptables -A LOGDROP -j DROP[/cc]

И направляем его в эту цепочку
[cc lang=”bash”]iptables -A FORWARD -p tcp -s 192.168.5.133 –dport 25 -j LOGDROP[/cc]

Переезжаем на php5+fpm

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

Сегодня решил один из своих сайтов перевести со связки nginx – Apache2+mod_php5 на nginx+php5-fpm в надежде, что появятся свободные ресурсы, которые сервер сможет тратить на mysql.

Введя в гугл запрос “ubuntu nginx php-fpm” я начал понимать, что предложенные варианты мне не подходят, т.к. я хотел перевести всего один из пару десятков сайтов, а все остальные продолжали работать на apache2.

Второе условие, что сайт у меня на wordpress и он должен заработать с прежним функционалом.

Я уже ранее писал, что я перешёл на PHP5.3 и вот ещё боялся ставить php-fpm версий меньше чем 5.3 т.к. не знал, а всё ли заработает, но сильно не задумываясь я решил проверить есть ли php-fpm в репозиториях? ну и разумеет оказался, как раз в тех, откуда я ставил PHP 5.3

и так поехали

[cc lang=”bash”]apt-get install php-fpm[/cc]

Он успешно устанавливается, связка nginx+apache2 у меня была настроена по вот этим статьям
Раз – компилируем сам nginx и два связываем всё во едино (пропуская установку из пакета)

Теперь я хочу один из virtualhost’ов заменить.
Делаю резервную копию старого конфига и начинаю собирать новый.
Времени я потратил много.
Основная беда была в том, что повсеместно используется mod_rewrite для Apache, и теперь надо заставить работать правила но уже на nginx. Снова гугл и снова по крупицам воссоздал конфиг, который работает для wordpress
и так привожу конфиг
/etc/nginx/sites-available/mysite

[cc lang=”bash”]
server {
listen 80;
server_name www.mysite.ru mysite.ru;

access_log /var/log/nginx/mysite/access1.log;
error_log /var/log/nginx/mysite/error1.log error;

index index.php;
root /var/www/mysite;
location / {
try_files $uri $uri/ @wordpress;
}

location @wordpress {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_NAME /index.php;
}

location ~ \.php$ {
try_files $uri @wordpress;
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
}

}
[/cc]

Сохраняем, проверяем nginx на ошибки синтаксиса.
[cc lang=”bash”]nginx -t[/cc]
Если скажет, что ошибок нет, идём дальше – запускаем php5-fpm
[cc lang=”bash”] /etc/init.d/php5-fpm start[/cc]
Теперь можно перезапустить nginx и пробовать зайти на свой сайт.
я столкнулся с ошибками, пол шаблона wordpress была свёрстана с вот такими тегами
Когда должно быть
Поправил нужные места, потом пошёл отредактировал новый php.ini который находится вот тут
[cc lang=”bash”]/etc/php5/fpm[/cc]

Собственно вся история, легче или сложнее жить я пока не заметил надо наблюдать, смотреть на графики и т.п.
итог wordpress заработал на php-fpm ^)

Ах чуть не забыл есть ещё плагин для wordpress, который дружит его с nginx
_http://wordpress.org/extend/plugins/nginx-compatibility/
я им воспользовался, но не знаю нужен он был или нет