Допустим у нас есть mysql база данных site_db, а в ней таблица tablename. Нам нужно конвертировать таблицу tablename из myisam в innodb. По идее всё просто. 1 2 3 mysql -u root -p USE site_db; ALTER TABLE tablename ENGINE=InnoDB; Но в жизни мы можем получить следующий ответ ответ 1 ERROR 1214 (HY000): The used table type doesn't support FULLTEXT indexes И вот здесь можно побороться. SHOW CREATE TABLE tablename; Нам покажут много строк, среди которых будет строчка с текстом FULLTEXT KEY key_name (column_list) или что-то около того. Важно чтоб в начале было FULLTEXT KEY. Запомнили этот ‘key_name’. Удаляем этот индекс ALTER TABLE tablename DROP INDEX key_name; в ответ получим что-то такое 1 2 Query OK, 6175950 rows affected (20 min 56.88 sec) Records: 6175950 Duplicates: 0 Warnings: 0 а затем снова пробуем конвертировать ALTER TABLE tablename ENGINE=InnoDB; В этот раз должно всё получиться. Не забывайте использовать screen, если работаете с большими базами данных.

В http-сервере Apache найдена опасная уязвимость, позволяющая вызвать отказ в обслуживании через исчерпание всей доступной памяти. Опасность уязвимости усугубляется тем, что для её осуществления уже доступен готовый эксплоит, позволяющий совершить атаку с одной машины с генерацией минимального трафика. При отсутствии отдельных лимитов на размер выделяемой Apache памяти, после выполнения эксплоита наблюдается полное исчерпание памяти с уходом в бесконечный своппинг без возможности зайти в консоль. Проблема вызвана ошибкой в реализации поддержки загрузки части файла по указанному диапазону (например, после обрыва соединения можно запросить загрузку начиная с определенной позиции). Ошибка связана с тем, что при обработке запроса, содержащего большое число диапазонов (например, “Range:bytes=0-,5-1,5-2,5-3,...,5-1000”) в сочетании с использованием gzip-сжатия отдаваемого контента, расходуется слишком много памяти. Например, если в заголовке Range передана тысяча диапазонов, то Apache пытается отдельно сжать каждый диапазон. Так как каждая операция сжатия требует достаточно много памяти (даже для сжатия одного байта выделяется буфер для сжатия блока), в сумме легко исчерпать всю доступную память. Для осуществления удачной атаки достаточно отправить около 50 подобных запросов с составным Range на сервер. Проблема присутствует в Apache 2.2.x, включая последний релиз 2.2.19. Исправление пока доступно в виде патча. Также имеется несколько способов временной защиты, не требующих пересборки Apache. Например, можно принудительно очищать заголовок Range при помощи mod_header ("RequestHeader unset Range" и “RequestHeader unset Request-Range”) или блокировать длинные последовательности Range через mod_rewrite: Вариант 1: 1 2 3 4 5 RewriteEngine On RewriteCond %{HTTP:Range} bytes=0-[0-9]+, [NC,OR] RewriteCond %{HTTP:Range} bytes=([0-9-],){4,} [NC,OR] RewriteCond %{HTTP:Range} bytes=[0-9,-]+,0-(,|$) [NC] RewriteRule .? http://%{SERVER_NAME}/ [NS,L,F] Вариант 2: 1 2 3 4 RewriteEngine On RewriteCond %{REQUEST_METHOD} ^(HEAD|GET) [NC] RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)(\s*,\s*[0-9]*-[0-9]*)+ RewriteRule .* - [F] Вариант 3: 1 2 3 RewriteEngine On RewriteCond %{HTTP:Range} bytes=0-.* [NC] RewriteRule .? http://%{SERVER_NAME}/ [R=302,L] Интересно, что о теоретической возможности совершения подобной атаки Михаил Залевски (Michal Zalewski), известный польский эксперт в области компьютерной безопасности в настоящее время работающий в Google, сообщал еще 4 года назад, но проблема по каким-то причинам не была воспринята всерьез и исправления не были внесены. ...

