Похоже, шесть нод какого-то ботнета пытались осуществить SQL-иньекцию:

188.120.227.83 - - [22/Aug/2014:06:45:59 +0200] "GET /lor-opennet.2014?lim=all1111111111111%20UNION%20SELECT%20CHAR(45,120,49,45,81,45)%20--%20%20/* HTTP/1.1" 200 3525803 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; iebar; acc=none; FunWebProducts; .NET CLR 1.1.4322)"
188.120.227.83 - - [22/Aug/2014:06:46:12 +0200] "GET /lor-opennet.2014?lim=all1111111111111%20UNION%20SELECT%20CHAR(45,120,49,45,81,45),CHAR(45,120,50,45,81,45)%20--%20%20/* HTTP/1.1" 200 3525853 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; iebar; acc=; YPC 3.2.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; IEMB3; IEMB3; yplus 5.1.04b)"
188.120.227.83 - - [22/Aug/2014:06:46:24 +0200] "GET /lor-opennet.2014?lim=all1111111111111%20UNION%20SELECT%20CHAR(45,120,49,45,81,45),CHAR(45,120,50,45,81,45),CHAR(45,120,51,45,81,45)%20--%20%20/* HTTP/1.1" 200 3525903 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; elertz 2.4.179[128]; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)"
<...>
75.98.233.34 - - [22/Aug/2014:07:04:19 +0200] "GET /lor-opennet.2014?lim=all1111111111111%22%20UNION%20SELECT%20CHAR(45,120,49,45,81,45),CHAR(45,120,50,45,81,45),CHAR(45,120,51,45,81,45),CHAR(45,120,52,45,81,45),CHAR(45,120,53,45,81,45),CHAR(45,120,54,45,81,45),CHAR(45,120,55,45,81,45),CHAR(45,120,56,45,81,45),CHAR(45,120,57,45,81,45),CHAR(45,120,49,48,45,81,45),CHAR(45,120,49,49,45,81,45),CHAR(45,120,49,50,45,81,45),CHAR(45,120,49,51,45,81,45),CHAR(45,120,49,52,45,81,45),CHAR(45,120,49,53,45,81,45),CHAR(45,120,49,54,45,81,45),CHAR(45,120,49,55,45,81,45)%20--%20/*%20order%20by%20%22as%20/* HTTP/1.1" 200 2850816 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; iebar; acc=; YPC 3.2.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; IEMB3; IEMB3; yplus 5.1.04b)"
77.222.61.160 - - [22/Aug/2014:07:04:20 +0200] "GET /lor-opennet.2014?lim=all1111111111111%22%20UNION%20SELECT%20CHAR(45,120,49,45,81,45),CHAR(45,120,50,45,81,45),CHAR(45,120,51,45,81,45),CHAR(45,120,52,45,81,45),CHAR(45,120,53,45,81,45),CHAR(45,120,54,45,81,45),CHAR(45,120,55,45,81,45),CHAR(45,120,56,45,81,45),CHAR(45,120,57,45,81,45)%20--%20/*%20order%20by%20%22as%20/* HTTP/1.1" 200 380820 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; elertz 2.4.025; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0)"
87.242.64.24 - - [22/Aug/2014:07:04:22 +0200] "GET /lor-opennet.2014?lim=all1111111111111%27%20UNION%20SELECT%20CHAR(45,120,49,45,81,45),CHAR(45,120,50,45,81,45),CHAR(45,120,51,45,81,45),CHAR(45,120,52,45,81,45),CHAR(45,120,53,45,81,45),CHAR(45,120,54,45,81,45),CHAR(45,120,55,45,81,45),CHAR(45,120,56,45,81,45),CHAR(45,120,57,45,81,45),CHAR(45,120,49,48,45,81,45),CHAR(45,120,49,49,45,81,45),CHAR(45,120,49,50,45,81,45),CHAR(45,120,49,51,45,81,45),CHAR(45,120,49,52,45,81,45),CHAR(45,120,49,53,45,81,45),CHAR(45,120,49,54,45,81,45),CHAR(45,120,49,55,45,81,45),CHAR(45,120,49,56,45,81,45)%20--%20/*%20order%20by%20%27as%20/* HTTP/1.1" 200 1441384 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; iebar; acc=; YPC 3.2.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; IEMB3; IEMB3; yplus 5.1.04b)"

После этой строчки я добавил проблематичные адреса в список на блокировку (3 дня). Спасибо товарищу Ичинге за оперативное уведомление о недоступности сайта.

Да, недоступности. Мы упёрлись в однопоточность bottle.py. В связи с этим у меня вопрос: если запустить несколько несколько bottle.py параллельно, не будет ли гонок по доступу к ресурсам? То есть, нужна ли им какая-то синхронизация? Если да - прошу прикрутить, и я подредактирую скрипты запуска, чтобы стартовали несколько экземпляров bottle.py разом.

Да, вот собственно список заблокированных IP-адресов:

