GGR

ОМГ, после этой фразы хочется узнать кто именно из руководства ИСа санкционировал такую акцию, можно конкретные фамилии встудию? Все челябинские операторы тихо валяюца пацталом от смеха =)

>Проблема в следующем: для проверки спама давно прикручен amavis, и в результате >после добавления mailmana не включается его роутер с предыдущей проблемой справился сам, домен в рутере надо было указывать без '*.' однако возникла следующая проблема: в доках на mailman пишут для eximа # The path of the Mailman mail wrapper script MAILMAN_WRAP=MAILMAN_HOME/mail/mailman в моем случае дистриб ставился из rpm и такого каталога просто не существует. Кто знает что ТОЧНО должно указываться в этом параметре exim.conf? Я сначала предположил что это путь до враппера mailman/bin/wrapper.sh, не получилось...

Коллеги помогите кто прикручивал такую связку ALT Linux Master 2.4 (Citron) Дружу mailman 2.1.7 и Exim 4 Проблема в следующем: для проверки спама давно прикручен amavis, и в результате после добавления mailmana не включается его роутер -- exim -bt mailman@list.my.ru mailman@list.my.ru router = amavis, transport = amavis host localhost.localdomain [127.0.0.1] -- и при попытке послать письмо на mailman@list.my.ru exim ругается что нет такого пользователя (список с таким именем нормально заведен и виден в конфигураторе) exim.conf ---------- domainlist local_domains = localhost : list.my.ru mailman_router: driver = accept domains = *.list.my.ru require_files = MAILMAN_HOME/lists/$local_part/config.pck local_part_suffix_optional local_part_suffix = -bounces : -bounces+* : -confirm+* : -join : -leave : -owner : -request : -admin transport = mailman_transport amavis: driver = manualroute # Do NOT run if received via 10025/tcp or if already spam-scanned # or if bounce message ($sender_address="") condition = "${if or {{eq {$interface_port}{10025}} {eq {$received_protocol}{spam-scanned}} {eq {$sender_host_address}{127.0.0.1}} }{0}{1}}" transport = amavis route_list = "* localhost byname" self = send no_verify no_expn mailman_transport: driver = pipe command = MAILMAN_WRAP .${if def:local_part_suffix {${sg{$local_part_suffix}{-(w+)(+.*)?}{$1}}} {post}}. $local_part current_directory = MAILMAN_HOME home_directory = MAILMAN_HOME user = MAILMAN_USER group = MAILMAN_GROUP amavis: driver = smtp port = 10024 allow_localhost ---------- и mailman и exim запускаются без ругани Я так понимаю что amavis просто перехватывает раньше, где неправильно и как бы так заставить amavis игнорировать все то что послано на домен list.my.ru?

Нет нет про километры никто пока не заикается =) Питание берем в каждом доме в начальной точке и тянем на все ящики в этом доме. И хотелось бы всетаки промышленное решение. Резервирование соседних домов или друг друга пока непонятно как делать если между домами Пэшку использовать.

2ingr Ну и решение хочется получить общее, потому что варианты разные могут быть. Для конкретизации можно выбрать простой вариант: 1) длинный дом (более 10 подъездов) => более 5 ящиков, т.е звезду сделать нельзя 2) магистраль - обычная витушка 3) в ящиках необходимо иметь возможность устанавливать более одного активного устройства, допустим пара коммутаторов Compex PS2216 3.3/7.5 вольтовые (в указанной мной выше схеме - 2 таких 16-ка уже просаживают питание если длина магистрали близко подходит к критической) Кабель с каким сечением, какой марки лучше использовать если принять решение передавать питание отдельным проводом а не по магистрали?

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

Можно поподробнее что конкретно вы оттуда используете в работе? а то я там не нашел ничего аналогичного преобразователям 220->60->220 Из интересного - маленький дешевый управляемый коммутатор и пингалки неплохие но дорогие.

Коллеги, кто работает в сфере больших домовых сетей, подскажите свои методы решения проблемы с питаловом в ящиках с оборудованием. Если мы имеем цепочку коммутаторов в доме, очень хочется питать их из одной точки, с возможностью управлением питания. Есть решение с опускающими и поднимающими трансформаторами и пуском питалова по парам магистральной линии. Но оно выполнено на кустарном уровне - есть ли готовое аналогичное решение на промышленном уровне? Как решается проблема запитки более чем одного коммутатора в одном ящике (просаживание питалова)? Есть ли аналогичное решение с помощью Power over Ethernet? Может кто-то промышленно использует PoE - расскажите про свою топологию, как где что устанавливаете, какое оборудование используете, надежность работы... и тд...

Коллеги а не поделитесь ли c7200-js-mz.12.3-9 а то его на ftp что-то уже нет... Очень буду признателен... Либо любым стабильным для 72й где есть одновременно MPLS и PPPoE...

В случае с впн крайне не рекомендую использование DI-604 за его многочисленные глюки с впн, можете пробовать DI-804 он гораздо стабильнее хотя и дороже...

Отвечаю - просто планируется использовать это там и на тех железках и в тех случаях где опасность снифферения сведена к нулю а гемороится с логинами и паролями для железок очень не хочется. Живые клиенты конечно будут ходить по логину/паролю

Честно говоря в приведенном примере атрибутов не увидел ни одного вендоровского аттрибута, так что такое ощущение что включить таки их забыли =) вот пример лога Радиуса с вендоровскими аттрибутами RADIUS: Vendor, Cisco [26] 16 RADIUS: cisco-nas-port [2] 10 "0/0/1/11" RADIUS: Vendor, Cisco [26] 41 RADIUS: Cisco AVpair [1] 35 "client-mac-address =0080.4834.0578" RADIUS: Vendor, Cisco [26] 32 RADIUS: Cisco AVpair [1] 26 "connect-progress=C all Up"

Когда проверяли в цыске вендоровские аттрибуты не забыли разрешить на аккаунтинг и авторизацию?

CISCO 3640, IOS Version 12.3(12) цыска выдает мак в вендоровском атрибуте Cisco AVpair [1] 35 "client-mac-address=0080.4834.0578" ------------------ ЗЫ. После долгого вдумчивого гугления определилось что цыска теоритически ДОЛЖНА выдавать МАС в поле Calling-Station-ID и в параметрах настройки цыски даже есть такая командочка как radius-server attribute 31 mac format НО заставить выдать это поле Радиусу у меня так и не получилось, в дебаге на цыске того что передается Радиусу этот атрибут отсутствует =( ....

День добрый коллеги Представляю одного из крупный провайдеров г. Челябинска Есть насущная проблема может кто-то что-то знает как решать Задача: клиенты терминируются на цыске по PPPoE, авторизуются во внешнем Радиусе, необходимо сделать авторизацию по MAC-адресу(этонеобходимо для некоторых железок). Проблема в том что информация о MAC передается Радису цыской только в ACCOUNTING_REQUEST а в первом запросе на авторизацию пусто. Как включать это в цыске, куда рыть? шаманство про NAS-Port не дало результата, там такого нет...