Yoda

Бекап в нашем случае был. Но он мог быть скомпроментирован давно, а отследить 200 000 строк кода движка - ну увольте нереально. Тут попался глупый хакер. Ну и при векторе атаке, в случае, когда база переводится на другой хост, и в бекапах она будет за три месяца назад - если будет. Не выход. Бекапы хорошо но бекапы бекапам рознь. И это первая большая ошибка большинства. Надеятся на то что где-то они там есть. Нет это не шантаж, возможно заказ, возможно "мимопроходил". И в данном случае я могу допустить, что скомпроментирован был непосредственно сервер хостера, а не движок. Но в целом это неважно. Если я расскажу просто так, то это прочитают и пройдут мимо, либо будут бездумно имплементировать советы от гугла, как вон кто-то выше написал простыню бездумных хауту. Даже не думая о том, что не все магазины живут на серверах, и даже у тех кто живет на Vps не всегда есть навыки внедрить 20% из этих нагугленных наскорую руку HOWTO. Хотя по факту есть как методология решения проблемы именно в этой ситуации, так и общая базовая методолология для исключения вероятности подобных происшествий. Я чуть позже изложу развернуто свои мысли по этому поводу.

Бекап не спасает. Если он не под подушкой. Устранить все дыры тоже в принципе не возможно. Но можно не допускать подобного. А заявление. На кого? На Васю из Тайланда? Который через три прокси пришёл. Хм... Бесполезно.

1 - база таки была убита. 2 - таки да. 3 - ну можно каждые пять минут это делать. Это не работа.

0 - не спасает, я вам могу потихому на свою базу переключить, неделя две... А данных у вас нету. Ну чуток стало медленее не заметили, а через какое то время. Все аля улю. 1 - не до конца понятно как оценить скилл компании. Скажем так, разработчиков, квалификации которых я доверяю, со всего форума, можно посчитать по пальцем одной руки. 2 - вопрос интересный, опять же с какой точки зрения, уязвимость, через которую чпокнули магазин, известная в узких кругах давно, но кроме этого там присутствовало вагон и маленькая тележка неявных проблем, ну и как рефакторить, то что под кубом, или то что продается от авторов, которые делают код без "архитетурных ошибок" и модули которых проверяет экспертная комиссия форума, по принципу "а слона и не заметил". В данном случае рефакторинг - не вариант. Очень дорого и специалистов днем с огнем не найти, но выход есть)))!

Вот с таким вопросом к нам пришел наш старый товарищ, несколько дней назад. У меня три вопроса: Что бы вы сделали на месте владельца магазина? Что сделать чтобы обезопасить себя от подобных "доброжелателей". И что делать в ситуации, когда подобные действия практически над любым магазином могут быть реализованы парой десятков авторов популярных дополнений?

Господа, все мы сталкиваемся с ситуацией, когда необходимо сформировать большой набор данных, сайтмап, yandex-market фид, и любая подобная задача, требует всегда очень много ресурсов. Большинство авторов таких дополнений слыхом не слыхивали ни про CLI-PHP, ни про возможность органично выделять ресурсы исключительно под собственные скрипты, не затрагивая общие настройки сервера. Про то, как делать CLI скрипты, я расскажу позднее, а сейчас поговорим про лимиты памяти, и почему нельзя пахабно относиться к ресурсам серверов клиентов. Приведу пример, который произошел буквально на днях. Обратились ко мне старые друзья с просьбой посмотреть, почему падает магазин. Да они добавили 30 региональных поддоменов, увеличилась нагрузка, но это не повод, чтобы 4гб памяти и 4гб SWAP забивались за 10 минут. Смотрим в настройки php_memory_limit 1gb. Система работает в связке nginx+php-fmp, и менеджер fpm резирвирует под каждый поток гиг памяти. Но нам то надо максимум 256МБ, для генерации любой страницы. Ок меняем настройки, немножко вносим тюнинг в конфиг php-fpm, все заработало, ресурсов хватает запас есть. Но из-за нехватки памяти отвалилась генерация YML, от одного известного автора. И Яндекс-маркет блочит магазин. Новый год, продажи стоят. Что делать? Писать автору, скорее всего бесполезно. Я думаю, что любой автор сказал - увеличивайте ресурсы сервера, у вас нехватка памяти, вы сами виноваты, у вас большой магазин. Я даже уверен, что 99% авторов дополнений так бы сделали. Но послушайте. Ну есть же возможность задавать настройки "на лету" прямо из выполняемого скрипта. И просто достаточно было добавить в код генерации яндекс-фида одну строку: ini_set("memory_limit",-1); И все.. Для всех скриптов, которые приходят на web-сервер у нас 256мб лимит, и наших 4 гигабайт хватает с головой обслужить весь входящий трафик и ботов. И без вопросов у нас генерится YML, которому мы разрешили использовать память безлимитно. Простейшая же задача как 2+2. Но продав более 1000 копий своего дополнения, автор даже не задумывался о подобных проблемах. Не будьте как автор! И еще. Не стесняйтесь вместо формирования каких то супермассивов, сразу писать все в файл. Вместо какого нить $thisoutYML->addItem($item), ведь очень просто делать $thisYmlSaveItemTofile($item). Ну и практически все фиды можно отдавать в .gz экономя место и время.

