GHhost

В теории, а по факту ДНС серверов куча - боюсь не доживу когда коньчаца.

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

это бесполезно, никакой диагностики нет, способа воспроизвести тоже, одни подозрения что виноват unbound, че толку от этого тикета.

ну траффик большой понятие относительное, но клиентов у нас pdns сервит аш пыль столбом, проблем с ним небыло никогда. P.S. В моих глюках с unbound ситуация что авторитативный сервер не ответил была практически исключена, во первых их там два, во вторых на них логгинг - еслип не ответил написал бы, ну и они там под боком - настолько крутой packet loss я бы тоже практически исключил - мониторинг оборался бы значительно раньше. Еще пробовал форвардить на рекурсоры - тоже не помогло, тоесть чтото всетаки с unbound не так было.

хм, творилось нечто подобное, unbound с форвардом около 10 зон, тоже работало года 2, ну обновлялось конечно, но проблемы начались с месяц назад - периодические факапы с резольвингом чего нибудь из этих зон лечащиеся рестартом, замена на stub ниче не дала, обновление до последнего тоже, стоял он в тепличном месте можно сказать - клиентских запросов к нему небыло, обслуживал он только почтовик и всякую его вспомогательную хрень фильтрующую спам. в итоге не стал разбираца - плюнул и переехал на bind.

Спасибо помогло, я главное нагуглил это же еще до того как тут спросить, но не подумав влепил в общей конфигурации и это не возымело никакого эффекта, но ваш ответ заставил задумаца и попробовать в route-instance в котором интерфейс и все поехало.

Есть вопрос по bgp в жунипере, вобщем есть вот так: show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 6053 6049 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 100.64.5.1 42916 29045 2633 0 0 1d 15:00:29 6049/6053/6053/0 0/0/0/0 root@J> show route advertising-protocol bgp 100.64.5.1 inet.0: 6067 destinations, 6071 routes (6067 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.32.18.176/28 Self 20 100 I * 10.32.75.176/30 Self 20 100 I * 100.64.5.1/32 Self 100 I * 100.64.5.5/32 Self 100 I * 100.64.5.8/30 Self 100 I * 100.64.66.0/24 Self 20 100 I root@J> root@J> show route 100.64.5.2 extensive inet.0: 6067 destinations, 6071 routes (6067 active, 0 holddown, 0 hidden) 100.64.5.2/32 (1 entry, 1 announced) *Local Preference: 0 Next hop type: Local Address: 0x8d4af64 Next-hop reference count: 9 Next hop: Interface: st0.0 State: <Secondary Active NoReadvrt Int> Age: 1d 15:02:25 Task: IF Announcement bits (1): 5-Resolve tree 1 AS path: I Primary Routing Table AS42916-VPN.inet.0 AS42916-VPN.inet.0: 3 destinations, 5 routes (3 active, 0 holddown, 0 hidden) 100.64.5.2/32 (2 entries, 1 announced) *Local Preference: 0 Next hop type: Local Address: 0x8d4af64 Next-hop reference count: 9 Next hop: Interface: st0.0 State: <Active NoReadvrt Int> Age: 1d 15:02:25 Task: IF Announcement bits (1): 1-rt-export AS path: I OSPF Preference: 10 Next hop type: Router Address: 0x8fae400 Next-hop reference count: 1 Next hop: via st0.0, selected State: <Int> Inactive reason: Route Preference Age: 1d 15:02:00 Metric: 0 Area: 0.0.0.0 Task: AS42916-VPN-OSPF AS path: I root@J> Тоесть проще говоря он почемуто не анонсирует 100.64.5.2 со своего локального интерфейса, и только с этого, с которого собсно bgp поднято, с других directly-connected маршруты есть. интерфейс выглядит вот так: root@J# show interfaces st0 unit 0 { description IPSEC-VPN_to_AS42916; family inet { address 100.64.5.2/32 { destination 100.64.5.1; } } } Единственные его отличия остальных в том что st0.0 находица в другом route instance и что с него поднимается bgp сессия. Это так и задумано или всетаки есть способ заставить его проанонсировать 100.64.5.2/32 с st0.0?

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

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

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

Хренова слышали, онлайникам какрас глубоко пох на синусоиду, это смартам хренова ибо трансформатор на входе.

оо, форум починили:) можно ответить:) заким хреном ups отключать то? сядет-сам погаснет, дадут питание - включица, сервера nut погасить в состоянии.

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

чем то напоминает анекдот про как десантник может вступить в рукопашный бой:) завершающюю его часть в частности:)

