REJIK

Здравсвуйте.
Была поставлена задача по блокировке баннеров и порнухи в моей организации. Погуглив наткнулся на rejik.ru. Попробовал и поставил на ubuntu server 7.10 связку squid+rejik, правда режик компилировался с ошибками, но заработал. Многие популярные сайты типа gismeteo.ru и mail.ru подчищались от рекламы нормально. Но по сайтам челябинской области баннеров в базе небыло. Решил прогнать топ 15 сайтов каждого пользователя интернета в организации. Но встал вопрос о правильности ввода правил в общую базу. И так, по порядку:
Возьмем сайт http://www.chelreal.ru/. На нем все картинки с расширением gif и различными комбинациями названия файлов картинок имеют слово "banner" - везде где есть такая комбинация букв в названия файла является банером. Например 58451_banner2.gif, bannerok3.gif, 58422_BANNER.gif. Как мне добавить в базу это правило? Или в banner.urls, что-то типа http://www.chelreal.ru/files/images/*banner.gif , т.е. все остальные символы я заменил "*". Будет так работать правило правильно? И вообще можно использовать символ "*" или "?" для замены символов в форме добавления url правил? Формы принимаются нормально с этими знаками, но как они потом обрабатываются - мне не понятно. В списках листов таких знаков не наблюдал.
На многих сайтах расположение баннеров в структурах папок и названиях просматриваюстя закономерности, которые можно описать регулярными выражениями или вводить в базу по 10-15 прямых линков на банеры, что не очень удобно.

И второй вопрос. Мне нужна связка squid+havp+rejik+(globax спутникового интернета). Конфиг squid 2.6 такой:

cache_peer 127.0.0.1 parent 8888 0 no-query default
acl ftp proto FTP
acl havp proto HTTP
acl al src 0.0.0.0/0.0.0.0
always_direct allow ftp
always_direct deny al
never_direct allow havp
url_rewrite_program /usr/local/rejik3/redirector /usr/local/rejik3/redirector.conf

Из конфига видно, что все запросы редиректятся на порт havp 127.0.0.1:8888, а сам havp потом редиректится на порт ускорителя глобакс 127.0.0.1. Т.к. havp не поддерживает ftp, то ftp протокол пришлось пустить напрямую в интернет описав протоколы в 2,3 стороках и разделив их в 5,6,7 строках конфига. Тут все ясно. в 8-ой строке указываю squid пользоватся внешним редиректором. Но после ввода 8-ой строки станицы начинают тормозить на баннерах. т.е. не могут подгрузиться, но и страница открывается не польностью, если банеры находятся в начале страницы.
Стоит apache на внутреннем интерфейсе и 1х1.gif открывается с клиентских компьютеров нормально. Если заремить первые 7 строк, то squid хоти в инет напрямую, но рекламма уже заменяется 1-о пиксельным gif нормально и страницы догружаются до конца. Так вопрос тем, кто настраивал такую комбинацию модулей. Как мне прописать в squid.conf, чтобы и havp вирусы лечил и rejik банеры резал?
На форумах отписываюсь с прозьбами помочь очень редко, т.к. на форумах полно решений большинства проблем. Но здесь встал в тупик.

Slayeruga писал(а):З Как мне добавить в базу это правило? Или в banner.urls, что-то типа http://www.chelreal.ru/files/images/*banner.gif , т.е. все остальные символы я заменил "*". Будет так работать правило правильно?

В banner.urls звездочка работать не будет.
Для этого есть pcre, регулярные выражения perl, на нем это правило будет выглядеть так:
http\:\/\/www\.chelreal\.ru\/files\/images\/.+banner\.gif

Slayeruga писал(а): И второй вопрос. Мне нужна связка squid+havp+rejik+(globax спутникового интернета). Конфиг squid 2.6 такой:

cache_peer 127.0.0.1 parent 8888 0 no-query default
acl ftp proto FTP
acl havp proto HTTP
acl al src 0.0.0.0/0.0.0.0
always_direct allow ftp
always_direct deny al
never_direct allow havp
url_rewrite_program /usr/local/rejik3/redirector /usr/local/rejik3/redirector.conf