Извините, но банально учить программирование. в 99% случаев если вы задаете такие вопросы, у вас ничего не получится. Да и внедрение lazy, чтобы не потерять индексацию изображений в поисковиках - та еще задача.

Я бы на вашем месте даже не пытался вступать в полемику с людьми, которые говорят, что fastvps по дешману - это хороший хостер. Нервы не казённые.

Ну приблизительно тем же, чем Макдональдс лучше сети из трёх шаурмятен у Ашота.

Вот спасибо, я аж засмущался.

Это не потому что долго открывается, а потому что яндекс ресурсы заблокированы. Пинг из Украины в мск - такой же по скорости как и во франкфурт к тому же хецнеру. Но опять же в разрезе Украины, почему стоит брать европейские сервера. 1 - цена однозначно дикий плюс, при чем разница в цене от того же Ukraine - раз в 5. Но Ukraine, мало того что сдулся по качеству услуг, так еще и процессоры 2009 года в парке VPS серверов, уже в третий класс ходят камни. 2 - политика к простоям у буржуев к простоям все-таки более ответственная чем у наших, методология регламентных работ, и весь work-flow процесс на порядок отличается в качественную сторону, поэтому это тот случай, когда без сертифицированного мастера, нельзя лампу поменять - это в плюс. Что касается того, почему в Европе дешевле. Во первых возврат VAT. Вы берете любой дедик в хецнере, на 19% дешевле, чем он стоит у них на сайте разбиваете его на виртуальные узлы - и у вас готовая VPS-нода, при цене 50 евро за 8 ядерный камень, получаем 16 виртуальных ядер, по 5 долларов, пусть. Продаем по 500 рублей за ядро - уже получается 8000 рублей. Двойной куш. На голом месте и это просто если в лоб арендовать в том же хецнере, физическое железо. Не одним хецнером мир дышит, они не дают скидок в целом, но есть масса провайдеров, которых можно продавить по цене, да и у них же нагрести на аукционе готового железа как грязи по дешману. А если брать бизнес таких "хваленных контор" типа фаствпс, рувдс ну это на грани аферизма. Если тот же ukraine.com.ua эксплуатирует железо, которое пентиум в лицо видело, и это норма, у буржуев есть масса контор, которые парк серверов обновляют раз в 2-3 года. И если хорошо поискать, то очень приличные сервера, можно найти по 200-300 долларов за blade-unit + 100 долларов диск. И у вас с учетом трехлетней аммортизации и аренды места в стойке, ну пусть за 20 долларов, цена узла под 16-24 ядра становиться уже всего 30 долларов. Поэтому можно продавать все эти ядра дешевле грибов. Т.е. хостинг типа территориально в рф. А вот весь этот парк серверов, он территорию ЕС даже не покидал, там купили, сюда курьером привезли, инженеры колокейшна диски и шнурки воткнули, подсеть прописали - все.. Готов хостинг. Но на практике что фаст что рувдс - это черепаший хостинг, и лучше с ними не связываться.