похоже что он. lsusb Bus 003 Device 002: ID 093a:2521 Pixart Imaging, Inc. Optical Mouse Bus 002 Device 002: ID 0001:0000 Fry's Electronics Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 004: ID 1a2c:2124 China Resource Semico Co., Ltd Bus 005 Device 055: ID 11c0:5603 Betop Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub у меня немного другой https://shop.nag.ru/catalog/09839.On-line/17926.IBP-moschnostyu-1-kVA/19054.SNR-UPS-ONRM-1000-XL24 , но попробуй так: /etc/nut/ups.conf [klingon] driver = blazer_usb port = auto desc = "snr online ups" #default.battery.voltage.high=27.24 #default.battery.voltage.high=27.00 default.battery.voltage.high=25.60 default.battery.voltage.low=21.6 novendor #norating у меня работает: #upsc klingon@localhost battery.charge: 100 battery.voltage: 27.24 battery.voltage.high: 25.60 battery.voltage.low: 21.6 battery.voltage.nominal: 24.0 device.type: ups driver.flag.novendor: enabled driver.name: blazer_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.internal: 0.12 input.current.nominal: 5.0 input.frequency: 50.1 input.frequency.nominal: 50 input.voltage: 214.1 input.voltage.fault: 206.0 input.voltage.nominal: 220 output.voltage: 220.5 ups.beeper.status: enabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 38 ups.productid: 0000 ups.status: OL ups.temperature: 25.0 ups.type: online ups.vendorid: 0001 #

/me обычно уверенных в том что для того чтоп понравилось необходимо стать клиентом отправляет в поход сразу же.

С такими вводными боюсь без телепатов никак.

Повезло тебе может, не имел критической массы и мимо прошло. Мильтерами оно обрастает сразу же, если это нормальный публичный сервис а не какиенить рога с капытами. https://www.freebsd.org/security/advisories.html это явно какаято хрень, https://www.cvedetails.com/vendor/31/Sendmail.html тут кстати тоже почемуто, и они не совпадают, 2000 года вообще нет, но почемуто есть вот к примеру вот это https://www.cvedetails.com/cve/CVE-2000-0319/ за 2000 год, а реально там было все очень плохо одно время. явно не все там учтено у них и у бсдэшников тоже. Сдается мне что на многие дыры они CVE просто не заводили.

на моей памяти этих дыр было значительно больше и их реально эксплуатировали вдобавок, просыпаешся утром а там ой - спам рассылаем или фсе сломали, ну рас сломали 2 сломали 3 сломали скока можно то, даунтаймы стали перевешивать все преимущества, потому и пришлось переехать на exim, в то время еще 3, который казался немного убогим конечно после мощи сендмейла, но зато его никто не ломали:) не уверен точно но это было чуток пораньше 2003 года. В m4 не нравица собсно наличие m4, зачем он нужен? По поводу гибкости тут это бесспорно конечно, sendmail в то время не имел практически равноценных альтернатив в этом плане, поэтому мирились со всеми граблями и дырами, сколько могли.

у меня sendmail жил гдето до начала 2000 годов, потом как его начали активно ломать по 3 раза на неделе пришлось его заменить, но тот ад и израиль с M4 я досих пор помню:) и "У exim конфиг слишком самобытен и неочевиден." это фигня:) Круче сендмейла у меня только был какой то маршрутизатор NSG, у которого команды были вида буква:цифра 2буквы:цифра, и подробный мануал к нему с етими ка***ми на ~400 страниц:) Так что не все так плохо.

если exim на марсе то тогда sendmail в аду чтоли? просто exim очень гибкий:) настолько гибкий что на его встроенных аклах умудрялись писать реализацию spf когда нативной еще небыло в нем, а за такое приходица платить.

там гдето rewrite должен делаца, но я уже не помню где чем и как, давно в такой позе exim не юзал, но это точно решаемо.

ну вы и нагородили:) решается элементарно exim'om как минимум, (а поидее любым стандартным MTA) - ставите локальный MTA, свои скрипты натравливаете на него, а MTA настраиваете релеить все через нужным вам гугловский акаунт. в дебиане даже тупо менюшкой в консоли при первой установке можно настроить выбрав данный режим работы и вбив туда сервир-login-pass.

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

сип на кошках не айс, нат на кошках тоже не айс, voip+nat опять не айс - так что да - бывает:) да и что вы ей роутить то и натить собрались? этож потоковый шлюз/сервер доступа всетаки, не для этого она.