Просьба оставить комментарий





Если вам понравился или не понравился топик. Я что то забыл или не дописал, то вы можете оставить свой комментарий и я постараюсь исправить это в ближайшее время.

среда, 29 февраля 2012 г.

Защита phpbb от регистрации ботов и спама

Очень долго бился с тем как закрыть доступ ботам к своим форумам на phpbb. Все встроенные средства естественно не помогают. Установка активации аккаунта по email, ограничение сообщений для новых пользователей не помогало. Даже самый не любимый способ установка recaptcha и то не помог в этом деле. Когда количество спама начало превышать 20 сообщений в день решил искать кардинальное решение этой проблемы.

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

Итак решение для версии 3 движка phpbb прописать в низу файла config.php следующий код:

if (isset($_POST['password_confirm']) && isset($_POST['tz'])){ // Пришел запрос на регистрацию
    if(
        $_POST['tz'] == -12 || // Нереальная временная зона которую по умолчанию отправляют роботы
        ($_POST['lang'] == 'en' && $_POST['change_lang'] != 'en') || // Изменен основной язык, но change_lang при это не изменен
        ($_POST['lang'] == 'en' && $_POST['submit'] == 'Отправить') // Язык вроде английский, а кнопка почему-то русская
    ){
        header("HTTP/1.1 404 Not Found");
        exit;
    }
}

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

понедельник, 27 февраля 2012 г.

Установка приложений apk на Android с флешки


1. Устанавливаем на планшет/мобильный с помощью программы маркет, приложение из категории ИНСТРУМЕНТЫ - ES Проводник(ES Explorer), с помощью которого вы сможете просматривать все доступные папки и файлы на вашем устройстве.

2. Запускаем ES Проводник, нажимаем на значок в виде microSD флешки, открывается много папок (acct, cache,config…). Ищем и переходим в папку mnt -> usb_storage (это и есть содержимое вашей флешки).

3. Находите нужный файл с расширением .apk (в виде пиктограммы) и запускаете его.
Если вы делаете это первый раз система выдаст окно с заголовком: "Установка заблокирована" и содержанием: "Из соображений безопасности на вашем телефоне заблокирована установка приложений, полученных не из Android-маркета". Нажимаете кнопку Настройки, откроется окно настроек, справа найдите строку Неизвестные источники (Разрешить установку приложений, полученных не из Маркета), ставим тут галочку, соглашаемся с предупреждением о том что планшет станет более уязвим, нажав кнопку ОК, и переходим в предыдущее окно. Снова запускаем пиктограмму скачанного в папку файла .apk, после чего жмем кнопку установить.
Если уже галка стоит, то установка начнется сразу же без предупреждения.

воскресенье, 19 февраля 2012 г.

Репликация баз данных MySQL по типу Master-Slave Часть 2: Внедрение

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

1. Итак у нас должен быть рабочий сервер с базой данной mysql, желательно схожей версии выше 5.0.
Сам сервер нужен чтобы смог справиться с подобной нагрузкой на головной сервер либо лучше. Я использовал физический сервер более мощной конфигурации, чем головной виртуальный.

2. Закомментируем строку в файлах my,cnf bind-address = 127.0.0.1 в этом случае доступ к базе будет как снаруже, так и изнутри.
Для безопасности вашего сервера так же рекомендуется в iptables на обоих серверах разрешить только доступ по порту базы данных только работающих в этой схеме серверов.

3. Создаем пользователя с правами на репликацию
GRANT FILE ON *.* TO repl@"%" IDENTIFIED BY '<password>'; 

Пароль для этого пользователя можно задать через phpMyAdmin либо соответствующую комманду в консоли.

4. На главном сервере в конфиге my.cnf надо добавить опции в [mysqld]
log-bin
server-id=xxx
Вместо xxx надо подставить разные значения на обоих серверах, приоритета никакого нет, но значения должны быть разными. Например 111 мастер, 222 слэйв.
На слейве за идентификацию  отвечает тот же параметр server-id его тоже надо внести в раздел [mysqld] на подчиненном сервере.
Для применения настроек сервер надо перезапустить.

5.1 Останавливаем основной сервер базы данных и делаем полный бэкап:
/etc/init.d/mysql stop
mysqldump --all-databases > all_databases.sql

 После окончания сброса баз данных в файл сервер мастера можно запустить.
/etc/init.d/mysql start

5.2 Как вариант базу можно не останавливать, а заблокировать запись командами
mysql@master> FLUSH TABLES WITH READ LOCK;
mysql@master> SET GLOBAL read_only = ON;
mysqldump --all-databases > all_databases.sql

   
5.3 Далее надо выполнить комманду mysql@master> show master status
 и записать полученные значения. Это очень важно так как здесь указывается какой журнал и какое событие является для подчиненного сервера началом репликации.
