Блог о технологиях, технократии и методиках борьбы с граблями
В начале апреля были обнаружены проблемы уязвимости веб-сервера Apache, благодаря которым вредоносное ПО Darkleech могло заражать компьютеры посетителей через уязвимости браузеров, используя iframe и JavaScript. Причем вредоносный код размещался как модуль Apache, что затрудняло его выявление.
Сам механизм заражения не был ясен, но уязвимости подвергались сервера под управлением панелей администрирования cPanel и Plesk.
После переезда блога WordPress на новый хостинг, образовался довольно интересный глюк- не хотели грузиться изображения в Media библиотеку, причем ошибка была такова, что не система не может загрузить изображение по старому пути, то есть имевшемуся на старом хостинге.
В одном из проектов мне пришлось прорабатывать тему видеосервера для телепрограммы под высокой нагрузкой, порядка 70-80к уников в сутки, которые генерили около полуляма просмотров, и что самое интересное- единственные кто мне смог дать внятную консультацию- это так называемые AWM, то есть вебмастера работающие в сфере адалта, так как в этой нише условия наиболее приближены к требуемым мне: видео и высокие нагрузки.
После ряда консультаций я продолжил общение с помогавшими мне людьми, так что когда мне предложили статью на тему балансировки нагрузки высоконагруженного сервера, на примере работающего проекта, я не отказался. Далее сохранена авторский стиль изложения. Учитывая что я с несколькими бывшими коллегами вел общение на тему моего проекта и творчества в интернете, то полагаю, что в дальнейшем буду публиковать еще статьи коллег по цеху.
Вебмастера, как правило, не особенно вникают в технические особенности настройки серверов – это дело администраторов. Но логику стоит знать, хотя бы затем, чтобы иметь возможность объяснить своему администратору, как и для чего вы хотите настроить вашу систему.
Как то так стало получаться, что покупаю последнее время частенько сайты с аука, и уже не первый раз попадаю на историю когда продавец не помнит логин админа блога, так что все заканчивается фразой “ну поменяйте в базе”.
Понятно что это делается легко, но все таки в моем понимании это моветон. А для кого то и вполне себе проблема, так как люди частенько обращаются с какими то дикими проблемами, вроде того что сайт не открывается в Яндексе и Google, подразумевая что он просто не проиндексирован.
Стал тут ставить на один из своих блогов, крутящихся под WordPress, плагин Exec-PHP, дающий возможность стартовать произвольный пхп код не только из тела файлов шаблона, но и из постов, страниц и виджетов.
Имея собственный веб-сервер перед пытливым умом веб-мастера встает проблема, что все это барахло надо бэкапить, причем желательно регулярно и по расписанию. Ну и поскольку не имеет смысла хранить ключи от сейфа в верхнем ящике письменного стола, то это богатство необходимо куда то выносить с сервака, причем желательно подальше.
Поэтому разберемся как нам заархивировать данные веб-сервера и вынести по фтп куда нить на сторону. Теоретически можно конечно воспользоваться ssh или rsync соединением, но о последнем я отпишусь позже, так как по хорошему, перед началом систематических резервирований, нам следовало бы забэкапить вообще всю систему, с тем чтобы в случае каких то косяков сначала разворачивать её, а потом уже по верху выкатывать имеющиеся архивы.
Иногда бывает такая ситуация что какой то скриптик веб-сайта ругается матерными буквами, гласящими: Fatal error: Allowed memory size of XXXXX bytes exhausted (tried to allocate XXX bytes) on /site/XXXXX
Данная ошибка говорит нам о том, что php скрипт пытается заюзать чутка больше памяти, чем это разрешено в файле настроек php.ini
