Всякий блог

Очень долго бился с тем как закрыть доступ ботам к своим форумам на phpbb. Все встроенные средства естественно не помогают. Установка активации аккаунта по email, ограничение сообщений для новых пользователей не помогало. Даже самый не любимый способ установка recaptcha и то не помог в этом деле. Когда количество спама начало превышать 20 сообщений в день решил искать кардинальное решение этой проблемы. Основная масса ботов использует просто набор решений для стандартной защиты и любое свое решение отличающееся от стандартного может практически полностью избавить ваш форум от спам сообщений которые производят роботы. Естественно полностью от спама избавится не возможно так как очень настырные вэбмастера если им надо будет просто сами зарегистрируются и запостят сообщение с ссылкой на продвигаемый ресурс. Итак решение для версии 3 движка phpbb прописать в низу файла config.php следующий код: if (isset($_POST['password_confirm']) && isset($_POST['tz'])){ //

1. Устанавливаем на планшет/мобильный с помощью программы маркет, приложение из категории ИНСТРУМЕНТЫ - ES Проводник(ES Explorer), с помощью которого вы сможете просматривать все доступные папки и файлы на вашем устройстве. 2. Запускаем ES Проводник, нажимаем на значок в виде microSD флешки, открывается много папок (acct, cache,config…). Ищем и переходим в папку mnt -> usb_storage (это и есть содержимое вашей флешки). 3. Находите нужный файл с расширением .apk (в виде пиктограммы) и запускаете его. Если вы делаете это первый раз система выдаст окно с заголовком: "Установка заблокирована" и содержанием: "Из соображений безопасности на вашем телефоне заблокирована установка приложений, полученных не из Android-маркета". Нажимаете кнопку Настройки, откроется окно настроек, справа найдите строку Неизвестные источники (Разрешить установку приложений, полученных не из Маркета), ставим тут галочку, соглашаемся с предупреждением о том что планшет станет боле

Процедура довольно сложная и требует обдумывания решений. Бросаться сразу делать не стоит, тем более на рабочих боевых серверах. Лучший вариант это кончено попробовать на тестовых виртуальных серверах, если есть терпение, у меня его нет, обычно внедряю сразу, подстраховавшись бэкапами всего и вся. 1. Итак у нас должен быть рабочий сервер с базой данной mysql, желательно схожей версии выше 5.0. Сам сервер нужен чтобы смог справиться с подобной нагрузкой на головной сервер либо лучше. Я использовал физический сервер более мощной конфигурации, чем головной виртуальный. 2. Закомментируем строку в файлах my,cnf bind-address = 127.0.0.1 в этом случае доступ к базе будет как снаруже, так и изнутри. Для безопасности вашего сервера так же рекомендуется в iptables на обоих серверах разрешить только доступ по порту базы данных только работающих в этой схеме серверов. 3. Создаем пользователя с правами на репликацию GRANT FILE ON *.* TO repl@"%" IDENTIFIED BY '<password&g

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

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

Ну и собственно настройка в данном случае не особо сложная и есть существенное преимущество ее можно произвести на уже существующем сервере и работающем проекте. 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; # Макс

По умолчанию если не задано уточнение в конфиге Nginx максимальный загружаемый файл на сервер ограничен 10 мб. Для увеличения этого лимита надо уточнить максимальный размер в конфиге и перезапустить сервер. Правим: nginx.conf(путь к конфигу по умолчанию /etc/nginx) в секции http{} client_max_body_size 50m; теперь ограничение стоит на 50 мегабайт Осталось перезапустить сервер /etc/init.d/nginx restart

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

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

При установке на свой сайт форума phpbb3 столкнулся с проблемой. Все письма которые отсылались с форума например для подтверждения регистрации или отправки сообщений на почту через профиль пользователя резались в спам. При просмотре оригинала письма, т.е. с полным просмотром заголовков увидел, что в качестве отправителя указан www-data@moivps, то есть фактически отправитель не совпадал с полем отправитель в письме. При написании собственных скриптов эта проблема обходилась без проблем, но так как мои познания в структуре кода phpbb3 минимальный полез в гугл решать вопрос более простым путем. После недолгого поиска нашел решение данной проблемы, но вариант этот подходит только для небольшого числа хостов и пользователей. Решение состоит в установке и замене стандартного MTA exim на ssmtp. Преимущество в том, что не нужно нагружать сервер лишними программами и по своему принципу ssmtp подгружается только в случае его вызова. Т.е. он будет загружаться только при использовании фун