Из конфига видно, что все запросы редиректятся на порт havp 127.0.0.1:8888, а сам havp потом редиректится на порт ускорителя глобакс 127.0.0.1. Т.к. havp не поддерживает ftp, то ftp протокол пришлось пустить напрямую в интернет описав протоколы в 2,3 стороках и разделив их в 5,6,7 строках конфига. Тут все ясно. в 8-ой строке указываю squid пользоватся внешним редиректором. Но после ввода 8-ой строки станицы начинают тормозить на баннерах. т.е. не могут подгрузиться, но и страница открывается не польностью, если банеры находятся в начале страницы.
Стоит apache на внутреннем интерфейсе и 1х1.gif открывается с клиентских компьютеров нормально. Если заремить первые 7 строк, то squid хоти в инет напрямую, но рекламма уже заменяется 1-о пиксельным gif нормально и страницы догружаются до конца. Так вопрос тем, кто настраивал такую комбинацию модулей. Как мне прописать в squid.conf, чтобы и havp вирусы лечил и rejik банеры резал?
На форумах отписываюсь с прозьбами помочь очень редко, т.к. на форумах полно решений большинства проблем. Но здесь встал в тупик.

В конфиге режика, урл замены указывает на 127.0.0.1 или на внутренний ip веб сервера?
Скопируйте урл из конфига и вставьте в адресную строку браузера (у клиента, с настроенной проксей), быстро загрузится?

[/quote] В конфиге режика, урл замены указывает на 127.0.0.1 или на внутренний ip веб сервера?
Скопируйте урл из конфига и вставьте в адресную строку браузера (у клиента, с настроенной проксей), быстро загрузится?[/quote]

У клиентов страницы с банером замены и porno.htm грузятся в миг.

Перед экспериментами обнуляю кэш браузера клиента и кэш squid.
пробывал и 127.0.0.1 и внутренний вебсервера 192.168.40.4, только с вариантом localhost страницы быстро догружаются не тормозя, а на местах банеров стоят надписи "Not Found The requested URL /ban/1x1.gif was not found on this server. Apache/1.3.33 Server at 127.0.0.1 Port 80", а с вариантом 192.168.40.4 в конфиге режика страницы стопорятся на банерах и не догружаются.

вот кусог лога squid cо 127.0.0.1 в конфиге режика из которого видно что адрес клиента squid 192.168.40.33, с которой я пробую просматривать страницы с порезаными банерами. Тестирую на overclockers.ru:

"214381046.402 1052 192.168.40.33 TCP_SWAPFAIL_MISS/200 1389 GET http://overclockers.ru/images/rss2.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381046.403 1043 192.168.40.33 TCP_SWAPFAIL_MISS/200 468 GET http://overclockers.ru/images/p_right.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381046.404 1043 192.168.40.33 TCP_SWAPFAIL_MISS/200 471 GET http://overclockers.ru/images/p_up_l.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381046.406 987 192.168.40.33 TCP_SWAPFAIL_MISS/200 471 GET http://overclockers.ru/images/p_down.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381046.417 1375 192.168.40.33 TCP_MISS/200 45292 GET http://www.overclockers.ru/images/x-m_main_0624.jpg - DEFAULT_PARENT/127.0.0.1 image/jpeg
1214381046.430 1144 192.168.40.33 TCP_MISS/200 8469 GET http://v6.overclockers.ru/www/delivery/javascript.php? - DEFAULT_PARENT/127.0.0.1 application/x-javascript
1214381046.447 207 192.168.40.47 TCP_MISS/200 5081 GET http://architektonika.ru/engine/ajax/dle_ajax.js - DEFAULT_PARENT/127.0.0.1 application/x-javascript
1214381046.478 285 192.168.40.33 TCP_SWAPFAIL_MISS/200 472 GET http://overclockers.ru/images/p_close.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381046.729 249 192.168.40.47 TCP_MISS/200 6983 GET http://architektonika.ru/engine/ajax/js_edit.js - DEFAULT_PARENT/127.0.0.1 application/x-javascript
1214381046.744 339 192.168.40.33 TCP_SWAPFAIL_MISS/200 454 GET http://overclockers.ru/images/pw_bg_du_m.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381046.744 339 192.168.40.33 TCP_SWAPFAIL_MISS/200 451 GET http://overclockers.ru/images/m2.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381046.745 338 192.168.40.33 TCP_SWAPFAIL_MISS/200 465 GET http://overclockers.ru/images/pw_bg_mid_r.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381046.745 340 192.168.40.33 TCP_SWAPFAIL_MISS/200 463 GET http://overclockers.ru/images/pw_bg_du_r.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381046.796 378 192.168.40.33 TCP_SWAPFAIL_MISS/200 454 GET http://overclockers.ru/images/pw_bg_dn_m.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381046.796 365 192.168.40.33 TCP_SWAPFAIL_MISS/200 465 GET http://overclockers.ru/images/pw_bg_dn_r.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381046.838 0 192.168.40.47 TCP_NEGATIVE_HIT/404 592 GET http://an.yandex.ru/resource/context.js? - NONE/- text/html
1214381046.850 371 192.168.40.33 TCP_SWAPFAIL_MISS/200 647 GET http://overclockers.ru/images/pw_grad_up_l.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381047.057 312 192.168.40.33 TCP_SWAPFAIL_MISS/200 465 GET http://overclockers.ru/images/pw_bg_mid_l.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381047.057 261 192.168.40.33 TCP_SWAPFAIL_MISS/200 463 GET http://overclockers.ru/images/pw_bg_dn_l.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381047.059 315 192.168.40.33 TCP_SWAPFAIL_MISS/200 626 GET http://overclockers.ru/images/pw_grad_up_mid.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381047.059 314 192.168.40.33 TCP_SWAPFAIL_MISS/200 645 GET http://overclockers.ru/images/pw_grad_up_r.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381047.060 314 192.168.40.33 TCP_SWAPFAIL_MISS/200 573 GET http://overclockers.ru/images/m_new.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381047.108 313 192.168.40.33 TCP_SWAPFAIL_MISS/200 573 GET http://overclockers.ru/images/m_old.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381047.113 234 192.168.40.47 TCP_MISS/200 1795 GET http://architektonika.ru/favicon.ico - DEFAULT_PARENT/127.0.0.1 text/plain
1214381047.323 46 192.168.40.33 TCP_NEGATIVE_HIT/404 592 GET http://ad.adriver.ru/cgi-bin/erle.cgi? - NONE/- text/html
1214381047.386 482 192.168.40.33 TCP_SWAPFAIL_MISS/200 1183 GET http://v6.overclockers.ru/www/images/1x1.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381047.497 439 192.168.40.33 TCP_MISS/200 510 GET http://v6.overclockers.ru/www/delivery/log.php? - DEFAULT_PARENT/127.0.0.1 image/gif
1214381047.498 0 192.168.40.33 TCP_NEGATIVE_HIT/404 592 GET http://adv.hardwarez.ru/cgi-bin/iframe? - NONE/- text/html
1214381047.719 508 192.168.40.33 TCP_SWAPFAIL_MISS/200 471 GET http://overclockers.ru/images/p_up.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381047.719 470 192.168.40.33 TCP_SWAPFAIL_MISS/200 471 GET http://overclockers.ru/images/p_down_l.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381047.719 478 192.168.40.33 TCP_SWAPFAIL_MISS/200 465 GET http://overclockers.ru/images/p_close_l.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381047.719 332 192.168.40.33 TCP_SWAPFAIL_MISS/200 529 GET http://overclockers.ru/images/hl_lt.gif - DEFAULT_PARENT/127.0.0.1 image/gif
1214381047.719 386 192.168.40.33 TCP_SWAPFAIL_MISS/200 471 GET http://overclockers.ru/images/p_left.gif - DEFAULT_PARENT/127.0.0.1 image/gif

из лога видно что банеры с http://adv.hardwarez.ru/ - банерной сети не грузятся TCP_NEGATIVE_HIT/404.

в логе squid при посещении overclockers.ru , но с 192.168.40.4 т.е. внутренним интерфейсом вебсервера в конфиге режика запросов на adv.hardwarez.ru просто нет. И страница стоит недогруженая. Даже в логах режика не отображается статистика по блокировке банеров.

Думаю проблема вся в cache_peer в конфиге squid. Может стоит копнуть в сторону cache_peer_access ?

ведь господин "asket" настраивал связку havp+clamav+squid+rejik, интересно как он это все подружил вместе

Урл замены не должен быть 127.0.0.1

Покажите конфиг режика.

Сделайте на сервере wget -S урл_замены напрямую и через прокси (настраивается через wgetrc) и покажите, что пишет.

Если есть возможность, сделайте wget -S урл_замены и wget -S внешний_урл_с _баннером с клиентской машины и покажите, что пишет.

листинг файла redirector.conf:
error_log /usr/local/rejik3/redirector.err
change_log /usr/local/rejik3/redirector.log
make-cache /usr/local/rejik3/make-cache
work_ip 192.168.40.0/255.255.252.0

