old

Походу да, потому что именно под FastCGI exit() делать нельзя и приходится выкручиваться, переопределением в том числе. Вот тут пример граблей, если вдруг кому интересно...

Решил почитать на ночь код и заметил следующий кусок: #this keeps the program alive or something after exec'ing perl scripts END() { } BEGIN() { } {no warnings; *CORE::GLOBAL::exit = sub { die "fakeexit\nrc=".shift()."\n"; }; }; eval q{exit}; if ($@) { exit unless $@ =~ /^fakeexit/; }; Вообще-то это что-то связанное с FastCGI ( к примеру, см. Perl + FastCGI + nginx , "Пример с codemongers.com"), а данном контексте оно что делает? Глобально переопределяет "exit"? Но тогда, если верить доке , переопределение должно быть сделано внутри блока BEGIN. Я попробовал потестировать это кусок кода, но в текущем виде не заметил от него никакой реакции. Кто-нибудь может подсказать, зачем он нужен в этом демоне?

Некоторые модели свитчей D-Link имеют возможность управления с помощью фирменной программы SmartConsole, которая использует некий проприетарный протокол, в котором, в том числе, предусмотрена возможность отправки управляемым устройством trap'ов, ничего общего с SNMPшными не имеющими и стандартными средствами, рассчитанными на SNMP, не обрабатываемыми. Т.к. оказалось, что как минимум серия DES-1100 ничего кроме этих trap'ов слать не умеет (там нет поддержки ни SNMP, ни даже syslog), то пришлось реализовать их прием и обработку (запись в syslog), благо формат сообщений оказался весьма простым. Если кто-то заинтересовался, то исходный код лежит здесь. Писалось и работает под FreeBSD 8 и 9, под Linux обеспечена сборка, но, к сожалению, не тестировалось. Что бы это все работало, в свитче надо включить отсылку trap'ов, причем IP адрес целевой машины должен быть внутри сети, которой принадлежит IP интерфейса свитча (наступил на эти грабли с DES-1100, у других моделей может быть по-другому).

Добрый день. Какая серия коммутаторов ZTE поддерживает балансировку по IP при объединении портов LACP'ом?

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

Настраивая ospfd из quagg'и, обнаружил, что в последней версии из портов (quagga-0.99.17_3) он не работает в 7.3-RELEASE-p*, выдавая ошибку при этом в "ifmcstat -i vlan0" видно, что vlan0 не слушает multicast-группу 224.0.0.5. В тоже время на 8.1-RELEASE-p* все работает без проблем. Гугление привело к закрытому PR. После того, как откатил назад патч, закрывающий этот PR (что бы не заморачиваться с portdowngrade, просто удалил net/quagga/files/patch-lib-sockopt.c) и пересобрал quagga, все заработало. На тех машинах с 7.3-RELEASE-p*, где стояла quagga-0.99.17, собранная до сентября (время закрытия PR), все заработало сразу без танцев с откатом патча. Похоже, в портах поломанная quagga (для случая FreeBSD 7.3), никто с подобным не сталкивался? И немного про mpd 5.5 + quagga ospfd: когда mpd создает новые интерфейсы ng (скажем, после перезагрузки), в конфиге ospfd они появляются с прописанной на них командой Клиентский IP с такого интерфейса почему-то либо не анонсится вообще, либо вместо него анонсится IP с нашего конца туннеля, причем не взирая на route-map или distribution list. После очистки конфига интерфейса ng ("no ip ospf network") все работает нормально до следующего ребута. "passive-interface default" в настройках ospf включено: router ospf ospf router-id 192.168.25.92 log-adjacency-changes detail compatible rfc1583 redistribute connected route-map STATIC-VPN passive-interface default no passive-interface vlan0 network 192.168.25.88/29 area 0.0.0.2 network 192.168.96.0/23 area 0.0.0.2 area 0.0.0.2 authentication message-digest area 0.0.0.2 stub ! access-list 10 permit 192.168.96.0 0.0.1.255 route-map STATIC-VPN permit 10 match ip address 10 ! Такое поведение вообще нормально или я что-то пропустил?

[skipped]просто в config.h заменил строку /* #undef HAVE_LINUX_IF_TUN_H */ Как оказалось, патчить не обязательно. Достаточно запустить configure с опцией --host mips-linux, а не --host mips. И обязательно обратить внимание, что бы симлинки tap_dev.c и tun_dev.c смотрели на файлы в каталоге linux, а не generic. Как оказалось, configure, если видит, что они уже созданы, то не меняет их, даже если они неправильные. Полностью строка запуска configure выгдела вот так:./configure --host mips-linux --build=i686 --prefix="${APP_PATH}/vtun-3.0.0/filesystem" --disable-ssl --disable-lzo --disable-zlib Тут еще проще, потому что configure поновее. Достаточно --host mips-linux, либо --host mips --target=mips-linux, а можно и все вместе:./configure --host mips-linux --build=i686 --target=mips-linux --prefix="${APP_PATH}/openvpn-2.0.9/filesystem" --disable-ssl --disable-lzo --disable-crypto --disable-debug --enable-small