188.120.227.83
87.242.64.24
85.17.223.149 (пока больше не пытался постучаться)
77.222.61.160
75.98.233.34
69.28.199.140

> Вот так новости... И кому мы понадобились?

Это чистая автоматика. Скайнет только-только оживает. :) Если б атака была целенаправленной, то никто бы не пытался сделать SQL-иньекцию.

Вот так новости... И кому мы понадобились?

> делать демона, который раз в n-минут обновляет состояние (понятия не имею, как это делается)

Что значит "обновляет состояние"? Вообще, я представлял себе фетчер так: сливает инфу во временную папку по соседству с папкой эхи (типа, myecho.tmp), как закончил - делает rename(2) для каждого файла в папку эхи. Остаётся лишь вопрос генерации постоянных уникальных идентификаторов для сообщений. При таком варианте гонок быть не должно при условии отсутствия параллельно работающих фетчеров (решается блокировкой какого-нибудь файла вроде /tmp/ii-fetch-myecho).

> третий вариант, что называется, в лоб - многопоточность через gevent. просто поставь py-gevent, и я её могу хоть щас включить, раз время подошло.

С радостью. Но проблемы с гонками-то никуда не денутся... Впрочем, это ты рулишь сервисом, тебе и решать. :) Стоит, в общем.

> а вообще, простой в несколько секунд - это не страшно.

Там не просто "несколько секунд", там уже простучаться было нереально вообще. Собственно, Icinga и рапортовала именно о превышении таймаута подключения. А про дозвон на скорости в пару килобод - тогда альтернатив не было (ограничения на клиенте), а сейчас страдания исключительно по серверной вине. :)

> > делать демона, который раз в n-минут обновляет состояние (понятия не имею, как это делается)
>
> Что значит "обновляет состояние"?

А, всё, понял. Ну, можно в bottle.py мониторить какой-то каталог (с теми же локами фетчера, например), и как только в нём удаляется лок-файл какой-то эхи (то есть, фетчер закончил работу) - запускать обновление кеша.

поставил через gevent.... посморим, как жить будет...

мне не очень нравится эта идея с файлами. мне больше нравится, если можно как-то снаружи СООБЩИТЬ. в фенде были разные SendMesage для окон, которые можно было ловить :) чё есть в питоне - не знаю даже :)

да, lim=all рабоает медленновато для больших эх, и напрягать систему - запросто.

> В связи с этим у меня вопрос: если запустить несколько несколько bottle.py параллельно, не будет ли гонок по доступу к ресурсам?

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

1. делать демона, который раз в n-минут обновляет состояние (понятия не имею, как это делается)

2. запустать фетчер изнутри сервера (проблемный вариант)

3. как-то фетчером сообщать, что данные обновлены (я вообще изначально хотел сделать url типа /update, и чтобы его фетчер дёргал, но, наверное, есть и другие пути) [если вот тут как-то по-умному придумать - будет хорошо]


второй путь - это много ботлепуев. это делается через gunicorn. но тогда, опять же, надо смотреть, какие данные НЕ ПЕРЕДАЮТСЯ в рамках процесса. python мне тем и хорошо, что я могу, в отличие от php, легко делать глобалы и не дёргаться по пустякам. мне не нравится вариант "много ботлепуев" именно из-за того, что нельзя делать простое кэширование многих данных

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


а вообще, простой в несколько секунд - это не страшно. ты для сравнения irk38.tk помониторь, и посмотри, как он отдаётся... или представь дозвон до нода на 1200 без коррекции ошибок :) читать логи мониторинга - только себя пугать на каждый чих :)

можно, конечно, вообще отказаться от lim=all в пользу пажинации, но у меня ИДЕОЛОГИЯ! :) и своё представление о том, как это должно выглядеть. поэтому именно так, а не иначе :)

> Что значит "обновляет состояние"? Вообще, я представлял себе фетчер так: сливает инфу во временную папку по соседству с папкой эхи (типа, myecho.tmp), как закончил - делает rename(2) для каждого файла в папку эхи.

оно не требуется. потому что там две операции записи. одна - добавить новый файл. другая - добавить строчку в файл. всё, больше никаких операций не выполняется. возможно, там даже чисто теоретически не может возникнуть коллизий на современном оборудовании, потому что эта операция будет всегда глотаться мгновенно и целиком :)

> С радостью. Но проблемы с гонками-то никуда не денутся...

а они и сейчас есть, те же самые.

> Там не просто "несколько секунд", там уже простучаться было нереально вообще.

погоняем с gevent-ом, посмотрим...

> поставил через gevent.... посморим, как жить будет...

О, совсем другое дело! Небольшой стресс-тест пройден без проблем.

> А так - у Web-сервиса по определению есть интерфейс для посылки сообщений под названием HTTP. :)

та я знаю... но чё-то не хотелось :) пусть пока так поработает, а там посмотрим... у меня тут всяких разных вариантов навалом...