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

А места на диске свободного достаточно? Такое часто происходит, при нехватке места. При этом на совершенно целых дисках.

"PVasili" wrote:

Хотя InnoDB таблиц нет вообще в базах.

Всё же есть.

"ttenz" wrote:

но та же история - mysql не запустилась.

А в логе что?

"ttenz" wrote:

du -sk /var/lib/mysql
11518512 /var/lib/mysql

Вот только проблема в том, что этот параметр управляет выделением памяти под страничный кеш innodb. А 11ГБ оперативки на виртуалке вашей конечно нет.
Кстати, с помощью du считать объём данных в базах не правильно - их меньше, возможно, очень значительно.

11 гигов это явно больше, чем есть на виртуалке. Надо было читать внимательнее, и подходить разумно.
Остальное надо измерять после прогрева кеша запросов.
Медленнее уж точно быть не должно.

Toshik:По скорости также, тут все почти время занимает работа самого php. А вот памяти, специализированный менеджер процессов, тратит в пустую куда меньше апача, с массой модулей до кучи.

"ttenz" wrote:

благодарю, есть место для совершенства.

Минимум:
innodb_flush_method = O_DIRECT

innodb_buffer_pool_size
В идеале иметь чуть больше объёма базы, но это не всегда возможно. В любом случае лучше выделить по возможности больше.

innodb_file_per_table
Очень полезная опция, позволяющая не тратить лишнее место в разрастающемся ibdata, и уменьшить последствия при повреждении его структуры.

А вот это напрасно, особенно, при использовании innodb.

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

В большинстве случаев, всё будет работать до следующей мажорной версии, т.е. да, до 8.

Вы сравниваете неправильно:
Вместо

должно быть:

Вероятно, проблема вот в этом: https://www.drupal.org/node/1845964 и её уже пофиксили в последнем RC.
А вообще, не используйте лучше не релизнутые ещё модули, особенно, если не готовы к таким поворотам.

"denserdv" wrote:

владелец и группа www-data, права на файл 644 - я так понимаю, через веб загружены файлы.

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

Если у вас друпал был не обновлён, то вполне возможно и та уязвимость - её признаки описаны по вашей ссылке, как и методы лечения. А вот если не она, то придётся искать дальше.

Это php shell - средство выполнения кода на сервере, возможно специализированная спамилка. В принципе, выяснять что это конкретно, нет особого смысла. Это, конечно, надо удалить, но этого мало. Надо понять, как он туда попал, и пресечь возможность заливать такое в будущем.

«отрубай фтп, используй sftp»
Это отчасти правильно, но во многих случаях, слишком радикально и не всегда возможно. Ну и от кражи пароля спасает только при правильном использовании...

Если есть подозрение на ftp, это можно проверить, посмотрев логи ftp сервера.
Соответственно, если подтвердится - будет информация, кому надо лечить машинку, ну и пароли естественно надо сменить.
Если нет, то надо дальше искать путь взлома...

disable_functions можно установить только в php.ini
Пинайте хостера, если у вас шаред, или проверяйте наcтройки php если вы на сервере/виртуалке.

В стандартном .htaccess из поставки drupal в корне сайта, есть вполне рабочий пример редиректа в обе стороны.
Если не работает, проверьте - а может у вас вообще не обрабатываются .htaccess файлы?
Такое может быть, например, если используется не Apache, или если нужные настройки вынесены в конфиг apache, и AllowOverride установлен в None.

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

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

Как запущен php, и от какого пользователя работает он и Апач?

Если скрипт запущен от одного пользователя, он не создаст файлы владельцем которых является другой пользователь.
Вероятно, файлы создаёт какой-то другой процесс, типа какого-нибудь скрипта запускаемого по крону, не от того пользователя. Или, может, у вас друпал обновляется через ftp, используя неправильного ftp пользователя.

"Plazik" wrote:

http://revisium.com/ai/[/quote]
Таких скриптов разной степени навороченности немало. Но доверять результатам их работы полностью не стоит.

Надёжно в автоматическом режиме найти все изменённые файлы, можно только сравнив с чистым бекапом. Это можно сделать с помощью diff. Или с помощью системы контроля версий, если вы её используете.
И то могут остаться "закладки" в базе данных.

CSV это текстовый файл, в нём нет никакого форматирования, т.е. не сохраняются, ни выделение, ни шрифты, ни цвета, только символы.

Решить эту проблему, можно убрав file_put_contents из disable_functions настройках php.
Как это сделать в деталях, зависит от того, где хостится ваш сайт.

"ladovod77" wrote:

Executed 748 queries in 1369.6 ms. Queries exceeding 5 ms are highlighted. Page execution time was 3333.41 ms. Memory used at: devel_boot()=2.31 MB, devel_shutdown()=56.33 MB, PHP peak=57.75 MB.
Почему-то много времени затрачивается на DrupalDatabaseCache::getMultiple - 523.2 ms,

Смените хостера.