Файл журнала и номер позиции в этом журнале (Пример: Журнал: mysql-bin.000003 Позиция : 98)

5.4 Выполняем UNLOCK TABLES; SET GLOBAL read_only = OFF;

6. Копируем файл базы данных на подчиненный сервер.

7. В файле my.cnf слейва надо добавить несколько строк

master-host=<адрес головного сервера>
master-user=<имя пользователя репликации > в нашем случае repl
master-password=<пароль пользователя репликации > пароль который мы для него задали
master-port=<порт TCP/IP для головного сервера> стандартно 3306
server-id=<некоторое уникальное число между 2 и 2^32-1> заданный server-id (111)

8. Восстанавливаем на слейве скопированную базу с мастера
mysql -uroot -ppassword  < database.sql

8.5 После восстановления таким образом может возникать ошибка при рестарте сервера баз данных:
Checking for corrupt, not cleanly closed and upgrade needing tables..
/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)'
debatest:~# /usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)'
 
Лезем в файл /etc/mysql/debian.cnf ищем там строку password под пользователем
 debian-sys-maint копируем пароль и выполняем в консоли mysql 2 комманды:
 
GRANT RELOAD, SHUTDOWN, PROCESS, SHOW DATABASES, SUPER, LOCK TABLES ON 
*.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY 'Скопированный пароль';

 GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' 
IDENTIFIED BY 'Скопированный пароль' WITH GRANT OPTION;        
 

9. Рестартим базу данных на слейве /etc/init.d/mysql restart и выполняем команду в консоли сервера:

CHANGE MASTER TO MASTER_HOST = "ip master", MASTER_USER = "repl", MASTER_PASSWORD = "password", MASTER_LOG_FILE = "файл журнала в кавычках", MASTER_LOG_POS = позиция без кавычек;

mysql@slave> start slave;

После проведенных операций можно посмотреть статус репликации на слейве в консоли mysql ввести команду mysql@slave> SHOW SLAVE STATUS; 


Ключевыми в отчете по этой команде являются 2 строки
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Если в одной из строк стоит значение "no", то следовательно допущена ошибка в настройке и репликация не происходит.

суббота, 18 февраля 2012 г.

Медленные запросы к удаленной базе данных MySQL

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

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

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

Очень часто большие задержки интернета связаны с проблемой настройки ДНС. Это относиться ко всем системам как Windows так и Linux. Диагностируются такие проблемы пингом. Если задержек к удаленным хостам нет например 8.8.8.8, а интернет ползает медленно, то проблема в нем.

В загугленном топике нашел такой способ проверки. Нужно программой telnet подключиться к вашему серверу баз данных mysql.

telnet x.x.x.x 3306

Если при этом происходит задержка, а не происходит моментального подключения, то у вас скорее всего подобная проблема.

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

У демона mysqld есть специальная опция —skip-name-resolve ее лучше всего прописать прямо в конфиге my.cnf в секции [mysqld]. И перезапустить сервер. Этот параметр отвечает за резолв имен серверов, что в принципе для такой ситуации не требуется.

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

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

среда, 15 февраля 2012 г.

Репликация баз данных MySQL по типу Master-Slave Часть 1: Введение

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

Собственно репликация слово страшное, но на самом деле это просто создание копии основной базы данных на дополнительном сервере.

Применяется подобные фишки в случаях:
1. Когда нужно снизить нагрузку на главный сервер баз данных распределяя запросы.
2. Сделать резервную копию основной базы и регулярно ее обновлять.
3. В случае падения одного сервера переключиться на другой.
4. Без каких либо проблем останавливать Slave и делать резервную копию всей базы, не останавливая Master.
5. Добавить страшное слово в резюме.

Схем построения репликаций есть огромное количество, но выделяются Master-Slave и Master-Master как основополагающие.

Я опишу принцип репликации типа Master-Slave так как он самый простой.

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

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

Репликация MySQL состоит из следующих шагов:

1. Необходимо найти сервер на котором будет располагаться реплика основной баз. Естественно будет очень хорошо если сервера будут удалены друг от друга и независимы.

2. Необходимо переназначить адрес на котором будет висеть база данных. При обычной установке по умолчанию MySQL висит на порту 3306 адреса localhost(127.0.0.1). Для того чтобы mysql висел не только на localhost, но и на внешнем ip нужно в файле my.cnf закомментировать строчку bind-address = 127.0.0.1.
Для большей безопасности можно переназначить порт на другой или настроить iptables таким образом, чтобы он блокировал доступ по этому порту со всех адресов кроме адресов этих 2х серверов.