А сколько было, сколько стало ?

Вы меня, простите, но тут есть масса нюансов. Во первых 4x quemu - это может быть очень много, а может быть ни о чем. Все зависит от физического типа процессора. Во вторых необходимо внимательно посмотреть логи и отследить тип страниц, по которым эти самые боты ходят. В третьих, по возможности исключить или заменить "талантливые" модули, которые могут создавать на голом месте дикую нагрузку В четвертых, отказаться от генерации любых фидов-выгрузок через web-интерфейс. Ну а дальше теми или иными средствами исключать все бутылочные горлышки. К сожалению 100к товаров - это много. И просто взять и поставить волшебную таблетку на подобный проект не выйдет.

Нет не подгорает. Это не технический вопрос, а холивар.

Да кстати, если вам не нужен рф-айпи, то DO втопку. https://www.hetzner.com/cloud-ru 3 евры - ядро, 2 гига/20 гиг – это практически бесплатно. А ну еще -19%VAT.

Вы меня простите, я сарказм включу, но ваш вопрос звучит так. Приходите вы к проктологу, и говорите: доктор, у меня зубы болят, поставьте пломбу пожалуйста. Человек пришел с банальной проблемой, ему просто необходимо рабочее окружение для развертывания web-ресурса. Там нет ни слова о каких либо нестандартных реализациях. Мой опыт и специализация, позволяют мне утверждать, что ISP достаточно для его задач выше крыше. А также то, что подобное решение, заведомо избавляет от любых прямых или косвенных зависимостей бизнеса, от лишнего звена в виде системных администраторов, коих вменяемых днем с огнем не найдешь. Вы же рассказываете про какие то кастомные решения с транспортом почты. Вобщем это как теплое с мягким путать.

Пожалуйста, уточните, что лишнего для полноценной работы магазина в этих терминах? И есть ли в этом списке хотя бы один не критичный пункт. Также к вашему сведению, все задачи из этого списка пятая панель решает в один клик. И еще, уточните, что такого критичного не может сделать панель. К тому же, я выше писал, что панель закрывает 99% рутинных серверных манипуляций. Да даже если и не полный ноль, быть подвязанным под какого-то лохматого специалиста из-за 4 евро в месяц. Ну реально надо быть волшебным на всю голову.

Установка ISP, в случае, если человек умеет пользоваться putty - утилитарна как 2+2. Есть определенные моменты, которые могут потребовать некоторых услуг специалистов, но они не сравнимы с общими настройками, и самое главное с дальнейшим саппортом. Что касается вашего личного опыта. Давайте рассмотрим простую ситуацию: У вас 5 сайтов, вам необходимо под них иметь три разных версии php, автообновляемые let's encrypt сертификаты, 40 почтовых ящиков, регулярные бекапы, по 10 cron заданий, пару десятков ftp-пользователей, управление доменными зонами прямо на сервере ну и например автоматическую генерацию и выгрузку в dns зону dkim-записей. Если подобный огород будет поднимать наемный linux-администратор, и у вас нет навыков писать чуть больше чем apt-get, это 10-15 часов работы по 20-30 долларов минимум за настройку, и потом за каждый любой чих. Так что 40 евро и нормальный визуальный интерфейс для всей рутины, или же платить и каяться.

Я вам, как человек измученный нарзаном, немножко вангану. После того как вы найдете исполнителя, который вам это сделает, вы столкнетесь с еще кучей мелких и крупных проблем. За которые вам придется платить, платить и еще раз платить. Вместо этого, поставьте ISP-панель, заплатите 40 евро за год и забудьте о 99% серверных манипуляций. https://doc.ispsystem.ru/index.php/Установка_и_обновление_ISPmanager

Возможно вам проще будет понять это, поставив вопрос не с точки зрения "ставим запреты", а от противного. А какие собственно боты вам нужны? У вас есть трафик с BING, или Mail.ru. Ну и дальше просится логичный ответ, что надо разрешать посещения только тем ботам, которые нужны именно вам, и по возможности блокировать всех остальных.