<BANNER>
ban_dir /usr/local/rejik3/dbl/banner.urls
url http://192.168.40.4/ban/1x1.gif
work_ip 192.168.40.0/255.255.252.0
#log off

<PORNO>
ban_dir /usr/local/rejik3/dbl/porno.urls
url http://192.168.40.4/ban/porno.html
work_ip 192.168.40.0/255.255.252.0

через 192.168.40.4:8080 у меня работают все клиенты сети как windows и linux без проблем.

прописал в /etc/wgetrc на клиенской машине:
http_proxy = http://192.168.40.4:8080/
ftp_proxy = http://192.168.40.4:8080/
use_proxy = on

url_замены http://192.168.40.4/ban/1x1.gif
внешний_url_c_банером http://064.ru/img/dn.gif

wget -S http://192.168.40.4/ban/1x1.gif с клиентской машины через прокси пишет:
root@13-pc033:~# wget -S http://192.168.40.4/ban/1x1.gif
--09:33:20-- http://192.168.40.4/ban/1x1.gif
=> `1x1.gif'
Устанавливается соединение с 192.168.40.4:8080... соединились.
Запрос Proxy послан, ожидание ответа...
HTTP/1.0 403 Forbidden
Content-Type: text/html
Age: 1
Content-Length: 2524
X-Cache: HIT from upp_proxy
X-Cache-Lookup: HIT from upp_proxy:8080
Via: 1.0 upp_proxy:8080 (squid/2.6.STABLE14)
Proxy-Connection: close
09:33:20 ОШИБКА 403: Forbidden.


wget -S http://064.ru/img/dn.gif с клиентской машины через прокси пишет:
root@13-pc033:~# wget -S http://064.ru/img/dn.gif
--09:35:06-- http://064.ru/img/dn.gif
=> `dn.gif'
Устанавливается соединение с 192.168.40.4:8080... соединились.
Запрос Proxy послан, ожидание ответа...
HTTP/1.0 403 Forbidden
Content-Type: text/html
Age: 20
Content-Length: 2524
X-Cache: HIT from upp_proxy
X-Cache-Lookup: HIT from upp_proxy:8080
Via: 1.0 upp_proxy:8080 (squid/2.6.STABLE14)
Proxy-Connection: close
09:35:06 ОШИБКА 403: Forbidden.


wget -S http://192.168.40.4/ban/1x1.gif на клиенской машине на прямую пишет:
root@13-pc033:~# wget -S http://192.168.40.4/ban/1x1.gif
--09:47:15-- http://192.168.40.4/ban/1x1.gif
=> `1x1.gif'
Устанавливается соединение с 192.168.40.4:80... соединились.
Запрос HTTP послан, ожидание ответа...
HTTP/1.1 200 OK
Date: Thu, 26 Jun 2008 03:47:23 GMT
Server: Apache/2.2.4 (Ubuntu)
Last-Modified: Wed, 02 Nov 2005 09:19:05 GMT
ETag: "1dd30f-2b-90537440"
Accept-Ranges: bytes
Content-Length: 43
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/gif
Длина: 43 [image/gif]

100%[====================================>] 43 --.--K/s

09:47:15 (1.90 MB/s) - `1x1.gif' сохранён [43/43]

Теперь те же команды, выполненные на самой прокси.

вывод команды wget -S http://192.168.40.4/ban/1x1.gif на прокси через прокси сервер:
root@nproxy:~# wget -S http://192.168.40.4/ban/1x1.gif
--10:06:15-- http://192.168.40.4/ban/1x1.gif
=> `1x1.gif'
Connecting to 192.168.40.4:8080... connected.
Proxy request sent, awaiting response...
HTTP/1.0 403 Forbidden
Content-Type: text/html
Age: 55
Content-Length: 2524
X-Cache: HIT from upp_proxy
X-Cache-Lookup: HIT from upp_proxy:8080
Via: 1.0 upp_proxy:8080 (squid/2.6.STABLE14)
Proxy-Connection: close
10:06:15 ERROR 403: Forbidden.

вывод команды wget -S http://192.168.40.4/ban/1x1.gif на прокси напрямую:
root@nproxy:~# wget -S http://192.168.40.4/ban/1x1.gif
--10:07:59-- http://192.168.40.4/ban/1x1.gif
=> `1x1.gif'
Connecting to 192.168.40.4:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Thu, 26 Jun 2008 04:07:59 GMT
Server: Apache/2.2.4 (Ubuntu)
Last-Modified: Wed, 02 Nov 2005 09:19:05 GMT
ETag: "1dd30f-2b-90537440"
Accept-Ranges: bytes
Content-Length: 43
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/gif
Length: 43 [image/gif]

