Чукча не читатель? Объяснили выше, что "проблему" высосали из пальца - кто-то просто не читает документацию.
"Медленный канал". Будут качать дольше, чем другие клиенты. Одна из причин повесить nginx перед апачем.
Если "проверяли" как выше - проблема не с VPS, а с Вашей "проверкой".
PS: Приводя server_status - Вам не следовало его так редактировать. Я о том, что Вы вырезали вообще вырезали работающие процессы из листинга (те, что в scoreboard отображаются у Вас W и т.п. значками). Это на будущее.
Это ведь не "из дистрибутива", верно?
А зачем? Чем не устроил штатный пакет в центосе? Я вот посмотрел исходники - ошибка какая-то новая. Аналогичной строки нет, по крайней мере в 5.1 (версия в дебиан).
Да, действительно, пропустил. :(
Не, в дистрибутиве точно другая версия. Там 5.0.x, насколько я помню.
Отвечать - "А сделать это так: <туто ссылко к документации>". Сложно?
Это конечно тоже временная мера. Пройдет время - наклепают sftp клиентов, которые умеют хранить пароль в plain-text и/или вирусни, которая собирает беспарольные ключи и ломится потом с ними на хостинг. Зато в сухом остатке все-равно получите защищенное соединение для передачи файлов.
Я не понимаю, как такое можно "понимать" - когда снизу у Вас там нарисована легенда. И нормальным русскиманглийским языком написано:
Перевести?
[ERROR] innobase_buffer_pool_size can't be over 4GB on 32-bit systems
ЧТО непонятно? Поставили поди 32-битную версию mysql. Вот и все.
Поставьте 64-bit, проще всего непосредственно из дистрибутива.
Я не писал такую фразу, так что будьте любезны: либо цитировать нормально - либо убрать кавычки. За тараканов в Вашей голове я не отвечаю.
Для обычного хостинга как раз ftp - не нужен. Поплюются немного, но если документация хорошая - освоят sftp без проблем. Зато вирусня лезть больше не будет.
Ну, крайне надеюсь, что Вы всерьез восприняли совет о переустановке сервера с нуля. Хотя фраза во множественном числе
... Школу закончить - самое первое.
Апачу не даст? (Мы-то помним про Ваш совет с suPHP/suexec).
О да! Будем читать на ночь?
Причем здесь какие-то "дырки"?
Судя по Вашей же информации - "лилось все это по фтп". Какой-то любитель "клубнички" сидит на загаженном вирусней компе - вот с него гадость всякая и лазит по фтп.
Так что не факт, что веб здесь вообще "причем". Вы хоть работоспособность веб-шеллов проверяли?
Вот то, что Вы утверждаете что вычищен /var/log/ - куда серьезней. С Ваших слов - получается кто-то root-доступ добыл. Здесь нужен крайне аккуратный аудит, а лучше просто реинсталл сервера заново (дешевле).
man find, man xargs
Еще мои две копейки: это ОЧЕНЬ ПЛОХАЯ идея.
Помимо того, что написал madoff, ведь это файлы пользователя - а может Вы удалите что-то ему нужное? Не собачье дело хостера, извините, в файлах клиента ковыряться. Тем более "по крону".
Нанять админа. Не по принципу "поломалось-пошел на форум-нашел Васю-Вася починил" - а на постоянную ставку.
Подумать над тем, чтобы вообще не давать пользователям ftp-доступ. Давать SFTP и только в крайнем случае SSH.
Мы видим, что за сервер отвечаете Вы. Администрируете его - Вы. С Вас и спрос. Может нажав пару клавиш в консоли - Вы создали такую дыру, что вся "безопасность" мегаадмина пошла в ж***! :-)
А что Вам там настраивал какой-то Вася - нужно было бы с ним договориться о более вменяемых условиях. Например, о постоянном сопровождении сервера.
Это смотря как спросите. Если как здесь в данном случае - существенной разницы не ждите.
Хотите "просто и быстро" - читайте ответы внимательно, а не до первой фразы. Вам вон задали один и тот же вопрос по-разному:
Почему Вы не ответили?
find /www/storage/ -name func.php -print0 |xargs -r -0 -n 1 -I {} cp /www/includes/func.php {}