У вас может быть любое количество причин: от очень большого количества дескрипторов сессий, до кривых рук системных администраторов. Также у вас фактически не 2000 товаров а для поискового бота 2000*100 = 200 000, что само по себе достаточно много. К тому же "мы добавили ядра" - а вы систему научили эти ядра правильно использовать? Еще. Если посмотреть на ваш график, то явно видно, что у вас существуют некие циклические повторяющиеся процессы, которые скорее всего вызваны какой нибудь генерацией тяжелых скриптов планировщиком. И скорее всего некорректно реализованным планировщиком. И напоследок, кроме Яндекса есть еще масса "полезных ботов". Поэтому ваша ситуация это совершенно не проблема, вам достаточно проанализировать паттерн трафика, отследить что создает пики, устранить причину, убрав узкие места и распределив по возможности нагрузку и закрыть все возможные узкие места, создав 60-70% запаса ресурсов от пика, для того чтобы подобная ситуация не повторилась. Если специалисты по свопам не помогут, стукните в начале следующей недели, возможно будет время посмотреть вашу беду.

US ip - да, нужен. http2 - не может уменьшить время загрузки де факто, так как он не об этом, а про доставку контента клиенту. Если честно ни разу не втыкал http2 на голом апач - не подскажу. В ситуации с nginx, есть определенные нюансы, связанные с версией установленной в системе openssl. Ip, чем ближе локально к пользователям, тем лучше. Что касается apache. Мое мнение - он должен маздай как класс. И даже если вы используете его, ставьте на фронт nginx, за счет этого намного проще решать целый ворох проблем, в том числе и http2. Ну а в целом, что касается уменьшения время ответа сервера. Это же сродни искусству.

Можно, но как показывает практика, всегда лучше работать в окружении, приближенном к максимально боевым условиям. Я бы рекомендовал поставить какую нить vestucp, если жалко 4 евро в месяц на isp панель.

Вопроса два. 1. Чем амазон отличается от любого другого поставщика вычислительной площадки (ну кроме того, что это облако). 2. Openserver зачем? LAMP LEMP не подходит?

jpegoptim не умеет сжимать! Это программное решение создано для выкидывания мусора из файлов. За счет этого получается уменьшить вес файла. На маленьких (порядка 1К) файлах вы можете увидеть результат существенный, т. к. мусор в виде дополнительной информации (какой фотокамерой снято, когда, каким редактором обработано и т.д. и т. п.) занимает объем, сопоставимый с полезной информацией. На средних и больших файлах выигрыш получается смешной в единицы или доли процентов. Чем больше файл, то тем меньше выигрыш. Компрессор умеет выкидывать мусор (также как jpegoptim) без стороннего софта и без включения сжатия (mozjpeg). Это в нем по умолчанию включено. Я не знаю с какой целью вы вводите людей в заблуждение, сознательно или нет! Надеюсь что вы это делаете по неграмотности, а не от неуемной жажды наживы на несведущих пользователях, но, если вы обратитесь к документации Jpegoptim, там можно обнаружить вот такой текст: Подскажите, в каком месте здесь нет сжатия? По поводу WEBP. К сожалению, у вас нет своего магазина, вы не знаете что такое цена клика, бюджет на рекламы, зарплаты сотрудников, зато вы знаете как удачно порождать мифы и продавать воздух. Так вот.... Не миф, а ФАКТ 1. Использование эскпериментальной необкатанной и не поддерживаемой большинством бразуеров и дополнений технологий и попытка навязать оную, является моральным преступлением по отношению к владельцам магазинов, да и всем тем кто ведется на ваше СУПЕР пупер рекламное сжатие. ФАКТ 2. Вы верно сказали, что mozilla - добавит поддержку в течении двух месяцев, а что там Safari? А сколько у людей трафика с apple устройств может быть? Опять я надеюсь это вы по незнанию, а не ради наживы а там и трава не расти.