3. Необходимо задать роли для серверов БД и идентификаторы, завести пользователя от имени которого будет происходить репликация.

4. Нужно сделать полный дамп баз данных сервера mysql, где будет располагаться master. Сделать это можно 2мя способами:
     а. Остановить сервер(что является не всегда правильным, так как посещаемость ресурсам может быть круглосуточной, а дамп базы довольно большой)
     б. Остановить запись в базу данных. Перевод в режим "Только чтение" позволит выгрузить дамп без проблем и ошибок.

Эти действия нужно проводить обязательно. Я пытался выгружать не все базы с данными, только структуру, но репликации не происходило. Происходила репликация только тех данных которые были добавлены после установки отношений. Данные которые были на master до установки отношений не подтягиваются со временем. Почему такое происходит будет понятно во второй части.

5. Произвести восстановление дампа на Slave'е и установить отношение с Master'ом. После этого если на этих серверах использовались разные пароли для root, то после восстановления они оба буду одинаковыми, такими как на master.

6. Проверить состояние отношений.

суббота, 11 февраля 2012 г.

Настройка nginx как Фронтенд(Frontend) к Apache Часть 2: Настройка

Ну и собственно настройка в данном случае не особо сложная и есть существенное преимущество ее можно произвести на уже существующем сервере и работающем проекте.

1. Сначала нам надо изменить конфигурацию Apache. Его нужно перевесить на прослушку например порта 81 на адресе 127.0.0.1. Я использую сервер Linux Debian эта настройка задается в файле /etc/apache2/ports.conf

NameVirtualHost *:81 // здесь обычно указан 80 порт меняем на 81
Listen 127.0.0.1:81 // здесь обычно указан внешний ip адрес и 80 порт меняем

2. Правим nginx.conf


user www-data; # Пользователь от которого запускается процесс
worker_processes  4; # Количество рабочих процессов

error_log  /var/log/nginx/error.log; # куда сбрасываем логи
pid        /var/run/nginx.pid;

events {
worker_connections  1024; # Количество соединений
}

http {
include       /etc/nginx/mime.types;
default_type  application/octet-stream;
server_names_hash_bucket_size 64;
access_log  /var/log/nginx/access.log;
client_max_body_size 50m; # Максимальный размер файла для upload

sendfile        on;

keepalive_timeout  65;
tcp_nodelay        on;

gzip  on; # Сжатие

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*; # Аналогично apache
}


С правкой nginx.conf в принципе завершено, остальные настройки можно указывать непосредственно в конфигах хостов

Проверка работоспособности конфига можно проверить командой:
sudo nginx -t


3. Правим конфиги хостов. Создадим файл host.ru в директории /etc/nginx/site-available
server {
        listen   80;
        server_name host.ru www.host.ru;

        access_log  /var/www/host.ru/logs/nginx-access.log;

        location / {
                proxy_pass         http://127.0.0.1:81/; # делаем переадресацию запросов на apache
                proxy_redirect     off;

                proxy_set_header   Host             $host;
                # Эти настройки необходимы, что бы из скриптов было видно реальные IP пользователя, а не фронт-части
                proxy_set_header   X-Real-IP        $remote_addr;
                proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

                client_max_body_size       10m;
                client_body_buffer_size    128k;

                proxy_connect_timeout      90;
                proxy_send_timeout         90;
                proxy_read_timeout         90;

                proxy_buffer_size          4k;
                proxy_buffers              4 32k;
                proxy_busy_buffers_size    64k;
                proxy_temp_file_write_size 64k;
        }
}


4. Создаем симлинки
ln -s /etc/nginx/sites-available/host.ru /etc/nginx/sites-enabled/host.ru


5. Ставим mod_rpaf
apt-get install libapache2-mod-rpaf

6. Перезапуск серверов /etc/init.d/apache2 restart /etc/init.d/nginx restart

Ошибка: client intended to send too large body Nginx

По умолчанию если не задано уточнение в конфиге Nginx максимальный загружаемый файл на сервер ограничен 10 мб. Для увеличения этого лимита надо уточнить максимальный размер в конфиге и перезапустить сервер.

Правим: nginx.conf(путь к конфигу по умолчанию /etc/nginx) в секции http{}

client_max_body_size 50m;
теперь ограничение стоит на 50 мегабайт

Осталось перезапустить сервер
/etc/init.d/nginx restart