100%[====================================>] 43 --.--K/s

10:07:59 (1.34 MB/s) - `1x1.gif' saved [43/43]

Т.е. через прокси мы пробывали все эти команды в связке squid+havp+rejik, а теперь попробуем команду wget -S http://064.ru/img/dn.gif на клиенской машине через прокси, но уже в связке squid+rejik:
root@13-pc033:~# wget -S http://064.ru/img/dn.gif
--10:13:35-- http://064.ru/img/dn.gif
=> `dn.gif'
Устанавливается соединение с 192.168.40.4:8080... соединились.
Запрос Proxy послан, ожидание ответа...
HTTP/1.0 200 OK
Date: Thu, 26 Jun 2008 04:13:22 GMT
Server: Apache/2.2.4 (Ubuntu)
Last-Modified: Wed, 02 Nov 2005 09:19:05 GMT
ETag: "1dd30f-2b-90537440"
Accept-Ranges: bytes
Content-Length: 43
Content-Type: image/gif
Age: 20
X-Cache: HIT from upp_proxy
X-Cache-Lookup: HIT from upp_proxy:8080
Via: 1.0 upp_proxy:8080 (squid/2.6.STABLE14)
Proxy-Connection: close
Длина: 43 [image/gif]

100%[====================================>] 43 --.--K/s

10:13:35 (2.06 MB/s) - `dn.gif' сохранён [43/43]

Из этого следует, что в связке squid+rejik замена банера на наш подставной размером 43 байта проходит успешно. Но в связке squid+havp+rejik банерорезка не работает.

и еще один вопрос, если можно .
Вчера и сегодня пытался получить список проверочных урлов, чтобы повысить рейтинг до 1000, но на mail они не приходят.

С чем это может быть связано? раньше списки приходили буквально через 10-15сек, а сейчас тишина..

сейчас уже проверочный урлы на почту приходят.. не знаю в чем была проблема...

Есть просьба удалить все мои новые правила в общей базе банеров за 24 и 25 июня. Там много косячных правил со знаком "*", которые просто не отрабатывают. Ник в базе у меня такойже "Slayeruga"

Slayeruga писал(а): wget -S http://192.168.40.4/ban/1x1.gif с клиентской машины через прокси пишет:
root@13-pc033:~# wget -S http://192.168.40.4/ban/1x1.gif
--09:33:20-- http://192.168.40.4/ban/1x1.gif
=> `1x1.gif'
Устанавливается соединение с 192.168.40.4:8080... соединились.
Запрос Proxy послан, ожидание ответа...
HTTP/1.0 403 Forbidden
Content-Type: text/html
Age: 1
Content-Length: 2524
X-Cache: HIT from upp_proxy
X-Cache-Lookup: HIT from upp_proxy:8080
Via: 1.0 upp_proxy:8080 (squid/2.6.STABLE14)
Proxy-Connection: close
09:33:20 ОШИБКА 403: Forbidden.

Основная проблема в недоступности урла замены через прокси.
Есть два решения:
1. Пустить клиентов за урлом замены напрямую, а не через прокси, например, прописав этот урл, хост или подсетку в список исключений, при использовании прокси.

2. Сделать урл замены доступным через прокси.
Отключите фаирвол, проанализируйте вывод tcpdump, пропишите в проксе исключения для урла, хоста или локальной подсетки на предмет хождения через havp, отследите по логам, где стопорится загрузка.

Slayeruga писал(а):и еще один вопрос, если можно .
Вчера и сегодня пытался получить список проверочных урлов, чтобы повысить рейтинг до 1000, но на mail они не приходят.

С чем это может быть связано? раньше списки приходили буквально через 10-15сек, а сейчас тишина..

В спам фильтре на mail.ru блокируются письма, содержащие ссылки на порно, часто блокируются листы для проверки порно от режика.

Slayeruga писал(а): Есть просьба удалить все мои новые правила в общей базе банеров за 24 и 25 июня. Там много косячных правил со знаком "*", которые просто не отрабатывают. Ник в базе у меня такойже "Slayeruga"

