Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 115
PPs. Хостера не упомянаю сознательно.
жаль
Действительно жаль. Может в личку кинете?
Всем, кому сильно интересно, предлагаю провести собственное расследование. Зацепка находится примерно по середине топика :)
Детектив из меня никакой, попробую предсказать.
На моей памяти абсолютно не старается разобраться в проблеме и предлагает перейти на выделенный сервер .masterhost
На моей памяти абсолютно не старается разобраться в проблеме и предлагает перейти на выделенный сервер .masterhost
поддерживаю догадку.
homm?
homm?
Да тут навыков детектива никаких не надо:) Надо посмотреть адрес картинки со скриншотом, выйти на сайт stratero.ru, узнать его ip (ping stratero.ru), зайти по адресу 77.221.130.2 и увидеть в сообщении об ошибке ссылку на infobox))
Они все предлагают перейти на выделенный сервер… Только некоторые предлогают сначала перейти на VPS :)
peterhost?
У меня тоже один сайт хостится не Петерхосте. Проблемы возникают, и решаются порой черт знает как. Давича вдруг перестал работать include. Пожаловался. Через 3 часа заработало. А на следующий день нас отключили за превышение места на диске. Нагрузка на сервер возросла в 10 раз. Опять жаловался. Опять часа через 4 только включили. Не извинились, а сообщили: передаем вас в очередь для подключения.
Когда я задал вопрос, может мне кое-что надо подправить, товарищ от тех.службы заявил: я в этом не разбираюсь, я не знаю php! Типа я к нему прилип как банный лист…
Пока не пожаловался боссу, мое письмо компетентному специалисту не передали.
Очень бы хотелось получить от крупного и известного хостинга лучшего сервиса.
Справедливости ради должен заметить, что чаще всего вопросы решаются быстро. Но мелкие косяки вечно портят общее впечатление.
Когда я задал вопрос, может мне кое-что надо подправить, товарищ от тех.службы заявил: я в этом не разбираюсь, я не знаю php! Типа я к нему прилип как банный лист…
Пока не пожаловался боссу, мое письмо компетентному специалисту не передали.
Очень бы хотелось получить от крупного и известного хостинга лучшего сервиса.
Справедливости ради должен заметить, что чаще всего вопросы решаются быстро. Но мелкие косяки вечно портят общее впечатление.
Не нужно гадать, нужно просто посмотреть.
П.С.: Я не ожидал от них такого…
П.С.: Я не ожидал от них такого…
Удивляться здесь нечему совершенно. Когда ваш сайт начал напрягать сервер — его, чтобы совсем не отключать, перенесли в отстойник. Это обычная практика, которую практикуют многие хостеры.
Дело в том, что часто бывает, что клиенты не хотят разбираться, почему их софт грузит сервер. Причем не то чтобы оперативно, а вообще разбираться — мол, раньше все работало, что вы сделали, верните все на место :)
Но сайт ведь создает нагрузку — мешает соседям. Поэтому вменяемый хостер либо отключит сайт, либо перенесет его в отстойник и, естественно, что одного клиента-грузчика спрашивать никто не станет в сете получения ответа через долгое время или не получения его вовсе. Хостеру нужно обеспечить комфортную работу остальным 500-1000 клиентам на том же железе :)
P.S. Пользоваться другой папкой для сохранения сессий можно — рад что в вашем случае это помогло, но в современных системах /tmp обычно монтируется как tmpfs. Это фактически аналог ram drive. Число файлов в папке при этом не долно играть особой роли. А хранение сессий на физическом диске — это наоборот может быть медленнее.
Дело в том, что часто бывает, что клиенты не хотят разбираться, почему их софт грузит сервер. Причем не то чтобы оперативно, а вообще разбираться — мол, раньше все работало, что вы сделали, верните все на место :)
Но сайт ведь создает нагрузку — мешает соседям. Поэтому вменяемый хостер либо отключит сайт, либо перенесет его в отстойник и, естественно, что одного клиента-грузчика спрашивать никто не станет в сете получения ответа через долгое время или не получения его вовсе. Хостеру нужно обеспечить комфортную работу остальным 500-1000 клиентам на том же железе :)
P.S. Пользоваться другой папкой для сохранения сессий можно — рад что в вашем случае это помогло, но в современных системах /tmp обычно монтируется как tmpfs. Это фактически аналог ram drive. Число файлов в папке при этом не долно играть особой роли. А хранение сессий на физическом диске — это наоборот может быть медленнее.
так-то вроде все правильно говорите, но! я покупаю хостинг, т.е. не только железо, но и программное обеспечение. В описанном примере человек столкнулся с проблемой ПО, точнее с его кривой настройкой. Ну неужели правда не за мной будет?
Я купил новый автомобиль, после заезда в сервис Вы, не спрашивая меня, заменили коробку передач, после этого автомобиль сильно потерял в мощности. Я сам разобрался в проблеме и выяснил, что коробка была установлена под углом, что вызывало дополнительную нагрузку на передачу вращательного момента.
Я купил новый автомобиль, после заезда в сервис Вы, не спрашивая меня, заменили коробку передач, после этого автомобиль сильно потерял в мощности. Я сам разобрался в проблеме и выяснил, что коробка была установлена под углом, что вызывало дополнительную нагрузку на передачу вращательного момента.
Лучше уж упомяните, ибо хоститься у хостера, который хранит сессии в общей папке tmp не хорошо, и таких хостеров желательно опасаться.
session.save_path /tmp
Хостинг Центр РБК =)))
Хостинг Центр РБК =)))
И чем же плохо хранить сессии в tmp?
объективно объясните пожалуйста :)
объективно объясните пожалуйста :)
могу предположить, что в сессиях хранятся данные об авторизации и получить имя сессии из tmp могут все.
все это кто? =))) матчасть говорит о том, что сессии созданы для передачи данных между сессиями, некая «заплатка» в http протоколе. А к /tmp на чтение любых файлов могут получить доступ только те, кто имеют доступ к серверу. Да и потом. Если не сервере 1000+ проектов, и все сессии хранятся в /tmp, как вы разберете, какая чья?
я предположил лишь брешь возможную.
в целом вы правы. Получив доступ к серверу даже на правах nobody (php-inj etc) можно читать сессии. Но это последнее, что будет делать «хакер», получив доступ к серверу даже на правах nobody.
> Но это последнее, что будет делать «хакер», получив доступ
Вы не поняли. Есть интерисующий ваш сайт на виртуальном хостинге, все что вам нужно — зарегестрироваться у того же хостера на тот же сервер. При этом ломать его не нужно. Я пробовал делать листинг дириктории — полуилось. Читать чужие файлы я не пробовал, но по умолчанию права в системе 644, должно было получиться.
Вы не поняли. Есть интерисующий ваш сайт на виртуальном хостинге, все что вам нужно — зарегестрироваться у того же хостера на тот же сервер. При этом ломать его не нужно. Я пробовал делать листинг дириктории — полуилось. Читать чужие файлы я не пробовал, но по умолчанию права в системе 644, должно было получиться.
Как видно из скриншота, пхп запускается в режиме CGI, скорее всего через suPHP.
В этом случае на файл сессии ставятся права 0600, что исключает возможность чтения/записи другими пользователями.
В этом случае на файл сессии ставятся права 0600, что исключает возможность чтения/записи другими пользователями.
файловая система ext3 даже близко, даже на каплюшку, даже чуть-чуть не реляционно-ориентированная. Она больше напоминает стакан с водой, который на глаз на 60% наполнен или на 40% пуст.
По моему опыту количество объектов (файлов, директорий, симлинков) в каждой директории не должно привышать 5к. Тем не менее я лично не храню более 1к в директории. И вообще стараюсь избегать от хранении чего-либо в файловой системе. Сессии — в базу, возможно в мемкеш, если нагрузка не высока. Но, соответственно, картинки в базу пока класть накладно, кладем на диск, но в поддиректории обязательно.
php же при работе с сессиями, читает директорию сессий каждый раз при удалении, соответственно, если там дохрена объектов, он начинает жестко тормозить.
Не зря в php ветвление директории для save_path предусмотрено, цитирую:
По моему опыту количество объектов (файлов, директорий, симлинков) в каждой директории не должно привышать 5к. Тем не менее я лично не храню более 1к в директории. И вообще стараюсь избегать от хранении чего-либо в файловой системе. Сессии — в базу, возможно в мемкеш, если нагрузка не высока. Но, соответственно, картинки в базу пока класть накладно, кладем на диск, но в поддиректории обязательно.
php же при работе с сессиями, читает директорию сессий каждый раз при удалении, соответственно, если там дохрена объектов, он начинает жестко тормозить.
Не зря в php ветвление директории для save_path предусмотрено, цитирую:
There is an optional N argument to this directive that determines the number of directory levels your session files will be spread around in. For example, setting to '5;/tmp' may end up creating a session file and location like /tmp/4/b/1/e/3/sess_4b1e384ad74619bd212e236e52a5a174If . In order to use N you must create all of these directories before use. A small shell script exists in ext/session to do this, it's called mod_files.sh, with a Windows version called mod_files.bat. Also note that if N is used and greater than 0 then automatic garbage collection will not be performed, see a copy of php.ini for further information. Also, if you use N, be sure to surround session.save_path in "quotes" because the separator (;) is also used for comments in php.ini. 
сипанель (и полагаю ещё пачка панелек) ставит такую переменную в РНР по умолчанию, с какой то стороны в этом есть смысл
Предлагаю личкой :)
Статья интересна и познавательна. Люблю над такими коротать время…
P.S.: Веселые ребята эти PHPшники =) Одни из них эволюционно развивают технологию которую по хорошему, давно нужно разработать с чистого листа и забить на совместимость со старым кодом, который можно поддерживать и на старых версиях интерпретаторов. Другие разрабатывают на этой технологии проекты для которых гораздо лучше подошли бы java, ruby, asp.net, и т.п.
P.S.: Веселые ребята эти PHPшники =) Одни из них эволюционно развивают технологию которую по хорошему, давно нужно разработать с чистого листа и забить на совместимость со старым кодом, который можно поддерживать и на старых версиях интерпретаторов. Другие разрабатывают на этой технологии проекты для которых гораздо лучше подошли бы java, ruby, asp.net, и т.п.
на сколько я понял, о PHP Вы плохого мнения, но при условии хорошей архитектуры кода, PHP мало чем уступает тем языкам которые вы привели ввиде альтернативы… везде есть свои плюсы и свои минусы, и нет ни одного языка без минусов, об этом не следует забывать тоже
Буквально вчера один старый перловик, решивший попробовать приручить wordpress глядя на мешанинку кода php воскликнул — «Вообще, более ужасного языка с точки зрения синтаксиса не могу себе представить». Это о пхп да, после строгого синтаксиса perl.
Надо же, спам-боты и сюда добрались.
Узнаю стиль mtw.ru
Да, мтв приколисты, те еще. Вспоминаю как у них в своё время бэкап базы на шаред хостинге нужно было «заказывать» по телефону или почте, ибо админка такой функциональности попросту не поддерживала, как сейчас не знаю.
Также.
Мы пароль для ФТП нового сервера, на который нас перевезли с уведомлением по факту, неделю с хвостиком пытались выбить.
А еще у меня не получилось им объяснить что мы хотим домен третьего уровня, завязанный на другой наш хостинг, арендуемый у них же.
(хотели chat.xxx.yy, но после ответа на детальное письмо с примерами того как пользователь будет ходить, описания проблемы и пр на трех А4 «объясните что и куда вы хотите», решили оставить chat.xxx.yy.servname.mtw.ru = уродливо, но работает и трогать боимся теперь уже)
Мы пароль для ФТП нового сервера, на который нас перевезли с уведомлением по факту, неделю с хвостиком пытались выбить.
А еще у меня не получилось им объяснить что мы хотим домен третьего уровня, завязанный на другой наш хостинг, арендуемый у них же.
(хотели chat.xxx.yy, но после ответа на детальное письмо с примерами того как пользователь будет ходить, описания проблемы и пр на трех А4 «объясните что и куда вы хотите», решили оставить chat.xxx.yy.servname.mtw.ru = уродливо, но работает и трогать боимся теперь уже)
Нифига се!!! И после этого вы еще у них до сих пор хостируетесь?!?!??!?!?!??!?!?!?!??!
Если честно, в шоке.
Если честно, в шоке.
мало знаков, мало
«хоститесь» кстате
«хоститесь» кстате
Да, мало. Несоизмеримо с возникшим недопониманием.
А нормы языка для данного слова еще нет, на сколько я знаю. Хотя для больше уверенности лучше наверное уточню.
А нормы языка для данного слова еще нет, на сколько я знаю. Хотя для больше уверенности лучше наверное уточню.
Хостить -> Хостите -> Хоститесь(себя).
Нет, не так. Точнее не совсем так. Специально уточнял. Самое главное то, что как я уже говорил, что для данного глагола нормы языка еще нет. Тебе привычнее слышать «хоститесь». Мне — «хостируетесь». И нет тут правильного или неправильного варианта написания, поэтому второе замечание мимо кассы.
Привожу дословное объяснение:
"… норма же определяется исходя из употребления. то есть статистически определяют, что вот в языке появилось новое слово. и не так, что когда его знает 11 341 человек — это не норма, а когда 11 342 человека уже норма. нет такой границы и есть некоторый элемент условности, особенно когда возникают варианты. вот однозначно вИшневыый или индУстрия уже устарело. Как быть с петлЯ-пЕтля пока неясно, поэтому указывают два варианта, хотя проводили исследования. Тут еще сложнее, потому что статистику вообще никто пока не собирал. Причем обычно учитывают не только количественный показатель, но и качественный (то есть если все клерки говорят договорА и пОртфели, это ничего не значит, пока норма не преобладает у большинства во ВСЕХ СОЦИАЛЬНЫХ ГРУППАХ -приблизительно так, хотя механизм подсчета сложнее ). Сказать, что является нормой, без этого невозможно, так как само слово не дает оснований для такого вердикта. "
Привожу дословное объяснение:
"… норма же определяется исходя из употребления. то есть статистически определяют, что вот в языке появилось новое слово. и не так, что когда его знает 11 341 человек — это не норма, а когда 11 342 человека уже норма. нет такой границы и есть некоторый элемент условности, особенно когда возникают варианты. вот однозначно вИшневыый или индУстрия уже устарело. Как быть с петлЯ-пЕтля пока неясно, поэтому указывают два варианта, хотя проводили исследования. Тут еще сложнее, потому что статистику вообще никто пока не собирал. Причем обычно учитывают не только количественный показатель, но и качественный (то есть если все клерки говорят договорА и пОртфели, это ничего не значит, пока норма не преобладает у большинства во ВСЕХ СОЦИАЛЬНЫХ ГРУППАХ -приблизительно так, хотя механизм подсчета сложнее ). Сказать, что является нормой, без этого невозможно, так как само слово не дает оснований для такого вердикта. "
Думаю, в общем-то «хостить» употребляют из-за того, что это слово короче, чем «размещать», и звучит немного приятнее. «Хостировать» — и длинное, и звучит (имхо) как нелепая попытка сделать из английского слова русское. Говорят ведь гуглить, а не гуглировать, парсить, а не парсировать и т.д.
Да, тут соглашусь. В языке есть такая тенденция как использование более короткой формы. Но. Это не всегда работает. Но в варианте «хостить» есть проблема с образованием первого лица. Что я делаю — хошу. При варинате «хостировать» такой проблемы нет. Что я делаю — хостирую.
Яндекст, кстати, ближе к варианту с «р». «Хостируемых сайтах». slovari.yandex.ru/dict/internet/article/269.htm?text=%D1%85%D0%BE%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C
Тут мне уже и профессор лингвистики свое мнение озвучил:
"… что по аналогии со словом ДЕЛЕГИРОВАТЬ правильнее ХОСТИРОВАТЬ. Cкорее всего надо воспринимать это как стилистически дифференциорованные варианты. То есть в разговоре — хостить, а в более официальной обстановке — хостировать."
Но лично для меня в разговоре более привычно «хостировать», поэтому лично буду все же за этот варинат.
А вообще появилась идея провести опрос. Возможно и сделают такой опросик по сети.
Яндекст, кстати, ближе к варианту с «р». «Хостируемых сайтах». slovari.yandex.ru/dict/internet/article/269.htm?text=%D1%85%D0%BE%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C
Тут мне уже и профессор лингвистики свое мнение озвучил:
"… что по аналогии со словом ДЕЛЕГИРОВАТЬ правильнее ХОСТИРОВАТЬ. Cкорее всего надо воспринимать это как стилистически дифференциорованные варианты. То есть в разговоре — хостить, а в более официальной обстановке — хостировать."
Но лично для меня в разговоре более привычно «хостировать», поэтому лично буду все же за этот варинат.
А вообще появилась идея провести опрос. Возможно и сделают такой опросик по сети.
Вообще, спор о несостоявшемся слове бессмысленен. Также как и «гАмать» или «гамАть», «гУглить» или «гуглИть» и т.п.
В официальной переписке, я думаю, не «хостируют», а «предоставляют услуги хостинга» или «размещают сайт на площадке».
В официальной переписке, я думаю, не «хостируют», а «предоставляют услуги хостинга» или «размещают сайт на площадке».
В петерехосте также.
А хостер после объяснения причины проблемы не попытался извиниться? Как я понимаю суть проблемы в том, что они перенесли сайт на новый сервер с изрядно уже захламленной tmp директорией?
С одной стороны я конечно могу понять хостера, копаться в движке для каждой проблемной площадки не стоит, да и люди работающие с движком уж нужно думать быстрее и лучше разбируться в проблема да и сам движок не повредят. С другой стороны когда такая явная связь с нагрузкой и незапланированным переносом и такое ультимативное заявление… опять же, площадка забирает большие ресурсы, ну так и ограничивайте её в пределах указанных на тарифном плане, kill процессу еще ни кто не отменял… Не, хостер ясно не прав.
Кстати, отчего его не означить то? Страна должна знать своих героев, тем более прецедент то есть, история то реальная?
С одной стороны я конечно могу понять хостера, копаться в движке для каждой проблемной площадки не стоит, да и люди работающие с движком уж нужно думать быстрее и лучше разбируться в проблема да и сам движок не повредят. С другой стороны когда такая явная связь с нагрузкой и незапланированным переносом и такое ультимативное заявление… опять же, площадка забирает большие ресурсы, ну так и ограничивайте её в пределах указанных на тарифном плане, kill процессу еще ни кто не отменял… Не, хостер ясно не прав.
Кстати, отчего его не означить то? Страна должна знать своих героев, тем более прецедент то есть, история то реальная?
Сессии можно в memcached хранить, есть ли способы быстрее чем memcached?
Не понял, в чем проблема?
session.save_handler = memcache
session.save_path = «tcp://127.0.0.1:11211»
session.save_handler = memcache
session.save_path = «tcp://127.0.0.1:11211»
сессии в мемкеше отличное решение до тех пор, пока количество серверов под мемкеш не больше 1 и он не падает. на удивление, memcache достаточно не стабильная штука под нагрузкой.
Посмотрел своего хостера — все в /var/spool/php-sessions/php5, 70'000 файлов :-)
session.gc_divisor 100 100
session.gc_maxlifetime 1440 1440
session.gc_probability 1 1
Хммм, что им можно посоветовать?
session.gc_maxlifetime 1440 1440
session.gc_probability 1 1
Хммм, что им можно посоветовать?
В дебиане и убунте хорошо придумано, по крону запускается скриптик и делает всю грязную работу, чтобы не напрягать ПХП.
Что-то типа:
21,51 * * * * root [ -d /tmp/php-sess/ ] && find /tmp/php-sess/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm
Что-то типа:
21,51 * * * * root [ -d /tmp/php-sess/ ] && find /tmp/php-sess/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm
а что за хостинг то? обычно дело в троянце у того кто имеет фтп доступ на сервак + есть скрипт для вычистки есго етого гавнища за пару секунд, я его находил гдето и клиенту чистил 6000 файлов однажды, могу снова поискать
так вот, обчно это троянец который захламляет все php и html файлы которые видит, в той папке в которую ему есть доступ, посему тут 2 варианта — либо у вас он сидит, либо у «кого-то» кто имеет доступ к вашей папке ( как вариант ко всему корню сервера)
логи фтп смотреть нужно
так вот, обчно это троянец который захламляет все php и html файлы которые видит, в той папке в которую ему есть доступ, посему тут 2 варианта — либо у вас он сидит, либо у «кого-то» кто имеет доступ к вашей папке ( как вариант ко всему корню сервера)
логи фтп смотреть нужно
насчёт троянца я имел ввиду как раз ту прогу что заражает файлы, я так понимаю касперский ругается на уже заражённые хтмл-ки и пхп?
немного непонял про доступ, если есть ссх это уже хорошо, хостинг я так понимаю шаред и это многое обьясняет
IE тут кстати тоже нипричём был бы, но факт заражения с вашего компьютера мы вобщем то отсекли, в таком случае нужно смотреть логи фтп
как вариант создать dummy папку с файлом и назвать его как нибудь нестандартно, а потом, когда его «поразит» эта весёлая вещица — смотреть свои фтп логи на предмет упоминания этого файла, если такого там небудет — виноват хостер
немного непонял про доступ, если есть ссх это уже хорошо, хостинг я так понимаю шаред и это многое обьясняет
IE тут кстати тоже нипричём был бы, но факт заражения с вашего компьютера мы вобщем то отсекли, в таком случае нужно смотреть логи фтп
как вариант создать dummy папку с файлом и назвать его как нибудь нестандартно, а потом, когда его «поразит» эта весёлая вещица — смотреть свои фтп логи на предмет упоминания этого файла, если такого там небудет — виноват хостер
попробуйте у хостера логи ftp попросить посмотреть
если заливают по ftp — одна история, если нет другая.
Если не по ftp — погрепайте логи апача на post в этот файл.
по нашей статистике:
троян — слабый пароль в 90% случаях,
в 9% — уязвимость в клиентских скриптах
в 1% уязвимость сервера.
если заливают по ftp — одна история, если нет другая.
Если не по ftp — погрепайте логи апача на post в этот файл.
по нашей статистике:
троян — слабый пароль в 90% случаях,
в 9% — уязвимость в клиентских скриптах
в 1% уязвимость сервера.
На самом деле стоит на машине с которой входят в админку сайта (и ведь наверняка из под IE) провериться на вирусы.
Ну а так же подновить версию движка, а так же погуглить на тему стандартных эксплоитов для данного ПО. Стандартные движки имеют стандартные дыры через которые лезут стандартные вирусы ;)
Из всех случаев когда мне приходилось разбираться с заражением сайта все относились к категории «дыра в самом движке». Либо в плохо написанном ядре (реже), либо в криво написанных модулях (чаще). Ну и фактор настройки сервера бывает играет роль.
Ну а так же подновить версию движка, а так же погуглить на тему стандартных эксплоитов для данного ПО. Стандартные движки имеют стандартные дыры через которые лезут стандартные вирусы ;)
Из всех случаев когда мне приходилось разбираться с заражением сайта все относились к категории «дыра в самом движке». Либо в плохо написанном ядре (реже), либо в криво написанных модулях (чаще). Ну и фактор настройки сервера бывает играет роль.
Был случай один в один: поймал какой-то вирус, который расшифровывал данные от ФТП-аккаунтов, храянщихся в конфиг-файлах Total Commander и преспокойно заходил на эти ФТПшники. Его деструктивное действие как раз и заключалось в дописывании в index-файлы некоего js-кода и ифрема, ведущего на сайт злоумышленника. Возможно у Вас модификация этого трояна. Проверьтесь.
Очень уж напоминает одного *Другого Хостера не упомянаю сознательно*, который ещё и дорогой регистратор. Не оплатил хостинг как то — на индексной странице появился не добрый js.
chmod 0444?
у меня тоже такое было, выставил нормально права, и перестало
Вообще-то выход. Это же средства ОС, под которой крутится проект. Тем более, встроенные. Единственный минус — при изменении файлов приходится менять вручную chmod, но для этого достаточно скрипта .sh ))) А другой защиты толковой нет (((
Имхо, костыли — это добавлять функции подсчета контрольных сумм, размеров файлов и др. А такая защита наименее ресурсоемка и наиболее проста в реализации
Имхо, костыли — это добавлять функции подсчета контрольных сумм, размеров файлов и др. А такая защита наименее ресурсоемка и наиболее проста в реализации
Аналогичные штучки недохостера были у Уайвея, купленного РБК. Пришлось выбирать хостинг.
Сменил несколько штук. У одного php как mod, у другого — cgi. А потом нашел нормальный h4w.ru — там php-fastcgi и число этих процессов забито за мной постоянно — их всего пять.
А так-же вкусные плюшки, среди которых свой php.ini, /tmp на каждый сайт и многое другое.
Про то, что после переезда у меня пропали проблемы с тем, что мне дописывали iframe с вирусами я даже не говорю.
Сменил несколько штук. У одного php как mod, у другого — cgi. А потом нашел нормальный h4w.ru — там php-fastcgi и число этих процессов забито за мной постоянно — их всего пять.
А так-же вкусные плюшки, среди которых свой php.ini, /tmp на каждый сайт и многое другое.
Про то, что после переезда у меня пропали проблемы с тем, что мне дописывали iframe с вирусами я даже не говорю.
Судя по скриншоту PHP запускается через FastCGI.
Следовательно сессии нужно чистить ручками по крону. Так как при таком механизме самоотчистки сессий не происходит!
Следовательно сессии нужно чистить ручками по крону. Так как при таком механизме самоотчистки сессий не происходит!
crontab -e -u %USER%
где %USER% имя пользователя от которого запускается PHP
Этот скрипт запускается по крону каждые 30 минут и удаляет файлы сессий которые старее чем $(/usr/lib/php5/maxlifetime)
*/30 * * * * root [ -d /var/www/site.ru/sessions ] && find /var/www/site.ru/sessions -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm
/var/www/site.ru/sessions — директория прописанная в php.ini или скрипте. Место куда сохраняются сессии.
/usr/lib/php5/maxlifetime — скрипт который берет значение из php.ini о времени жизни сессии
где %USER% имя пользователя от которого запускается PHP
Этот скрипт запускается по крону каждые 30 минут и удаляет файлы сессий которые старее чем $(/usr/lib/php5/maxlifetime)
*/30 * * * * root [ -d /var/www/site.ru/sessions ] && find /var/www/site.ru/sessions -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm
/var/www/site.ru/sessions — директория прописанная в php.ini или скрипте. Место куда сохраняются сессии.
/usr/lib/php5/maxlifetime — скрипт который берет значение из php.ini о времени жизни сессии
Вопрос: а почему автор статьи сам не выбрал место хранения сессий и параметры устаревания?
Поправьте орфографические ошибки: «не до переноса, не в то время», «безапиляционно», «не упомянаю»
Хостеры, они, конечно, козлы и все такое =) но давайте не забывать о том, что предоставлять хостинг, это все же огромный труд. И наладить даже один сервер досточно трудно, ибо он «живой». Я лично, имея свои сервера и админя клиентские, не представляю как бы смог делать свой хостинг, слишком это геморойно.
Мне непонятна политика хостеров, зачем отказываться от обслуживания клиента, если можно ограничить используемые им ресурсы до прописанных в тарифном плане… Или не можно?
В рамках обычного виртуального хостинга (не jail, не VPS и т.п.) можно лишь обрубать скрипты по времени. Поставить, к примеру, что любой скрипт/запрос к базе выполняется не более одной секунды. Всё что больше отключать. Но это вызовет массу негодований со стороны пользователей.
Почему-то подумал про VPS…
Но и в других случаях наверно могут быть варианты (приоритеты зажравшимся в минимум выставлять, первое что на ум приходит...)
Но и в других случаях наверно могут быть варианты (приоритеты зажравшимся в минимум выставлять, первое что на ум приходит...)
Есть куча способов, вроде sa, выделения fastcgi-деток на каждого юзера, вплоть до собственных apache для каждого юзера у %well_known_hostername%.
Только оверхед от этого будет ого-го.
Только оверхед от этого будет ого-го.
похожая проблема была на 1GB, сессии хранили правда в базе, но обычный SMF форум при посещении 300-400 уников в день жаловались на нагрузки. Всё оказалось проще, UNIX хостинг у них оказался IIS сервером с установленным а-ля LAMP ПО… С тех пор плююсь в их сторону как слышу :)))
Получается WIMP :)
На самом деле PHP ужасно работает в виндовсе, особенно если много инклудов. Это связано с тормознутостью файловой системы.
На самом деле PHP ужасно работает в виндовсе, особенно если много инклудов. Это связано с тормознутостью файловой системы.
У нас можно выбрать любой тип сервера, а вот веб-мастер, не пытающийся посмотреть, на каком сервере -он сам- выбрал сайт, а потом решающий проблемы, достоин уважения. :)
Я знал, что родные сессии php — зло, но не знал, что настолько :)
Могу подкинуть ещё один косяк, если вдруг не знаете: в рамках одной сессии не могут работать одновременно 2 php-скрипта. Файл сессии блокируется.
Могу подкинуть ещё один косяк, если вдруг не знаете: в рамках одной сессии не могут работать одновременно 2 php-скрипта. Файл сессии блокируется.
Спасибо за полезный материал.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
С какой проблемой мы столкнулись на виртуальном хостинге