воскресенье, 5 февраля 2012 г.

Настройка nginx как Фронтенд(Frontend) к Apache Часть 1: Введение

Nginx все больше завоевывает просторы интернета. По заметкам на хабре известно, что даже ФБР в США использует этот вэбсервер и недавно проект получил крупные инвестиции в денежном выражении. Крупные вэбсервисы, порталы рунета также используют его. Причина его резкого роста в том, что nginx очень маленький и быстрый сервер. Это преимущество позволяет:
1. Экономить огромную долю ресурсов сервера, а следовательно и денег.
2. Ускорить загрузку сайта, что очень важно, т.к. основные поисковые системы начали учитывать скорость при ранжировании запросов.
3. В общем произвести приятное впечатление у пользователе которые не ждут долгую загрузку страницы и увеличивая таким образом количество отказов.
4. Создавать очень гибкую архитектуру для крупных проектов.

При полном переносе крупных проектов может возникнуть проблемы, так как работа nginx и Apache немного различаются в своей работе. Но нет необходимости переносить сразу все на nginx, можно переходить в несколько этапов.

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

В этом топике опишу только смысл работы этих серверов в связке.  Во второй части опишу пример внедрения.

Как известно Apache по умолчанию сидит на порту 80 и смотрит во внешнюю сеть, т.е. в интернет и отвечает в него. Т.о.  при установке nginx нужно придумывать хитрость при которой. Nginx будет заменять Apache на 80 порту и отвечать клиенту на запросы отдавая статический контент, но при исполнении каких либо скриптов отправлять запросы apache.

Для работы такой связки необходимо перенести apache на другой порт и очень важно при этом заставить слушать его не внешний интерфейс который смотрит в интернет, а loopback 127.0.0.1.


В итоге можно будет снизить общую загрузку сервера. Apache будет загружаться только при обработке интерактива на сайте  Разница в памяти между nginx и Apache в 15 раз по моим наблюдениям. А общий выигрыш от моего внедрения nginx как frontend оказался в 30 процентов(сравнивал загрузку памяти).

четверг, 2 февраля 2012 г.

IBM создает 9-нанометровые углеродные транзисторы на нанотрубках, бросая вызов кремниевым аналогам

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

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

phpbb3 Настройка отправки сообщений с форума через службы Яндекс. Решение ssmtp на Debian

При установке на свой сайт форума phpbb3 столкнулся с проблемой. Все письма которые отсылались с форума например для подтверждения регистрации или отправки сообщений на почту через профиль пользователя резались в спам.

При просмотре оригинала письма, т.е. с полным просмотром заголовков увидел, что в качестве отправителя указан www-data@moivps, то есть фактически отправитель не совпадал с полем отправитель в письме.

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

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

Решение состоит в установке и замене стандартного MTA exim на ssmtp. Преимущество в том, что не нужно нагружать сервер лишними программами и по своему принципу ssmtp подгружается только в случае его вызова. Т.е. он будет загружаться только при использовании функции mail. И после отправки выгружаться из памяти. Кстати то что используется функция mail() очень важно, почему будет ясно ниже. Для переправки почты будет использоваться Яндекс службы для домена, хотя службы Google настраиваются аналогично.
Допустим привяжем к службам Яндекса домен example.ru

Итак приступим к установке:

apt-get install ssmtp

При установке автоматом будет удален пакет exim. После этого отправка почты отвалится до того как вы настроите конфигурационные файлы. Они расположены как обычно: /etc/ssmtp/

Правим ssmtp.conf для нашего домена example.ru


root=myemail@example.ru 
mailhub=smtp.yandex.ru:465

AuthUser=
myemail@example.ru
AuthPass=пароль_к_почтовому_ящику

rewriteDomain=
example.ru 
hostname=
example.ru 

FromLineOverride=YES
UseTLS=YES
 

Все осталось добавить пользователя в разрешенных пользователей которые имеют право отправлять почту. Делается это в файле /etc/ssmtp/revaliases
В моем случае был пустой файл и я дописал одну строку:

root:myemail@example.ru:smtp.yandex.ru:465


Все с ssmtp разобрались осталось добавить опцию в phpbb3:

1. В центре администрирования в главной вкладке "Общие" ищем пункт Средства связи->Настройка почты.
2. Включаем опцию "Включить email сообщения" и "Рассылку email сообщений через форум".
3. В поля "Контактный email" и "Обратный email" пишем имейл через который осуществляем рассылку/отправку в моем случае myemail@example.ru
4. Настройка завершена. Опции которые расположены ниже задействовать не нужно, так как рассылка будет также происходить через функцию mail().