r46.sysop

Привет, Andrei! 26 Дек 18 09:00, ты писал(а) Stas Mishchenkov: SM>> == SM>> ========== Дек 25 1983. Том Дженнингс начал работу над Fidonet. SM>> Точная дата неизвестна, во всех источниках упоминается, что это SM>> случилось "около Рождества 1983". SM>> Поздравляю. AM> Опять нет повода не выпить (с) Жаль, мне сейчас низзя... Можно и пепси колой замочить, это не проблема. :) Yuriy

Hello Michiel! 11 Nov 18 13:43, you wrote to all: MV> 13:15 [3144] creating a poll for 2:467/239@fidonet (`d' flavour) MV> 13:15 [3144] clientmgr started MV> + 13:15 [3612] call to 2:467/239@fidonet MV> 13:15 [3612] trying fido.redcat.link [213.231.2.214]... MV> ? 13:15 [3612] connection to 2:467/239@fidonet failed: {W32 API error MV> 10061} Connection refused MV> + 13:15 [3612] holding 2:467/239@fidonet (2018/11/11 14:15:45) MV> 13:15 [3144] the queue is empty, quitting... Recently, the node is working again. fido.redcat.link / 45.32.234.106 / 2001:470:1f15:c3c:f1d0:2:467:239. Mykhailo

Hello *Alexey.* Sunday 02 December 2018 01:40, Alexey Vissarionov wrote to Yury Roschupkin: AV> А вообще дурь все это... Ибо https://google.com/search?q=vps+1eur для AV> хоста достаточно чуть более, чем по уши, и сумма для damned hobby AV> вполне подъемная. аруба больше не дает за эти деньги, а жаль. :-(

Доброго времени суток, Yury! 02 Dec 2018 00:08:06, ты -> мне: SM>>> Вот здесь выиграет система из нескольких узлов, даже если они не SM>>> будут синхронизировать аутбаунд. AV>> Если есть желание сделать действительно надежно, нужно на каждого из AV>> добровольцев навешивать не более одного-двух хостов. А еще выдавать AV>> им технические aka в поддерживаемых сетях. YR> А разве 2:46хх/0 будет недостаточно? Для работы достаточно (хотя и коряво), а вот раздражать деда лучше не надо. А вообще дурь все это... Ибо https://google.com/search?q=vps+1eur для хоста достаточно чуть более, чем по уши, и сумма для damned hobby вполне подъемная. -- Alexey V. Vissarionov aka Gremlin from Kremlin gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii ... Безумству храбрых - минута молчания

Hi! 01 дек 18 15:58, Stas Mishchenkov -> Yury Roschupkin YR>> Мы как-то недообсуждали вопрос о принципах функционирования YR>> внешнего хоста сети (там, где он нужен). Высказано два подхода: YR>> виртуальный распределенный ip-хост на общем домене или физическое YR>> перенесение хоста на отдельный узел(хаб) за пределами сети. В YR>> каждом пути есть плюсы и минусы. Я вот пока для себя не YR>> определился, что лучше для региона. Хотелось бы услышать больше YR>> мнений/аргументов. SM> Hу, проще всего вписать твой узел в качестве хоста для таких сетей... Только если их мало. И помнить о spof... -+- WBR, YuR

*** Правила конференции *** R46.SYSOP 14.06.2016 Конференция R46.SYSOP является основной конференцией системных операторов узлов 46-го региона 2-й зоны сети FidoNet. В эхоконференции разрешается обсуждение любых тем, относящихся к работе сетей региона, региона и FidoNet в целом. Исключение составляют темы, для обсуждения которых существуют специализированные тематические конференции. Данная конференция настоятельно рекомендуется к получению всеми узлами 46-го региона. Официальная информация, помещенная в конференцию, считается доведенной до всех сисопов региона. В конференцию также могут писать сисопы других регионов сети FidoNet на технические темы, имеющие отношение к региону 46. Поинты и пользователи ббс не вправе писать в данную конференцию без специального разрешение модератора. Тем не менее, для решения технических проблем любой сисоп региона 46 может написать в эху, используя любой поинтовый адрес,при условии указания в кладжах или тексте письма своего нодового адреса. При написании писем запрещается использовать псевдонимы. В поле "From" письма должно содержаться либо _нодлистовое_ имя сисопа, либо название официальной должности ( например R46C, R46PK, N46??C и.т.п.) либо иная информация, однозначно идентифицируящая _сисопа_. Для написания писем в конференцию может быть использован русский, украинский, молдавский и английский язык. Отвечать на письмо рекомен- дуется на том же языке, на котором было написано оригинальное письмо. В конференции запрещаются: * флейм, оскорбления и нецензурные выражения * переписка с модератором, обсуждение политики модерирования и само- вольное модерирование * злоупотребление личной перепиской * обсуждение политики и национальных отношений. В зависимости от обстановки в конференции, любая тема временно или постоянно может быть объявлена модератором офтопиком. В случае нарушения подписчиком правил, модератор выносит ему предупреждение. Система предупреждений стандартная [*][+][!], в зави- симости от тяжести нарушения. Тяжесть нарушения определяется модера- тором. Как правило,"награды" суммируются ( например [+]+[+]+[+]=[!] ), Однако в случае особо злостного нарушения модератор может сразу приме- нить более серьезное наказание, вплоть до перевода в Read-Only. Модератором конференции всегда является действующий R46C. Модератор может назначать себе помощников - комодераторов, которые обладают всеми правами модератора,за исключением изменения правила эхи и назначения комодераторов. Решение комодератора может быть обжаловано перед модератором. Действующий модератор конференции : Yury Roschupkin (2:46/0) Другие адреса модератора: 2:466/50, 2:466/55, 2:466/46б, 2:466/50.1 Комодераторы: отсутствуют. /При раработке данных Правил использованы элементы из Правил конференции R50.SYSOP/

Hi! 18 ноя 18 22:27, Pavel Gulchouck -> Yury Roschupkin [...] YR>> У нас в строке Region с 2011 года стоит флаг DO4:binkp.net. Он YR>> незаконный, его надо удалить? PG> Формально - да, незаконный. Hо это user-flag. PG> Пока чекалка Варда его пропускает и софт поддерживает, кажется, что он PG> никому не создаёт проблем, а иногда удобен, поэтому я бы оставил. Значит, пока оставляем. PG>>> 3. В сети есть NC, но нет хоста. PG>>> Узел NC является pvt или по какой-то другой причине не может PG>>> выполнять функции хоста. В такой ситуации на мой взгляд хост PG>>> вполне может быть удалённый (не принадлежащий узлу сети) и PG>>> IP-only, например, жить на ноде RC или на любом региональном PG>>> netmail-хабе. YR>> Хотелось бы все же услышать о технической стороне вопроса. YR>> Виртуальный хост в том виде как было чуть ранее рассказано - YR>> имеет смысл? Если да, то как проще сделать? Или считаешь, что YR>> хабы должны просто поделить между собой сети, в которых они YR>> станут внешними хостами? PG> Hу... Сейчас моя работа непосредственно связана с созданием PG> распределённых систем без единой точки отказа, балансировкой нагрузки PG> и подобными задачами. И вот мне кажется, что в данном случае это не PG> нужно, виртуализация хоста на нескольких хабах даст больше проблем, PG> чем пользы, и в итоге приведёт к снижению надёжности. За счёт PG> усложнения системы без мониторинга работы её составных частей. В PG> случае, если в роли хоста сети выступает один узел, то когда он PG> отвалился, это сразу стало заметно, и перенесли хост на другой узел, PG> это просто и быстро. А вот если на адрес хоста отвечает несколько PG> узлов, то падение тоссера на одном из них приведёт к пропаданию части PG> почты и останется незаметным. Кроме того, при неаккуратной настройке PG> это может привести к проблемам связи между этими узлами (если PG> удалённый узел предъявит виртуальный AKA) или даже к хождению между PG> ними эхопочты (если адрес хоста попадёт в path или seen-by). Hу то есть это то, о чем написано в последнем предложении моей квоты - внешние хосты на хабах. PG> С другой стороны, у нас не продуктовая система, где нужно оценивать PG> выгоду от затраченного времени. Если создать виртуальный хост на PG> нескольких узлах интересно - why not? :) Hе, я за простоту реализации и надежность. Пожалуй, я слишком увлекся идеей распределенного хоста и в упор не видел то, что под носом. ;) Впрочем, если кому-то "виртуальный хост" будет интересен именно в том виде и он сможет сделать надежное решение, то такое имеет право на существование. Осталось узнать еще мнение Стаса, т.к. он тоже собирался в нем участвовать. [...] PG> Я вместо этого предлагаю добавить техническую строку "Host,4699", PG> которая не будет влиять ни на что, кроме адреса узла Harry: PG> Region,46,...,Yury_Roschupkin PG> Host,4699,...,Yury_Roschupkin PG> ,123,...,Harry_Potter PG> Почту для его узла по-прежнему будет доставлять RC самостоятельно или PG> через третий узел, правки в нодлистовую строку Harry он тоже будет PG> вносить сам, и с возможными конфликтами тоже будет разбираться сам PG> (количество уровней апелляции не меняется). Вариант, когда РЦ - всеобщий запасной HЦ для региона. Hу и внешний хост зачастую. РЦ ушел в астрал - с ним полрегиона или больше. -+- WBR, YuR

Hi Stas! 18 Nov 18, Stas Mishchenkov ==> Pavel Gulchouck: PG>> убрал, а вместо этого напрочь запретил использовать в нодлисте имена, PG>> в которых каким-либо образом просматривается исходный фидошный адрес. SM> Вот, мне тоже совершенно не понятно, как это может влиять на связность сети. PG>> текущим стандартам". И вместо "DO4:binkp.net" нужно указать PG>> "INA:f0.n4635.z2.binkp.net", хотя и это Виссарионов может объявить PG>> нарушением FTS его авторства. SM> Что значит может? Так и есть. Сейчас вот это "каким-либо образом просматривается исходный фидошный адрес" в стандарте не закреплено, это было лишь в виде авторской трактовки. :) Стандартом запрещено указывать в нодлисте адреса из DDN. Оно и понятно: в этом случае получается бесконечная рекурсия. Но binkp.net не является DDN, хотя и похож на него по некоторым признаком, так что формального нарушения тут нет, как и технических проблем. PG>> а потому склонен смириться и заменить DO4:binkp.net на PG>> INA:f0.n4635.z2.binkp.net (и в других подобных случаях аналогично). SM> Ксожалению в теперешней ситуации это тоже не соответствует стандарту и в нодлисте нужно публиковать какой-то другой домен. Нет, всё не настолько плохо. Да и Michiel van der Vlist, из-за чекалки которого начался этот разговор, советует именно такое решение. Lucky carrier, Паша aka gul@gul.kiev.ua

Доброго времени суток, Yury! 18 Nov 2018 18:34:34, ты -> Pavel Gulchouck: PG>> Административно это будет как перенос узлов сети под регион, а PG>> технически адреса будут сохранены путём добавления технической PG>> строки "Host", дублирующей содержимое строки "Region". YR> Т.е. список узлов в сегменте "под регионом" и такой же как сеть? YR> Вроде выглядит как-то не очень... Может, лучше просто договориться YR> с любым из сисопов, что ему чисто формально поставим флаг NC, а YR> фактически сегмент будет вести RC и хост - внешний?.. Разумеется, лучше. Более того, полностью соответствует FPD: NC в этом случае делегирует кому-то (хорошо бы хабу из своей сети) функции хоста, еще кого-то назначает нодмейкером, а сам обеспечивает общее руководство и рассматривает комплейны. -- Alexey V. Vissarionov aka Gremlin from Kremlin gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii ... Чем меньше вы знаете, тем больше я зарабатываю

Hi! 18 ноя 18 15:44, Pavel Gulchouck -> Yury Roschupkin [...] PG> Hi Yury! YR>> Каждый HЦ, отозвавшийся на мой клич, может сразу заявить, если YR>> нужна услуга виртуального хоста. YR>> Пока всё. Жду откликов HЦ. Hу и тех, кому есть что сказать YR>> важного. ;) PG> Тут есть сразу несколько проблем, которые я бы предложил рассматривать PG> по отдельности. PG> 1. Узлы, у которых не указан способ связи, или указан устаревшим PG> способом (флагом DOM). Информацию про них просто нужно привести в PG> соответствие с нынешними стандартами, чтобы чекалка не ругалась. У нас в строке Region с 2011 года стоит флаг DO4:binkp.net. Он незаконный, его надо удалить? PG> 2. NC PG> не актуализирует сегмент или вообще ушёл в астрал. В частности, не PG> удаляет дохлые ноды и не ставит Pvt узлам, которые работают, но с PG> которыми нет общедоступного способа связи. Hужно теребить NC или PG> назначать другого, это забота RC. Тут очевидно. PG> 3. В сети есть NC, но нет хоста. PG> Узел NC является pvt или по какой-то другой причине не может выполнять PG> функции хоста. В такой ситуации на мой взгляд хост вполне может быть PG> удалённый (не принадлежащий узлу сети) и IP-only, например, жить на PG> ноде RC или на любом региональном netmail-хабе. Хотелось бы все же услышать о технической стороне вопроса. Виртуальный хост в том виде как было чуть ранее рассказано - имеет смысл? Если да, то как проще сделать? Или считаешь, что хабы должны просто поделить между собой сети, в которых они станут внешними хостами? PG> 4. В сети есть живые PG> ноды, но среди них нет тех, кто согласен выполнять функции NC (в PG> частности, вести сетевой сегмент). Расформирование сети скорее всего PG> приведёт к уходу из fido оставшихся узлов, потому что сисопы за много PG> лет привыкли к своим адресам и менять их вряд ли согласятся. Считаю, PG> что в таких случаях функции NC вполне могут перейти к RC. PG> Административно это будет как перенос узлов сети под регион, а PG> технически адреса будут сохранены путём добавления технической строки PG> "Host", дублирующей содержимое строки "Region". Т.е. список узлов в сегменте "под регионом" и такой же как сеть? Вроде выглядит как-то не очень... Может, лучше просто договориться с любым из сисопов, что ему чисто формально поставим флаг NC, а фактически сегмент будет вести RC и хост - внешний?.. -+- WBR, YuR