Доброго всем времени суток, уважаемые Форумчане!
Думал, куда бы разместить свою скромную историю, но, наверное, здесь ей место более логично. Надеюсь, мой, хоть и не слишком глубокий, опыт, кому-нибудь пригодится. Начнём.
Зародилась идея прикрутить к форуму портал vBadvanced. Но так как на "живом" экспериментировать что-то б0язно, решил восстановиться из какой-нибудь древней копии на локалке. Благо tar.gz домашнего веб-каталога в закромах Родины лежит, не отсвечивает, да и дамп с тех времён рядышком почивает. Дамп, правда, кривоват, ибо делан был во время падения форума и содержит в себе кучу мусора, в том числе и таблиц t_aggregate_temp_xxxxxx.
Ну да не об этом. Ставить решил на давно полюбившуюся операционку FreeBSD, заодно и посмотреть "в глаза" "десятке", ибо видел её только издалека, но слышал о многих хороших изменениях.
Процедуру установки ОС описывать не буду, ибо это предмет отдельной темы, перейду сразу к подготовке системы для установки vB.
Так как сервак в демилитаризованной зоне и кроме меня навряд ли кто туда полезет, использую "стандартную" связку: Apache+Php+Mysql, без разделения на "фронтэнд" и "бэкэнд".
Обновив порты системы решил ставить все самые свежие версии софта: апач 2.2.29 (на 2.4 пока переходить не хочу), мускль 5.6.25, пхп 5.6.11.
Обычно собирал весь необходимый софт вручную: брал архив, распаковывал, делал configure --help | more и выписывал нужные для себя опции, с которыми потом конфигурял makefile для последующей сборки. Но зачастую такой путь не позволял установить все необходимые зависимости, без которых устанавливаемый софт не будет работать должным образом, а вручную шерстить дерево dependencies для того, чтобы потом так же вручную их ставить слишком долго и утомительно. Ибо зависимостей иногда бывает не один десяток.
Умные люди не так давно показали один очень интересный системный скрипт под названием portmaster, который расширяет "стандартные" возможности портов во FreeBSD. Этот скрипт при запуске сначала проверяет все зависимости, выдаёт экран настройки и установки опций для каждого связанного порта, генерируя config.status и makefile для каждого, после чего собирая и устанавливая всё в нужной последовательности. Скрипт писан на шелле и использует все стандартные функции системы работы с портами, что на самом деле очень радует.
В общем, находясь в каталоге нужного порта, пишем мантру "portmaster" и начинаем расставлять опции во всплывающих окошках конфигов для последующей сборки. При установке апача вылезло десятка три всяких зависимостей, благополучно настроенных. Сама установка напоминает "подсматривание за подсматривающим": всё делается само, всё тянется само, всё собирается и ставится само. При установке насторожило, что в конфиге апача нет опции --enable-so и нет упоминания о сборке пхп модуля. Ну да ладно, думаю, опции всегда можно изменить в процессе.
Потом поставил мускля. Там ничего, как помнится, отдельно в опциях указывать необходимости нет. Далее пошёл пых. Помнится, была известная проблема с пыхом версии 5.4, когда движок не желал работать с этой версией интерпретатора, но раз уж люди эту проблему решают, значит, подумал я, и мне нефиг делать кислую рожу, и начал устанавливать. При конфигурянии тоже не увидел старой "доброй" позиции --with-apxs.
В общем, всё поставилось, настала пора конфигурирования всего этого добра.
Первым делом решил разобраться с пыхом. Создал в /usr/local/etc/ файл php.ini, скопировав и переименовав файл php.ini.production. В принципе для более-менее нагруженного сервера более-менее типовой конфигурации эта настройка в б0льшей мере удовлетворяет. Поправил там работу с ошибками:
Code:
error_reporting = E_ALL & ~(E_DEPRECATED & E_STRICT & E_NOTICE)
и
Code:
display_errors = Off
чтобы не орало на экран. Ещё мне посоветовали поставить переключатель
типа для секурности. Хотя на локалке....
При установке пыха раньше он "автоматом" добавлял в конфиг апача обработку пхп-файлов, а сейчас при установке он просто написал, мол, для корректного функционирования движка добавьте вот это
Code:
<FilesMatch "\.php$">
SetHandler application/x-httpd-php
</FilesMatch>
<FilesMatch "\.phps$">
SetHandler application/x-httpd-php-source
</FilesMatch>
А раньше нужно было либо в основном конфиге, либо в mime_types добавлять
Code:
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
Ну я решил закосить под умного, создал в каталоге апача в extras отдельный файл, назвал его php.conf и впихнул туда предлагаемые параметры. Ибо хз, может быть в "новой" версии апача поддержка пхп делается именно так.
Так как сервер - локальный, ДНСов нет, описание домашнего каталога форума сделал просто алиасом, а не через виртуалхост. И тут смотрю, в списке подключаемых модулей ну нету ни mod_php, ни libphp, ничего такого подобного, что раньше само вставлялось при сборке пхп. Оказывается, сейчас каждый сам по себе: пых - сам по себе, апач - сам по себе, а модуль пыха для апача - вообще четвёртый поросёнок по имени "нах-нах" и приходит по отдельному приглашению. Идём в /usr/ports/www/mod_php56 (так как у нас всё-таки пых версии 5.6) и ставим его дополнительно. По окончании установки, как в старые времена, модуль сам прописывается в конфиг апача. Будем на сей момент считать, что пых вроде бы настроен.
Идём к мусклю, ибо он заждался. При установке мускль сам создал дефолтовый файл настроек себя любимого (my.cnf), который положил в /usr/local/. Чтобы не думалось, копируем этот файл в /var/db/mysql/, где будет лежать база (пути пока решил не менять, ибо всё-таки всю эту конструкцию полагаю как "временную" и "тестовую").
Добавил в /etc/rc.conf строчку mysql_enable="YES" для того, чтобы и при перезагрузке мускль стартовал, и при рукопашном старте/стопе сервиса через скрипт rc.d не ругался, а нормально работал.
Запустил мускля (/usr/local/etc/rc.d/mysql-server start) и выполнил команду первичной инициализации сервера, перейдя в каталог /usr/local/ сделал командочку bin/mysql_install_db
Рутовый пароль я поменять сразу как-то подзабыл, поэтому после инициализации базы остановил мускля, в my.cnf добавил строчку skip-grant-tables для того, чтобы база стартовала, не зная, у кого какие пароли и права, и снова запустил мускль.
Далее mysql -u root -p пустил в базу, где sql-запросом
Code:
UPDATE USER SET PASSWORD=PASSWORD('new_password') WHERE USER='root' AND HOST='localhost';
FLUSH PRIVILEGES;
изменил пароль суперпользователя на нужный и обновил права.
Всё, рута сделали, теперь надо базу создать для движка. Но так как, помнится, при прошлой попытке восстановления из бэкапа был какой-то конкретный косяк с кодировкой, оттого, что где-то в двухгиговом дампе collate было устангвлено на 'latin_swedish1_ci' и просто так, "в лоб", этот дамп поправить в те времена мне не удалось, при создании базы решил жёстко указать и кодировку и сортировку.
Code:
CREATE DATABASE dbname CHARACTER SET cp1251 COLLATE cp1251_general_ci;
Отработало. Теперь надо сделать юзера. Не под рутом же жить (хотя такая крамольная мысль проскакивала: ну типа же "локалка" и "тест", но "тест", я думаю, должен быть более приближен к "живой" системе). Но так как не помнил сразу строку создания юзера с назначением прав и пароля, а искать было лень, просто создал юзера
Code:
CREATE USER dbuser;
думаю, сначала юзера просто создам, а потом ему и права и пароль назначу, в чём проблема?
назначаю пароль
Code:
UPDATE USER SET PASSWORD=PASSWORD('new_password') WHERE USER='dbuser' AND HOST='localhost';
FLUSH PRIVILEGES;
запрос вроде правильный, мускль не ругается, но пишет 0 rows affected, 0 changes made
что за хрень... Плюс в истории команд - сброс привилегий остался, а апдейт пароля - нет. Ничего не понимаю.
Полез посмотрел табличку
Code:
SHOW USERS FROM USERS;
юзер, показывает, есть. Ладно, думаю. Есть, значит есть. "Может быть смена пароля не считается изменением в базе?" - подумалось у меня в чердаке. Почесав волосистую часть верхней точки полез раздавать права вновь созданному юзеру.
Code:
GRANT ALL PRIVILEGES ON dbname.* TO 'dbuser'@'localhost' IDENTIFIED BY 'mypassword';
опять 0 raws affected, 0 changes made.
делаю командочку
Code:
SHOW GRANTS FOR dbuser;
а в ответ выводится только возможность USAGE, но для всего. Ладно, думаю, сделаю по-другому. И выполнил запрос без указания пароля:
Code:
GRANT ALL PRIVILEGES ON dbname.* TO 'dbuser'@'localhost';
отработало!
Ура, думаю я, пойду редактировать config.php форума и заливать дамп в мускль. Не единожды натыкался на форуме на то, что при более свежих версиях пыха в config.php движка нужно в dbtype ставить значение mysqli вместо mysql, что и было сделано. Ну и конечно же вписал имя бд, имя и пароль пользователя для работы движка.
Потом залил дамп базы
Code:
mysql -u root -p -D dbname < mydumpfile.sql
После некоторого времени ожидания, настало время и пытаться что-нибудь запускать. Мускль уже крутится, апач вроде худо-бедно настроен, пых стоит, пора!
service apache22 start
захожу браузером на адрес восстанавливаемого форума:
http://192.168.35.1/forum/
а в ответ вываливается содержимое файла index.php
япона мать. Что такое.
Пытаюсь запустить спец файлик с пхпинфо - на экране содержимое файла. не отрабатывает пхпинфо.
Полез смотреть конфиги апача и сравнивать с тем, что предлагал пых (а это было заботливо сохранено в файле). Проверил по буквам - один-в-один. Посмотрел список модулей апача - libphp5 прописан и при старте не ругается. Но не работает, и всё. Бился, бился, в итоге в основной файл httpd.conf добавил строчку
Code:
AddType application/x-httpd-php .php
прямо в секции модуля компрессии после описания x-gzip и x-compress.
Перезапуск апача, и.... Файл с пхпинфо отработал! Отлично! Вот только непонятно, почему же установщик требует добавить в конфиг апача одну конфигурацию настройки модуля, а работает - другая? Ответ очень прост: в httpd.conf строки подключения модулей из extra закомментированы.....
А я тут сексом с плясками страдаю.... В общем, результата добился, причину нашёл. Конфиг изменять уж не стал, пусть работает, как работает.
Захожу в корневой каталог восстанавливаемого форума - и вижу пустой экран. Исходный код страницы также пустой. Что за хрень, опять какие-то грабли... Но так как пых отрабатывает, закрались сомнения относительно настройки соединения с бд, хотя если бы было что-то не то с бд, по идее бы рисовалась database error, а не пустой экран. Ну да ладно, полез проверять.
пытаюсь залогиниться в мускль под созданным и настроенным юзером - а вотхрен там. Аксесс, говорит, тебе денаед, и делай, что х0шь. Иду рутом, думаю, хз, может пароль криво набрал. Делаю снова UPDATE USER SET PASSWORD... , выхожу, пытаюсь зайти - хрен.
Полез искать ответов в Интернетах.
ОКАЗЫВАЕТСЯ! Юзеры 'user'@'localhost' и 'user'@'%' - это РАЗНЫЕ юзеры!!! Для меня это было великое открытие (поясню: я - не специалист в MySQl или SQL, и у меня в голове не укладывается, как так может быть, что при запросе select user from user; может в таблице вылазить несколько юзеров с одинаковыми именами???).
В общем, создал юзера 'dbuser'@'localhost':
Code:
CREATE USER 'dbuser'@'localhost' IDENTIFIED BY 'password';
дал ему права на нужную базу:
Code:
GRANT ALL PRIVILEGES ON dbname.* TO 'dbuser'@'localhost';
ну и обновил права. Вышел/зашёл - пускает! Фух... Юзер в базе есть, права у него есть, пробуем запуск форума.
шЫш.
В смысле белый экран.
Полез искать в тырнетах рецепты лечения белого экрана. Кстати, довольно-таки обширная тема, которая есть здесь, нифига не индексируется (видимо) поисковиками и найти её удалось только переходами по ссылкам из других тем на этом же форуме.
В организм начала закрадываться мысль "а, поомнишь, - говорил я сам с собой в черепной коробке, - "когда настраивал форум во время обновления системы, не отображалась часть админки из-за отсутствующего расширения пыха?". Помню... Хорошо, пхпинфо отрабатывает и показывает нужную информацию. В соседней вкладке запустил пхпинфо с другого локального сервака, где уверенно крутится такая же "тестовая" "ксюха". Ага. Половины модулей нет. Ну правильно. Если в старые времена модули и расширения для пыха собирались вместе с пыхом, путём добавления нужных опций при конфигурации исходника, то сейчас php56-extensions - это отдельный "продукт". Хорошо. Идём в порты, портмастером ставим.
После установки сравниваем результаты phpinfo: практически идентичны.
Так как не нашёл здесь на форуме (возможно, плохо искал, но неоднократно уже задавался этим вопросом и находил ответы в других местах), списка необходимых расширений php для корректной отработки движком своих функций. Напишу его тут (пусть даже только для себя):
Code:
CORE
Ctype
Date
DOM
Ereg
filter
gd
hash
iconv
json
libxml
mhash
mysql
mysqli
mysqlnd
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
Posix
reflection
session
Simplexml
SPL
SQLite3
tokenizer
xml
xmlreader
xmlwriter
ZendOPcache
Zlib
Ну, думаю, щщасьте наступило. Щаз как заработает!! Перезапускаю апача для переинициализации расширений пыха (кстати, список установленных расширений пыха находится в файле /usr/local/etc/php/extensions.ini. При переезде или апгрейде можно его сохранить в укромное место и всегда подсмотреть, что же было в системе установлено из расширений php) - белый экран.......
В качестве одного из советов по восстановлению работоспособности встречал, что глючить может какой-то из установленных хаков. Там их несколько штук есть (превент даблпост, мини-статистика на главной, комментарий модератора/администратора и ещё пара штук). Ну мало ли, ХЗ, может быть при дампе криво слились данные, или по их таблицам какая ошибка, полез в config.php и, как советовали, после строки
Code:
$config['Mysqli']['ini_file'] = '';
вставил
Code:
define ('DISABLE_HOOKS',true);
А нифига... белый экран атакуэ и никуда уходить не желает.
Что жжж. Остаётся крайнее средство диагностики. Включаем в php.ini вывод всех ошибок на экран.
Code:
display_errors = On
пеереезаапуускаааем....
И при заходе на экран повалилось..." Ой, неправильные форматы даты", что-то там ещё, но в конце после всех ворнингов вижу еррор: (вольный перевод) "при инициализации модуля GeoIP в тех путях, где его надо искать, его и нету!!! За сим звыняйте, откланиваюсь и закрываю лавочку".
Хех. Путь копанья ясен. Лезем в config.php и видим там абсолютный путь до местонахождения модуля. А путь-то по сравнению со старым местоположением форума в файловой системе естественно не совпадает. Меняю путь на свой, сохраняю, перезапускаю апач, захожу и..... Уря! После всех (ещё пока неотключенных) ошибок нарисовался "вельком срин форума".
Ещё раз внимательно просмотрел сообщения об ошибках, кроме ворнингов про формат даты ничего больше не нашёл. Ну и хрен с ним, значит можно снова отключать вывод ошибок на экран.
Code:
display_errors = Off
Пытаемся зайти в админку (эээххх, вспомнить бы пароль 2010 года
) - естественно, нифига не выходит.
Ладно, думаю, зайду с фасада. Типа "кто тут в цари крайний? Никого?" Ввожу имя, пароль, выскакивает сообщение:
Quote:
|
не удается добавить cookies, header уже отправлен
|
Что за зверь.... Впервые такое вижу.... Но при перезагрузке страницы, вижу, вроде на форум-то пустило. По-крайней мере, "добро пожаловать", сказало. Ну уже хорошо. Пытаюсь зайти в тему - то же самое сообщение. Ладно. Полез искать в тырнетах. Люди пишут, мол, надо в настройках форума (в админке) проверить домен размещения печенюх. А в админку-то я зайти не могу. Ну, думаю, горе-то какое. Ч0 делать? Подумалось, а не грохнуть ли мне таблицу (в смысле, очистить) vb3_session, по которой вечно множество косяков именно из-за большого числа просроченных сессий, которые по разным причинам не удаляются из базы. Но снова зашёл на форум - о! В одну тему зашёл, в другую зашёл - нормально, читает. Зашёл в личку - там что-то всё пишется вопросиками в ромбиках. Ну, вот, думаю, вот и кодировочка проявилась. Без особой надежды ткнул на сохранённое сообщение - а оно нормально открылось, по-русски. Нажал показать список - нормально, всё по-русски. Ну и хорошо, думаю, процесс идёт.
Ну а тут вспомнился старый пароль на админку. Зашёл, пустило, нормально. Пошёл сразу в "обслуживание" восстановить/оптимизировать таблицы, потом перестроить информацию о разделах, о темах, перестроить счётчик сообщений.....
И всё, движок ожил, всё показывается, поиск работает, сообщения добавляются/удаляются. Отлично!
Проверяю работы хаков. Комментирую в config.php строку
define ('DISABLE_HOOKS',true)
на всякий случай перезапускаю апач и захожу. Всё работает. Даблпосты слиты, комментарии админов стоят, статистика рисуется.
Значит, считаем, что цель - достигнута? Думаю, да. Дальнейшие настройки, проверки исполнения крона - это уже отдельная песня. Главное, что двиг - живой и информация - на месте.
Спасибо всем, кто дочитал до конца. Надеюсь, хоть кому-нибудь моя информация окажется полезной и хоть один человек не наступит на те грабли, по которым протанцевал свою "джигу" я. Прошу прощения за много букв, но я люблю приукрасить текст
Прошу прощения у Администрации и Гуру, если ещё раз описал то, что уже миллион раз было на Форуме, находится в FAQах и инструкциях - честно пытался искать, но нашлось не всё. Ну и если вдруг ошибся разделом.... Сильно не ругайте
Спасибо ещё раз. Всем желаю высокопроизводительных серверов, корректной работы движков, скриптов и дополнений, ну и просто хорошего настроения!
История одного восстановления из бэкапа.