Ну вот и первая success story ;) При сборке vtun'а надо было заставить его собираться с системным TUN/TAP драйвером, а не со встроенным. Я не разбирался до конца, почему configure не задетектил системный драйвер (хотя у меня есть предположение, что это из-за того, что он вообще не понял, что целевая система linux), просто в config.h заменил строку /* #undef HAVE_LINUX_IF_TUN_H */ на #define HAVE_LINUX_IF_TUN_H Да, и еще в mkimg в блок создания устройств в /dev надо дописать mkdir $RW_ROOT/dev/net mknod -m666 $RW_ROOT/dev/net/tun c 10 200 Кста, походу собрал openvpn, там при сборке похожие грабли, configure не детектит целевую систему и собирается без поддержки системного TUN/TAP. После принудительного #define TARGET_LINUX в config.h сборка происходит без проблем.

Кто-нибудь может поделиться success story про запуск vtun'а в Wive-0.6.0? Потому что пытаюсь запустить его в режиме клиента, он запускается, поднимает соединение с удаленной стороной, после чего обваливается с руганью: "Can't allocate tap device tap1. No such file or directory(2)" Смотрю в /dev - все правильно, нет такого устройства, гуглю, создаю его mknod /dev/tap1 c 10 200, получаю ругань:"File descriptor in bad state (81)". И так с любым устройством tun/tap. По опыту использования vtun/openvpn на других системах, это очень похоже на то, что в системе отсутствует драйвер tun/tap, но в выводе dmesg видно, что он таки в ядре еть. У кого какие мысли есть по такому случаю? Кста, пока обгугливал эту тему, нашел как минимум один схожий случай, когда драйвер не работал, будучи вкомпиленным в ядро, но все заработало в модульном варианте...

1) c svn обновление взяли, rtl83xx_dlink_des1016d пересобрали? там раньше было недописано сохранение настроек igmp snooping'а, я поправил 2) flash точно открылось на запись? при "reboot soft" перезапускаются только интерфейсы, сам чип не ребутится. "reboot hard" аналогичен перезапуску по питанию.

"% Not implemented yet" означает, что запись в EEPROM в rrcp_cli пока не реализована. Сейчас запись работает только в rtl83xx, т.е. в вашем случае надо выполнить команду ./rtl83xx_dlink_des1016d 52:54:4с:01:02:03@eth0 write memory Извините, поторопился. Предварительно возьмите обновление с svn и пересоберите rtl83xx_dlink_des1016d.

"% Not implemented yet" означает, что запись в EEPROM в rrcp_cli пока не реализована. Сейчас запись работает только в rtl83xx, т.е. в вашем случае надо выполнить команду ./rtl83xx_dlink_des1016d 52:54:4с:01:02:03@eth0 write memory

Скорее, арпанет был ответом на ОГАС, вот здесь это достаточно подробно описано: История вычислительной техники в лицах

RealTek - любую на rtl8139. Если в драйверах производителя платы нет поддержи VLAN, можно попробовать универсальные драйвера с www.realtek.com.tw Intel - практически любую. Или, как вариант, платы на rtl8169s, к примеру TP-Link TG-3269. На 100Mb/s оно работает без проблем, в качестве бонуса умеет hardware tagging, хотя лично я это не проверял. Просто стоят они меньше $20.

Asus P5LD2-VM DH, не путать с просто P5LD2-VM. 4 SATA (умеют AHCI и 300MB/s трансфер) плюс 2 PATA/100 на ICH7R и 2 PATA/133 на ITE8211F для пущей радости. Onboard video и Intel 1Gb LAN, причем, что весьма ценно - PCI Express based. ICH7R вообще-то умеет недоRAID, но не одновременно с AHCI, так что лучше сразу делать софтовый RAID. Для нормальной работы надо отключить в BIOS'е "Intel Quick Resume", в остальном этими материнками доволен. Использую FreeBSD 6.1-STABLE, но делал и сервер с Linux (kernel 2.6.17.11, 2.4.х не видят LAN).

Всем добрый день/вечер. Возникла задача оконечить оптику, со стороны провайдера включенную в свитч имени Nortel'а. Порт 100Мб/с, не WDM. Мы обычно используем WDM, так что проверить методом научного тыка, какой медиаконвертер подойдет, я не могу. Может кто поделится опытом, а то Nortel в наших краях зверь редкий, непуганный :) Просто провайдер вспомнил о том, что у него на точке включения, куда подведена наша оптика, нет обычных fastethernet портов в последний момент, когда я уже договаривался везти к ним наш конвертер ;(

Реле на 12 или 5 вольт к соответсвующим выводам БП, нормально _замкнутые_ контакты - параллельно кнопке power.