Настраиваем squid
Общая настройка сквида чаще всего не вызывает сложностей. Сложности обычно вызывают три вещи - настройка ACL (access control list - список прав доступа) и правил для них, настройка дополнительных программ вроде баннерорезалок и настройка ограничений использования канала. Вот эти три вещи я и постараюсь описать в этой статье.
Итак, ACL. Обратимся к соответсвующему месту файла squid.conf и прокомментируем его.
ACL прописываются в виде строки acl имя_acl тип_acl параметры или acl имя_acl тип_acl "файл" - при этом в файле сохраняется по одному значению на строку.
Итак, пойдем по типам списков.
acl aclname src ip-address/netmask - в этом acl описывается ip-адрес или сеть, принадлежащая клиентам squid. Например:
acl vasya src 192.168.1.1/255.255.255.255 описывает единственную машину с адресом 192.168.1.1 и назначает ей ACL с именем vasya
acl office src 192.168.1.1/255.255.255.0 описывает диапазон машин с адресами 192.168.1.1-.254 и назначает этому ACL имя office. Если диапазон необходимо сузить, то необходимо либо изменить маску подсети, либо воспользоваться явным указанием - acl vip_user src 192.168.1.1-192.168.1.5/255.255.255.0. Здесь squid выбирает тот диапазон адресов, который окажется меньше - либо по маске, либо по явному указанию.
acl aclname dst ip-address/netmask - этот тип ACL описывает уже сервер, страницы с которого будут запрашивать клиенты. Особо отмечу - что в этом типа ACL задается не символьный адрес сервера, а ip.
acl aclname srcdomain .domain.ru - описывает клиентов, но уже не по ip-адресам, а по реверсным DNS. То есть в данном примере нет разницы, какие ip-адреса принадлежат клиентам - главное, что бы они определялись dns. Соответсвенно, пож это правило попадут все клиенты, стоящие в домене domain.ru.
acl aclname dstdomain .domain.ru - описывает сервер. Сравнивается с запросом из URL. Под этот ACL попадут все сервера 3его уровня домена domain.ru.
acl aclname srcdom_regex [-i] xxx
acl aclname dstdom_regex [-i] xxx
Описания аналогичны предыдущим, но теперь для выяснения, подходит ли правило под запрос, используются regex-правила. Если символьный адрес не смог определиться из ip-адреса, к запросу будет применена строка none.
acl aclname time [day-abbrevs] [h1:m1-h2:m2] - ACL, описывающий время. Коды дней недели определяются так: S - Sunday - Воскресенье, M - Monday - Понедельник, T - Tuesday - Вторник, W - Wednesday - Среда, H - Thursday - Четверг, F - Friday - Пятница, A - Saturday - Суббота.
Ну а вместо h1:m1 и h2:m2 вставляется время. Запомните - h1:m1 всегда должно быть меньше h2:m2.
Итак, acl worktime time MTWHF 08:00-17:00 описывает рабочее время с понедельника по пятницу, с 8 утра до 5 вечера. acl weekday time SA описывает целиком субботу с воскресеньем, а acl evening time 17:00-23:59 описывает время до полуночи. Если необходимо описать всю ночь, то приходится заводить два ACL- первый с вечера до полуночи, а второй с полуночи до утра.
acl aclname url_regex [-i] ^http:// - regex-правила, применяемый ко всему URL.
acl aclname urlpath_regex [-i] .gif$ - аналогичные правила, применяемые к URL.
acl aclname port 80 70 21 - ACL, описывающий порты. Вместо простого перечисления можно указать диапазон, например 1-1024.
acl aclname proto HTTP FTP - ACL, описывающий протокол, по которому клиент желает сделать запрос на сервер.
acl aclname method GET POST - метод, которым передаются данные клиента серверу.
acl aclname browser [-i] regexp - regexp запрос на клиентский браузер. Вычисления основаны на заголовке User-Agent, который отдает браузер.
acl aclname ident username - ACL описывает имя пользователя, от которого запущена программа на клиентской машине. Имя узнается с помощью ident-сервера.
acl aclname ident_regex [-i] pattern - то же самое, но основанное на regex правилах.
acl aclname proxy_auth username
acl aclname proxy_auth_regex [-i] pattern - ACL, описывающие имя пользователя. Это имя возвращает внешняя авторизующая программа.
acl aclname maxconn number - Это правило сработает, если клиент сделат больше number запросов к кешу.
acl req_mime_type mime-type1 - правило, срабатывающие при аплоаде файлов клиентом. Заметье, АПЛОАДЕ, а не скачивании.
Я конечно, некоторые описания ACL пропустил (большей частью по незнанию, что они значат), но большинство необходимых в повседневной жизни я описал. Думаю, мо вам этого тоже будет достаточно. Если не достаточно - то добро пожаловать на просмотр squid.conf - там все описано, правда, по английски.
Итак, давайте создадим правила обычной сети.
acl all src 0.0.0.0/0.0.0.0
acl office src 192.168.1.0/255.255.255.0
all - правило, описывающий все машины и office - описывающий все машины в подсети 192.168.1.
http_access allow office
http_access deny all
эти два правила описывают полный доступ машинам, описываемый acl office и запрещает доступ машинам, описываемым all. Как же так - спросите вы - как могут машины использовать прокси-сервер, если они попадают под правило all - а этому правилу запрещено? Тут в дело вступает порядок просмотра ACL - они просматриваются в порядке обьявления, и если сработало одно правило, то другие уже не просматриваются.
К примеру, если мы введем в дополнение ACL
acl vasya src 192.168.1.100/255.255.255.255
и расположим правила так:
http_access allow office
http_access deny vasya
http_access deny all
то машина с ip-адресом 192.168.1.100 по прежнему будет иметь возможность ходить через прокси-сервер.
а если так:
http_access deny vasya
http_access allow office
http_access deny all
То все будет в порядке. Остальные офисные машины не попадают под действие первого правила.
Если в списке нет ни одно правила, то запрос будет отвергнут. Если не одно правило не сработало, то за основу берется последнее. Если, к примеру, мы заменим предпоследнее правило на http_access allow all, то нашим прокси-сервером смогут совпользоваться абсолютно все (кроме vasya), кто сможет соедениться с портом squid. Так что будьте аккуратнее. Но авторы squid постарались - даже если последнее правило будет разрешающим всем все, то запрос будет отвергнут. Это поможет избежать дыр в прокси-сервере.
На основе этих же списков правил так же управляется и доступ к другим возможностям прокси - опять отсылаю вас к файлу squid.conf, где все расписано.
Но правила-правилами, но у вас в сети завелись пользователи, которые честно подключаются к серверу и начинают выкачивать гигабайтами какую-нибудь гадость. При этом занесение этих сайтов в deny-список вызывает их возмущение и капание начальству на предмет того, что на этих серверах находится очень важная для процветания фирмы информация. Ну кто из администраторов не встречался с такими?
На этот счет придумали много вещей, но самой эффективной остается ужимание канала для таких пользователей - доступ есть, но качается плохо - возразить им нечего - такая ситуация в интернете не редкость.
Итак, давайте разберемся с траффик-шейпингом - именно так эта штука называется. В squid же эта вещь носит название delay-pool. Замечу, что squid при сборке должен быть собран с опцией --enable-delay-pools.
Итак, сначала разберемся, какие есть пулы. Пулы делятся на 3 класса. Первый, и самый простой, это когда всему acl зарезается трафик до определенной величины. Второй - когда отдельно зарезается трафик для одной машины из подсети и для всей подсети. И третий класс - когда зарезается трафик для отдельных машин, для подсети класса С или меньше и для подсети класса B. Не понятно? Сейчас разьясню.
Итак, давайте обыграем ситуацию, когда у нас в сети завелся "дискокачальщик".
delay_pools 1 - у нас всего 1 пул.
delay_class 1 1 - 1й пул у нас первого класса
delay_access 1 allow vasya
delay_access 1 deny all
В первый пул попадают только машины, описываемые ACL vasya. Остальные ходят как им положенно - ведь им доступ к 1му пулу заказан.
delay_parameters 1 800/64000
Вот и все. Теперь файлики и страницы обьемом до 64кб будут скачиваться на максимальной скорости (то есть для веба хватит за глаза), а то, что больше этого - на скорости 800 байт в секунду.
Если он вас совсем достал, то напишите правило delay_parameters 1 800/800 - и злобный качальшик все будет качать на скорости 800 байт в секунду.
Но у вас офис и в его канале периодически начинается толчея - все хотя что-то качать, в итоге никому ничего не хватает.
Исправляем строчку с delay_pools на delay_pools 2
теперь у нас будет 2 пула
delay_class 2 2 - второй пул будет второго класса (совпадение номеров чисто случайно ;-)) - первый - это vasya
delay_access 2 allow office
delay_access 2 deny all
во второй пул попадают только машины с ACL office.
delay_parameters 2 64000/64000 4000/4000
В итоге вся подсеть, описываемая office, будет использовать канал не больше 512Кбит/с (64Кб/с), но каждый отдельный хост будет качать не более 4Кб в секунду. Этим правилом очень легко разграничить по скорости разные подсети, использующие один канал.
К примеру, у нас есть две подсети, описываемые office и office1. При этом office не должно иметь никаких ограничений на канал (примем канал за 256Кбит) в целом, но каждый из office не должен качать быстрее 6Кб/с. А office1 - это нехорошие дяденьки и тетеньки с большин гонором, которым всем и 5Кб/с хватит за глаза.
Создаем 2 пула 2го класса и прписываем для них ACL. Затем определяем этим пулам параметры.
delay_parameters 3 -1/-1 6000/6000 - это определение для office (ему отдан номер пула 3)
delay_parameters 4 5000/5000 -1/1 - а это для office1.
В итоге после применения этих правил получаем все, что заказано - первый офис грузит канал как хочет (-1/-1), но никто из сотрудников больше 6Кб/c на нос не получает. А второй офис грузит канал не больше 5Кб/с, а как данные 5Кб/с распределяются между его сотрудниками - не наша головная боль. Пауки в банке, так сказать.
Понятно, что в описание пулов можно заложить время, места и так далее, но конструирование таких правил я оставляю на вас - каждому нужно свое.
Остается еще одна маленькая вещь, мимо которой мы не можем пройти безнаказанно. И эта вещь - реклама. Не знаю, как вас, но меня достали эти разражающе мигающие и переливающиеся баннеры. И если порнуху можно запретить простым прописыванием сайтов в deny-листы, то с баннерами такая ситуация не проходит. То есть проходит, но страницы при этом портятся до безобразия. Но народ умный, он придумал такую вещь, как редиректор. Суть проста - каждый URL, который передается squid'у, первоначально передается редиректору. И тот либо возвращает прежний URL в случае, если все в порядке, либо возвращает тот, который по его мнению, более правильный. А кто мешает нам перехватывать обращения к баннерам и счетчикам и вместо них подсовывать свою картинку? Никто!. В итоге страницы не портятся безобразными значками о невозможности выкачать картинку, а заполняются прозрачными окошками.
Итак, опять лезем в squid.conf и прописываем туда строку redirect_program /squid/bin/redirector, где /squid/bin/redirector - путь до выполняемой программы, которая как раз и обеспечивает разбор URL. Ее можно написать на чем угодно, но наиболее предпочтительным является Perl - этот язык как раз предназначен для подобного рода работ.
Итак, вот эта программа.
Все, все необходимые действия проделаны (надеюсь, вы не забыли поставить аттрибут исполнения на redirector?), теперь просто перезагрузите сквид, очистите кэш браузера и пройдите по сайтам. Особый эффект наблюдается на price.ru - скорость закачки страниц подпрыгивает на очень большую величину.
При этом загрузка машины очень мала - даже я со своей домашней Р150 не замечаю замедления скорости работы. А трафик падает очень сильно - для диалапщиков такой редиректор просто спасение, потому как на некоторых сайтах (не буду показывать пальцем) обьем баннерной рекламы равен обьему полезной информации, а иногда и больше.
В общем, это хорошо. Да, чуть не забыл - полная версия редиректора лежит на http://linuxnews.ru/redirector - я ее обновляю время от времени, поэтому она почти соответствует последним веяниям баннеров (правда для тех сайтов, где народ из моего офиса обычно бывает). Оригинал редиректора был найден в сети, поэтому я никаких прав на него предявить не в состоянии, да и нет желания ;-)
Пользуйтесь на здоровье, вернее на пользу канала.
(с) 2001 Вячеслав Калошин multik@asplinux.ru
Итак, ACL. Обратимся к соответсвующему месту файла squid.conf и прокомментируем его.
ACL прописываются в виде строки acl имя_acl тип_acl параметры или acl имя_acl тип_acl "файл" - при этом в файле сохраняется по одному значению на строку.
Итак, пойдем по типам списков.
acl aclname src ip-address/netmask - в этом acl описывается ip-адрес или сеть, принадлежащая клиентам squid. Например:
acl vasya src 192.168.1.1/255.255.255.255 описывает единственную машину с адресом 192.168.1.1 и назначает ей ACL с именем vasya
acl office src 192.168.1.1/255.255.255.0 описывает диапазон машин с адресами 192.168.1.1-.254 и назначает этому ACL имя office. Если диапазон необходимо сузить, то необходимо либо изменить маску подсети, либо воспользоваться явным указанием - acl vip_user src 192.168.1.1-192.168.1.5/255.255.255.0. Здесь squid выбирает тот диапазон адресов, который окажется меньше - либо по маске, либо по явному указанию.
acl aclname dst ip-address/netmask - этот тип ACL описывает уже сервер, страницы с которого будут запрашивать клиенты. Особо отмечу - что в этом типа ACL задается не символьный адрес сервера, а ip.
acl aclname srcdomain .domain.ru - описывает клиентов, но уже не по ip-адресам, а по реверсным DNS. То есть в данном примере нет разницы, какие ip-адреса принадлежат клиентам - главное, что бы они определялись dns. Соответсвенно, пож это правило попадут все клиенты, стоящие в домене domain.ru.
acl aclname dstdomain .domain.ru - описывает сервер. Сравнивается с запросом из URL. Под этот ACL попадут все сервера 3его уровня домена domain.ru.
acl aclname srcdom_regex [-i] xxx
acl aclname dstdom_regex [-i] xxx
Описания аналогичны предыдущим, но теперь для выяснения, подходит ли правило под запрос, используются regex-правила. Если символьный адрес не смог определиться из ip-адреса, к запросу будет применена строка none.
acl aclname time [day-abbrevs] [h1:m1-h2:m2] - ACL, описывающий время. Коды дней недели определяются так: S - Sunday - Воскресенье, M - Monday - Понедельник, T - Tuesday - Вторник, W - Wednesday - Среда, H - Thursday - Четверг, F - Friday - Пятница, A - Saturday - Суббота.
Ну а вместо h1:m1 и h2:m2 вставляется время. Запомните - h1:m1 всегда должно быть меньше h2:m2.
Итак, acl worktime time MTWHF 08:00-17:00 описывает рабочее время с понедельника по пятницу, с 8 утра до 5 вечера. acl weekday time SA описывает целиком субботу с воскресеньем, а acl evening time 17:00-23:59 описывает время до полуночи. Если необходимо описать всю ночь, то приходится заводить два ACL- первый с вечера до полуночи, а второй с полуночи до утра.
acl aclname url_regex [-i] ^http:// - regex-правила, применяемый ко всему URL.
acl aclname urlpath_regex [-i] .gif$ - аналогичные правила, применяемые к URL.
acl aclname port 80 70 21 - ACL, описывающий порты. Вместо простого перечисления можно указать диапазон, например 1-1024.
acl aclname proto HTTP FTP - ACL, описывающий протокол, по которому клиент желает сделать запрос на сервер.
acl aclname method GET POST - метод, которым передаются данные клиента серверу.
acl aclname browser [-i] regexp - regexp запрос на клиентский браузер. Вычисления основаны на заголовке User-Agent, который отдает браузер.
acl aclname ident username - ACL описывает имя пользователя, от которого запущена программа на клиентской машине. Имя узнается с помощью ident-сервера.
acl aclname ident_regex [-i] pattern - то же самое, но основанное на regex правилах.
acl aclname proxy_auth username
acl aclname proxy_auth_regex [-i] pattern - ACL, описывающие имя пользователя. Это имя возвращает внешняя авторизующая программа.
acl aclname maxconn number - Это правило сработает, если клиент сделат больше number запросов к кешу.
acl req_mime_type mime-type1 - правило, срабатывающие при аплоаде файлов клиентом. Заметье, АПЛОАДЕ, а не скачивании.
Я конечно, некоторые описания ACL пропустил (большей частью по незнанию, что они значат), но большинство необходимых в повседневной жизни я описал. Думаю, мо вам этого тоже будет достаточно. Если не достаточно - то добро пожаловать на просмотр squid.conf - там все описано, правда, по английски.
Итак, давайте создадим правила обычной сети.
acl all src 0.0.0.0/0.0.0.0
acl office src 192.168.1.0/255.255.255.0
all - правило, описывающий все машины и office - описывающий все машины в подсети 192.168.1.
http_access allow office
http_access deny all
эти два правила описывают полный доступ машинам, описываемый acl office и запрещает доступ машинам, описываемым all. Как же так - спросите вы - как могут машины использовать прокси-сервер, если они попадают под правило all - а этому правилу запрещено? Тут в дело вступает порядок просмотра ACL - они просматриваются в порядке обьявления, и если сработало одно правило, то другие уже не просматриваются.
К примеру, если мы введем в дополнение ACL
acl vasya src 192.168.1.100/255.255.255.255
и расположим правила так:
http_access allow office
http_access deny vasya
http_access deny all
то машина с ip-адресом 192.168.1.100 по прежнему будет иметь возможность ходить через прокси-сервер.
а если так:
http_access deny vasya
http_access allow office
http_access deny all
То все будет в порядке. Остальные офисные машины не попадают под действие первого правила.
Если в списке нет ни одно правила, то запрос будет отвергнут. Если не одно правило не сработало, то за основу берется последнее. Если, к примеру, мы заменим предпоследнее правило на http_access allow all, то нашим прокси-сервером смогут совпользоваться абсолютно все (кроме vasya), кто сможет соедениться с портом squid. Так что будьте аккуратнее. Но авторы squid постарались - даже если последнее правило будет разрешающим всем все, то запрос будет отвергнут. Это поможет избежать дыр в прокси-сервере.
На основе этих же списков правил так же управляется и доступ к другим возможностям прокси - опять отсылаю вас к файлу squid.conf, где все расписано.
Но правила-правилами, но у вас в сети завелись пользователи, которые честно подключаются к серверу и начинают выкачивать гигабайтами какую-нибудь гадость. При этом занесение этих сайтов в deny-список вызывает их возмущение и капание начальству на предмет того, что на этих серверах находится очень важная для процветания фирмы информация. Ну кто из администраторов не встречался с такими?
На этот счет придумали много вещей, но самой эффективной остается ужимание канала для таких пользователей - доступ есть, но качается плохо - возразить им нечего - такая ситуация в интернете не редкость.
Итак, давайте разберемся с траффик-шейпингом - именно так эта штука называется. В squid же эта вещь носит название delay-pool. Замечу, что squid при сборке должен быть собран с опцией --enable-delay-pools.
Итак, сначала разберемся, какие есть пулы. Пулы делятся на 3 класса. Первый, и самый простой, это когда всему acl зарезается трафик до определенной величины. Второй - когда отдельно зарезается трафик для одной машины из подсети и для всей подсети. И третий класс - когда зарезается трафик для отдельных машин, для подсети класса С или меньше и для подсети класса B. Не понятно? Сейчас разьясню.
Итак, давайте обыграем ситуацию, когда у нас в сети завелся "дискокачальщик".
delay_pools 1 - у нас всего 1 пул.
delay_class 1 1 - 1й пул у нас первого класса
delay_access 1 allow vasya
delay_access 1 deny all
В первый пул попадают только машины, описываемые ACL vasya. Остальные ходят как им положенно - ведь им доступ к 1му пулу заказан.
delay_parameters 1 800/64000
Вот и все. Теперь файлики и страницы обьемом до 64кб будут скачиваться на максимальной скорости (то есть для веба хватит за глаза), а то, что больше этого - на скорости 800 байт в секунду.
Если он вас совсем достал, то напишите правило delay_parameters 1 800/800 - и злобный качальшик все будет качать на скорости 800 байт в секунду.
Но у вас офис и в его канале периодически начинается толчея - все хотя что-то качать, в итоге никому ничего не хватает.
Исправляем строчку с delay_pools на delay_pools 2
теперь у нас будет 2 пула
delay_class 2 2 - второй пул будет второго класса (совпадение номеров чисто случайно ;-)) - первый - это vasya
delay_access 2 allow office
delay_access 2 deny all
во второй пул попадают только машины с ACL office.
delay_parameters 2 64000/64000 4000/4000
В итоге вся подсеть, описываемая office, будет использовать канал не больше 512Кбит/с (64Кб/с), но каждый отдельный хост будет качать не более 4Кб в секунду. Этим правилом очень легко разграничить по скорости разные подсети, использующие один канал.
К примеру, у нас есть две подсети, описываемые office и office1. При этом office не должно иметь никаких ограничений на канал (примем канал за 256Кбит) в целом, но каждый из office не должен качать быстрее 6Кб/с. А office1 - это нехорошие дяденьки и тетеньки с большин гонором, которым всем и 5Кб/с хватит за глаза.
Создаем 2 пула 2го класса и прписываем для них ACL. Затем определяем этим пулам параметры.
delay_parameters 3 -1/-1 6000/6000 - это определение для office (ему отдан номер пула 3)
delay_parameters 4 5000/5000 -1/1 - а это для office1.
В итоге после применения этих правил получаем все, что заказано - первый офис грузит канал как хочет (-1/-1), но никто из сотрудников больше 6Кб/c на нос не получает. А второй офис грузит канал не больше 5Кб/с, а как данные 5Кб/с распределяются между его сотрудниками - не наша головная боль. Пауки в банке, так сказать.
Понятно, что в описание пулов можно заложить время, места и так далее, но конструирование таких правил я оставляю на вас - каждому нужно свое.
Остается еще одна маленькая вещь, мимо которой мы не можем пройти безнаказанно. И эта вещь - реклама. Не знаю, как вас, но меня достали эти разражающе мигающие и переливающиеся баннеры. И если порнуху можно запретить простым прописыванием сайтов в deny-листы, то с баннерами такая ситуация не проходит. То есть проходит, но страницы при этом портятся до безобразия. Но народ умный, он придумал такую вещь, как редиректор. Суть проста - каждый URL, который передается squid'у, первоначально передается редиректору. И тот либо возвращает прежний URL в случае, если все в порядке, либо возвращает тот, который по его мнению, более правильный. А кто мешает нам перехватывать обращения к баннерам и счетчикам и вместо них подсовывать свою картинку? Никто!. В итоге страницы не портятся безобразными значками о невозможности выкачать картинку, а заполняются прозрачными окошками.
Итак, опять лезем в squid.conf и прописываем туда строку redirect_program /squid/bin/redirector, где /squid/bin/redirector - путь до выполняемой программы, которая как раз и обеспечивает разбор URL. Ее можно написать на чем угодно, но наиболее предпочтительным является Perl - этот язык как раз предназначен для подобного рода работ.
Итак, вот эта программа.
#!/usr/bin/perl
$0 = 'redirect' ;
$| = 1 ;
@banners = ('reklama.ru/cgi-bin/banner/',
'anekdot.ru/cgi-bin/banner/',
..................
'linux.ru.net/counter.ph',
'counter.allhits.ru/counter?'
);
while (<>) {
($url, $who, $ident, $method) = /^(S+) (S+) (S+) (S+)$/ ;
$url = 'http://linuxnews.ru/images/1x1.png'
if grep ($url=~/$_/i, @banners) ;
print "$url $who $ident $method " ;
}
Эта программа проста по сути - если данный URL попадает под список banners, то в ответ браузеру возвращается http://linuxnews.ru/images/1x1.png. Как легко догадаться - там лежит картинка размером 1 на 1 пиксел. Везде в описании баннеров и счетчиков стоит размер, поэтому браузеры сами растягивают эту картинку до размеров баннера. Понятно, что адрес можете заменить на свой, но можете оставить и мой - поесле первого обращения прокси закэширует эту картинку и больше к ней обращаться не будет.Все, все необходимые действия проделаны (надеюсь, вы не забыли поставить аттрибут исполнения на redirector?), теперь просто перезагрузите сквид, очистите кэш браузера и пройдите по сайтам. Особый эффект наблюдается на price.ru - скорость закачки страниц подпрыгивает на очень большую величину.
При этом загрузка машины очень мала - даже я со своей домашней Р150 не замечаю замедления скорости работы. А трафик падает очень сильно - для диалапщиков такой редиректор просто спасение, потому как на некоторых сайтах (не буду показывать пальцем) обьем баннерной рекламы равен обьему полезной информации, а иногда и больше.
В общем, это хорошо. Да, чуть не забыл - полная версия редиректора лежит на http://linuxnews.ru/redirector - я ее обновляю время от времени, поэтому она почти соответствует последним веяниям баннеров (правда для тех сайтов, где народ из моего офиса обычно бывает). Оригинал редиректора был найден в сети, поэтому я никаких прав на него предявить не в состоянии, да и нет желания ;-)
Пользуйтесь на здоровье, вернее на пользу канала.
(с) 2001 Вячеслав Калошин multik@asplinux.ru
8 Мая 2001
Комментариев нет:
Отправить комментарий