Отправил Вам по почте лог добавления Вами правил со звездочками.
Добавьте их в DBL, в туже сексию, куда и раньше,. с ответом "НЕТ".

Получил почту с кривыми правилами. Добавил их в секцию баренов с ответом нет.. Буду правила прописывать заного.

По вашему совету пошел по первому пути, как самому простому.
Все решилось добавлением 2х строк в squid.conf:
ache_peer 127.0.0.1 parent 8888 0 no-query default
acl ftp proto FTP
acl http proto HTTP
acl local dstdomain nproxy
acl surnet dstdomain forum.surnet.ru
acl al src 0.0.0.0/0.0.0.0
always_direct allow ftp
always_direct allow local
always_direct allow surnet

В этом конфиге напрямую без havp и globax топает протокол ftp, бесплатный ресурс УралСвязьИнформа и локальный Web сервер 192.168.40.4, чтобы банер замены грузился с напрямую с локального сервера. Но по IP банер замены был доступен не всегда. Так и не понял зависимсоть его доступности. Пришлость прописать в /etc/hosts:
192.168.40.4 nproxy

Соответсвенно в redirector.conf пришлось заменить url http://192,168,40,4/ban/1x1.gif
на url http://nproxy/ban/1x1.gif и все завелось с полпинка.. т.е. связка squid+havp+rejik+globax заработала без проблем..

Спасибо вам за помощь!!!!!

Теперь хочу набить рейтинг 1000 и вписывать в общую базу правила на основе регулярных выражений. Ведь тяжно прописывать прямые урлы до 5 банеров, в пути которых наблюдаются закономерности. Проще регулярными выражениями вписать их одним правилом. По ходу приходится тестировать это правило сначала на сайте, а потом уже добавлять в общую базу.

По ходу дела возник вопрос по проверяемым урлам банеров. Допустим, правило airbase.uka.ru/top , а проверочный урл к нему http://www.airwar.ru/. Ну, захожу я на сайт http://www.airwar.ru/. Видно что половина банеров порезана но правило airbase.uka.ru/top не отрабатывает, что видно из redirector.conf.
Как поступать с такими кривыми правилами? Ставить галочку "удалить" или "нет"? Ведь проверочный урл должен указывать прямую ссылку на рекламу.
Тут таких правил полно. Ну, хорошо, что они не отрабатывают, а если вырезают лишний контент?

Slayeruga писал(а): По ходу дела возник вопрос по проверяемым урлам банеров. Допустим, правило airbase.uka.ru/top , а проверочный урл к нему http://www.airwar.ru/. Ну, захожу я на сайт http://www.airwar.ru/. Видно что половина банеров порезана но правило airbase.uka.ru/top не отрабатывает, что видно из redirector.conf.
Как поступать с такими кривыми правилами? Ставить галочку "удалить" или "нет"? Ведь проверочный урл должен указывать прямую ссылку на рекламу.
Тут таких правил полно. Ну, хорошо, что они не отрабатывают, а если вырезают лишний контент?

Если по проверочному урлу банеры, подпадающие под правило не находятся, то лучше сначала поискать его в гугле:
Расширенный поиск -> Найти страницы, ссылающиеся на эту.
Например, ищем airbase.uka.ru/top и первым пунктом среди найденного видим: http://rus.air.ru/airplanes/Yak-18T.htm

Переходим туда, внизу страницы поломанный счетчик с http://airbase.uka.ru/top/?img=11

Вывод: хотя счетчик и поломан, но на некоторых сайтах он ещё прописан, имеет смысл блокировать.

Здравсвуйте. Вопрос опять по банерам.

Есть банеры, которые ссылаются на тотже сайт, где и распложены. Т.е. это попадает под определение банеров? Понятно что анимированые gif и sfw, ссылающиеся на другие порталы 100% нужно резать.
Например сайт http://chelyabinsk.mvideo.ru/ , на нем есть флеш анимированый, но рекламируют сами себя. Стоит их вырезать или нет? Такие сайты частенько попадаются.

Slayeruga писал(а):Здравсвуйте. Вопрос опять по банерам.

Есть банеры, которые ссылаются на тотже сайт, где и распложены. Т.е. это попадает под определение банеров? Понятно что анимированые gif и sfw, ссылающиеся на другие порталы 100% нужно резать.
Например сайт http://chelyabinsk.mvideo.ru/ , на нем есть флеш анимированый, но рекламируют сами себя. Стоит их вырезать или нет? Такие сайты частенько попадаются.

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