Статья в виде заметки… В файле /etc/httpd/conf/httpd.conf ищем секцию и немного увеличиваем значения (MaxRequestsPerChild лучше наоборот уменьшить). Например, таким образом (по умолчанию настройки слишком зажаты, мы же здесь увеличим лимиты, съедая попутно больше оперативной памяти): 1 2 3 4 5 6 7 8 StartServers 5 MinSpareServers 5 MaxSpareServers 15 ServerLimit 30 MaxClients 30 MaxRequestsPerChild 200 MaxKeepAliveRequests 50 KeepAliveTimeout 5 И, как, обычно, после этого необходимо выполнить 1 # service httpd restart Источник и личный опыт

Вот уже которая версия, а phpbb3 не научился подставлять имя отправителя. При чтении почты это выглядит… скажем “не очень красиво”. Поставлена задача: Научить phpbb3 подставлять название форума. Приступим… Открываем 1 includes/functions_messenger.php Находим 1 2 3 4 if (empty($this->from)) { $this->from = '<' . $config['board_contact'] . '>'; } Заменяем на 1 2 3 4 5 6 if (empty($this->from)) { //$this->from = '<' . $config['board_contact'] . '>'; mb_internal_encoding("UTF-8"); $this->from = '"' . mb_encode_mimeheader($config['sitename'], 'UTF-8') . '"' . '<' . $config['board_contact'] . '>'; } Сохраняем, наслаждаемся результатом! Работает с русским языком! Использованы материалы www.phpbb.com

Эта статья описывает установку и настройку того самого PPTP-сервера под управлением Linux. В качестве исходных данных будем использовать: офисный интернет-шлюз под управлением Ubuntu Server 7.10 с адресом в локальной сети 192.168.1.1. Для начала устанавливаем всё необходимое: 1 apt-get install ppp pptpd Далее приступаем к настройке. Всё достаточно просто. Первым делом открываем в редакторе файл /etc/pptpd.conf и дописываем в конец следующие строки: 1 2 3 4 5 # IP-адрес сервера в локальной сети localip 192.168.1.1 # Диапазон адресов для клиентов PPTP-сервера remoteip 192.168.1.200-254 Следующим шагом дописываем в файл /etc/ppp/pptpd-options следующие две строчки: 1 2 3 4 5 # требуем авторизацию у клиентов auth # Используем шифрование require-mppe Ну и наконец открываем в редакторе файл /etc/ppp/chap-secrets и заполняем строчками вида: 1 2 3 4 5 6 # Если пользователь должен динамически получать IP-адрес # из диапазона remoteip в pptpd.conf: user1 pptpd password1 "*" # Если мы хотим привязать определённый IP к логину: user2 pptpd password2 "192.168.1.101" После этого перезапускаем pptpd: /etc/init.d/pptpd restart Скорее всего на сервере стоит файрволл. Добавим в скрипт iptables несколько строк: ...

Бывают случаи, когда вам нужно создать расписание выполнимых задач на сервере. Предположим что вы хотите сделать резервную копию на жесткий диск раз в неделю, или вы хотите запустить скрипт в 6 часов утра каждый день. Все эти задачи, которые вы хотите запустить в определённый интервал времени, могут быть настроены с помощью Cron. Демон Cron давно используется там, где нужно выполнять команды пользователя в определённые промежутки времени. Это руководство представляет собой учебник в котором шаг за шагом описывается как можно планировать такие задачи, используя программу с названием Crontab. Настройка crontab на самом деле очень проста. Для редактирования расписания crontab используйте следующую команду 1 crontab -e Если редактор по умолчанию не определен, то вы можете увидеть сообщение об ошибке: 1 2 /bin/sh: /bin/vi: No such file or directory crontab: "/bin/vi" exited with status 127 Для того чтоб определить используемый редактор по умолчанию, выполним 1 export EDITOR=vim Теперь Vim будет использоваться как редактор по умолчанию. Вы можете использовать любой редактор на ваш выбор, например (emacs, nano и т.д.). 1 2 3 4 5 6 7 * * * * * команда/которая/должна/быть/выполнена | | | | | | | | | ----- День недели (0 - 7) (Воскресение=0 или 7) | | | ------- Месяц (1 - 12) | | --------- День месяца (1 - 31) | ----------- Час (0 - 23) ------------- Минуты (0 - 59) Предположим, вы хотите запускать скрипт каждый час ...

Точное время необходимо для правильной работы системы, поэтому займемся первым делом этим вопросом. Установим пакет ntpdate 1 apt-get install ntpdate Сверим время с сервером точного времени 1 ntpdate-debian При необходимости произведем смену часового пояса через 1 tzconfig тут все по русски, выбираем необходимое. Теперь отключаем контроль разницы во времени БИОС и системы по местному времени, дело в том, что по умолчанию система считает, что время БИОС это точное международное время по Гринвичу и система должна корректировать свое время по местной разнице исходя от него, оставляя время БИОС без корректировки. Если мы хотим соответствия времени системы со временем БИОС, то заходим в /etc/default/rcS заменяем UTC=yes на UTC=no и выполняем 1 /etc/init.d/hwclock.sh restart перезапускаем сервер времени. Если у вас платформа amd64, то ваши часы наверняка убегают вперед, это происходит потому что по умолчанию работает таймер tsc, а нам нужен hpet, ибо tsc ведет себя таким вот безобразным образом в системах amd64. Как быть? Отключаем таймер tsc, а так как система не может без таймера, то она запустит следующий свободный hpet. Для этого необходимо передать ядру параметр notsc, его следует прописать в файле /boot/grub/menu.lst в строке с kernel в конце после уже прописанных параметров через пробел от последнего, сохранить и перезагрузить систему, это единственный случай, когда я не нашел варианта применить изменения без перезагрузки, суть задачи передать этот параметр ядру, но как это сделать без перезагрузки я пока не знаю, возможно есть вариант. Теперь время идет точно и соответствует нашему часовому поясу.Для синхронизации времени с интернет сервером необходимо установить ...

Пришлось на днях повозиться с переносом Crystal Trader. Описываю заметки и подводные камни. Общался с автором, он сказал что на данный момент (апрель 2015) перенос с помощью встроенных средств есть не слишком эффективным. Сам советует копировать файлы с сохранением прав. Ну и БД конечно же. 1. Скрипт обращается к mysql через сокет. На новой систему сокет находился в другом месте. Я сделал симлинк, хотя можно было бы просто исправить на правильный путь. 2. Пути указываются в файлах ./crtr/config/config.php, ./crtr/config/pathes.cnf, параметры mysql прописаны в ./crtr/config/c.cnf 3. Обязательно нужно не забыть скопировать задания крона с учётом новых путей, или просто переписать их в низу страницы. 4. В админке всё равно будет написано что кроны не запускались более 3 минут. Для этого нужно всё в той же админке выбрать System - Updates - Update current version files. Максимум через 5 минут уведомление должно пропасть. 5. После 4 пункта на сайте стали отображаться ошибки Internal script error can’t load settings в месте подключения in.cgi, то же самое отображалось и при попытке нажатия на тумбу, но уже с файлом out.cgi. Решение подсказал автор скрипта. Нужно удалить директорию со скриптами in.cgi, out.cgi. При следующем запуске крона они создадутся автоматически заново с правильными путями. Немного информации: Саппорт - ICQ UINs: 412826686 Установка: http://www.crystal-scripts.com/support/docs/ http://crystal-scripts.com/downloads/install.php Update: Параметры mysql 1 2 3 4 5 6 7 8 key_buffer = 512M max_allowed_packet = 64M thread_stack = 192K thread_cache_size = 8 query_cache_limit = 1M query_cache_size = 64M tmp_table_size = 1024M max_heap_table_size = 1024M

В качестве заметки… При изменении innodb_log_file_size придется остановить сервер и удалить (или переименовать) старый лог файл, для чего могут потребоваться рутовые права. Если же старый файл не удалять, mysql просто откажется стартовать. Моя выжимка из конфига (не самая сильная dev-машина, 3G RAM, Dual CPU E2140 @ 1.60GHz) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [innodb] innodb_buffer_pool_size = 1024M innodb_flush_method = O_DIRECT innodb_log_file_size = 256M innodb_log_buffer_size = 4M innodb_flush_log_at_trx_commit = 2 innodb_thread_concurrency = 8 [mysqld] log_slow_queries = /var/log/mysql/mysql-slow.log long_query_time = 1 log-queries-not-using-indexes default-storage-engine = InnoDB collation_server=utf8_general_ci character_set_server=utf8 и вот ещё из другого источника innodb_buffer_pool_size – 70 – 80% оперативной памяти. Я ставлю это значение в 12G на системе с 16G RAM innodb_log_file_size – зависит от необходимого вам объема данных для восстановления, но 256МБ будут разумным компромиссом между производительностью и рамером лог-файла innodb_log_buffer_size=4M – 4 мегабайта – нормальное значение, если вы не используете подачу больших блоков данных в InnoDB через каналы (pipes). Если используете, это значение лучше увеличить. innodb_flush_logs_at_trx_commit=2 – если вас не особо заботит ACID, и вы можете себе позволить потерять транзакции за последние секунду или две, в случае полного краха ОС, то установите это значение. Но это может повлечь печальные эффекты при коротких записях транзакций. innodb_thread_concurrency=8 – даже при имеющихся InnoDB Scalability Fixes будет совсем не лишним иметь ограниченное количество потоков. Значение может быть больше или меньше в зависомости от ваших потребностей, но 8 будет оптимальным значением для начала. innodb_flush_method=O_DIRECT – избегайте двойной буферизации и уменьшите активность swap, в большинстве случаев это увеличивает производительность. Но будьте осторожны, если у вас нет RAID с возможностью сохранения данных, операции ввода-вывода могут проходить некорректно и данные могут быть повреждены. innodb_file_per_table– если у вас немного таблиц, используйте эту опцию и рост занимаемого таблицами места не будет бесконтрольным. Эта опция добавлена в MySQL 4.1 и сейчас достаточно стабильна для использования. ...

Я часто настраиваю людям роутеры. В основном это что-то из D-Link, TP-Link, Asus, реже какой-то хлам и ещё реже Mikrotik. После того, как убрал из дома сервер, на котором хостились все мои сайты, который выполнял функции роутера, возник вопрос подбора роутера для домашней сети. Опыта довольно много, поэтому все приемлемые изделия D-Link сразу же откинулись. Пал мой взгляд на TP-Link TL-WR1043ND. На тот момент у него была максимальная производительность среди “бытовых” роутеров. Роутер куплен, предстоит настройка. Обычно это занимает не более 10 минут, но в этот раз пришлось повозиться. Мой провайдер предоставляет локалку, а через неё доступ к PPTP, PPPOE, L2TP серверам. Так называемый Dual Access. Для того чтоб всё это дело одновременно работало необходимо прописать маршрут на 192.168.0.0/16 (или 255.255.0.0). При этом я хочу в домашней сети оставить подсеть 192.168.0.0-255. Обычно роутеры не против такого. Но TP-Link оказался не обычным роутером, а со своими фокусами. Он отказался прописывать маршрут 192.168.0.0 255.255.0.0, потому что внутренняя сеть пересекалась с этой. Я не забыл что провайдер не использует нулевую подсеть, соответственно у меня остался вариант прописать маршруты на все подсети, кроме нулевой. Именно об этом я и хочу вам поведать, точнее сохранить эти маршруты на память, вдруг ещё пригодятся, а помощи искать негде будет. Адрес (хост или сеть) Битов или маска Шлюз 192.168.1.0 24 или 255.255.255.0 ваш шлюз 192.168.2.0 23 или 255.255.254.0 ваш шлюз 192.168.4.0 22 или 255.255.252.0 ваш шлюз 192.168.8.0 21 или 255.255.248.0 ваш шлюз 192.168.16.0 20 или 255.255.240.0 ваш шлюз 192.168.32.0 19 или 255.255.224.0 ваш шлюз 192.168.64.0 18 или 255.255.192.0 ваш шлюз 192.168.128.0 17 или 255.255.128.0 ваш шлюз Таким образом мне удалось добиться полноценной работы внутренней сети моего провайдера и моей внутренней сети 192.168.0.0-255. ...