Text 3831, 269 rader
Skriven 2012-09-11 14:22:36 av mark lewis (1:3634/12.0)
   Kommentar till text 3813 av Robert Bashe (2:2448/44)
Ärende: Pvt nodes vs points
===========================
ml> in your binkd.cfg after the nodes you specifically define and let it
ml> figure out the math? ;)  we did talk about this a few weeks back :)

 RB> Yes, but the problem was that the domain is listed differently in
 RB> various systems. 

how is that a problem??

 RB> Many if not most here add it just after the node number, like in 
 RB> my case:

 RB> ,44,abel.dnsalias.net,Datteln,Robert_Bashe,49-2363-56073,9600,CM,XA
 RB> ,MO,V34,V42B ,V110H,X75,IBN,U,ENC

ok...

 RB> and others use other systms:

 RB> ,290,Wueppel-BBS,Merzenich,Doris_Schmitz,49-2421-981180,9600,MO,CM,
 RB> XA,V32B,V34, X75,IBN:24555,INA:wueppel.doene.de

this one is basically backwards... INA should come before those protocol flags
that are to use the INA named domain... otherwise they are using a previously
determined domain (f.n.z or system name field or previous INA flag)...

 RB> Without even looking hard, I immediately spotted a PVT node in R24
 RB> such as I mentioned earlier, with domain:

 RB> Pvt,434,rr1.dnsart.com,Hagen,Ralf_Remus,-Unpublished-,300,CM,XX,IBN
 RB> ,IEM:ghostri der@ralf-remus.de

nothing wrong there... as mentioned before, PVT on a node with domains
specified is not a private node... there are no private ION nodes... there is
no way to indicate such other than they not having an address in the f.n.z DNS
zone for that domain...

 RB> I have my doubts that any program making an "include" file will
 RB> catch _everything_ like this, 

perl is a wonderful tool... properly written perl is beautiful code to
behold... the tool used to generate the binkd.txt file is written in perl...
the only problem i see with it is that it will list a domain twice if it is
listed twice... it is not a real problem, per se, but it should not write them
if they already exist for that node... this would mainly save on bytes in the
output file... i have a copy of the tool around here and have looked at it with
an eye to fixing this problem but i've not had time to do it yet...

 RB> and anyway, I don't correspond with huge numbers of people. My 
 RB> whole list of nodes I contact directly (with password) may be 
 RB> around 10-15 entries long. I use an "include" list, too, but often 
 RB> have to add a node that hasn't been caught or is new to my own 
 RB> configuration. I don't consider that a great handicap.

ok...

 RB> The only problem comes when I get someone like Bob S., who writes
 RB> with a PVT address with _no_ domain and expects people to guess
 RB> that return mail is supposed to be host routed. 

let's not go there again... it has already been hashed and explained... there
is no domain and there never was... that node does not indicate any kind of
internet connectivity thus there is no reason to expect such... route the mail
to your upstream or the network host and be done with it ;)

 RB> That's confusing here, as we don't have such node systems (or at 
 RB> least no more than maybe 10 in the entire region, and even they 
 RB> can be reached by addressing a reply to a reachable node number). 
 RB> If you already know the situation (as you and others in Z1 
 RB> obviously do), that's no problem, but if you're unfamiliar with 
 RB> it, you can make the kind of mistakes I did with Bob S.

but you shouldn't have made that mistake at all... especially with your time in
the network and historical knowledge of how things work ;)

RB>> As to the f.n.z. conversion, there's been so much shut down in fido
RB>> over the years that I have no idea if that would even work nowadays,
RB>> and here in R24, at least, people include their domain in their
RB>> listing if they're IP-capable.

ml> f.n.z conversion is default in binkd... specifying a domain is an
ml> override, technically... all you have to do is to contact the person
ml> that manages the Z2 DNS zone and ask them to place a CNAME for your
ml> static domain name and your f.n.z will work...

 RB> _More_ hassle, and here I am without any real problems to begin
 RB> with ;-) 

it isn't more hassle... you don't have to do it if you don't want to... it is
provided for more all around and complete service... you can even, believe it
or not, use DNS SVC records to tell the port(s) to use and i think also the
services offered... binkd is the only tool i've even known to use DNS SVC
records ;)

ml>... some of the binkp.net zone managers have set up something so that
ml>RCs can manage the entries in their region... there might even be a
ml>regional DNS zone manager...

 RB> [...]

 RB> Marc, I don't want to insult anyone, 

then please spell my name correctly...

 RB> but all that seems a great effort for very little benefit to me. 
 RB> It would be enough if we could all agree on how and where in the 
 RB> nodelist entry a domain _must_ be listed

that is not required and never has been... it is even moreso not required with
the f.n.z conversion that is default... in fact, with so many folks using binkd
and the f.n.z conversion, it is possible that everything as we know it in
fidonet may turn on its ear due to widespread use... think about that...
quietly...

 RB> and stick to that. The only problem we have now is that the domain 
 RB> is included at various positions and using various flags.

i've always been of the opinion that it the domain and/or IP and/or telco
number was only ever listed in field 6 where the telco number has traditionally
been listed... but this means that there'd have to be multiple entries for the
same system and thus multiple node numbers OR we'd still end up with something
like the INA flag AND we'd still have the f.n.z conversion which has been used
"forever"...

[trim]

ml> that's too much work adding and removing...

 RB> For a total of around 15 nodes (the number that were listed in
 RB> N2448 before I cleared out the deadwood)? Aside from which many of
 RB> them had no IP connection and I had to poll them using a modem or
 RB> ISDN.

 :)

ml> this has already been done for you with the binkd.txt file ;) granted,
ml> a new one hasn't been published in the last few weeks but...

 RB> OK, if I contactedd loads of people on a regular basis, I could see
 RB> the point. But I run a small system with only 8 active nodes in the
 RB> net and a few people I write otherwise. This is not a large system
 RB> like those of the people doing the main mail moving.

but you do maintain the full fidonet nodelist that has each and every fidonet
system listed in it, right? the binkd.txt file is no different... it just only
lists all the IBN nodes and their domains...

ml>> for the f.n.z dns domain format, the binkd guys have set up binkp.net
ml>> since fidonet.net got lost some time back...

RB>> Aha! This is exactly the thing I meant above.

ml> i don't understand "exactly the thing [...] meant above"...

 RB> Look at my comment above:

i did before i wrote that... and now, a few messages later, i have no idea
which comment you were talking about... yes, even after going back and reading
them in another editor while i write this :?

RB>> As to the f.n.z. conversion, there's been so much shut down in fido
RB>> over the years that I have no idea if that would even work
RB>> nowadays...

 RB> You confirmed the problem with your remark. You know about this
 RB> binkp.net. I didn't until now, and how many others (outside R50)
 RB> are familiar with it? 

i don't know but i do make it a practise to turn on and follow the support
echos for the software i use... binkd has just such an echo and all binkd using
systems should be reading it... if nothing else for the 3 section FAQ that's
posted each month... it does get updated with new FAQs and old irrelevant ones
are removed... plus there is some discussion that takes place... and feature
requests... and reports of things not working properly... etc... etc...

RB>> Now, you know this, and it may be common knowledge in Z1, but it's
RB>> the first time I've heard of it and I certainly wouldn't use it
RB>> unless there were really no other way.

ml> one of the binkd guys got fidonet.net years and years ago when their
ml> started working on all of this... the f.n.z conversion stuff was
ml> already being used for years and years before that...

 RB> This is another thing that may well be normal in Z1, but as far as
 RB> I know isn't in R24. I keep mentioning R24 and not Z2 because I
 RB> don't know what is done outside our region and stuff like this
 RB> f.n.z. conversion was never very widespread here, 

i fear you've had blinders on for many years :(  but at least you are now
looking outside your small area and learning what has been going on elsewhere
for a long time :)

 RB> and was mainly - in the late 1990's - used to spread advertising 
 RB> spam into fido. Thankfully, whoever was doing this finally 
 RB> stopped. 

that was spammers beating down the IEEE sponsored gateway... they haven't
stopped it, either... they are the same shits who are still doing it today...

RB>> Please remember, I was doing a count of active nodes. I wrote several
RB>> times in our node echo, polled every node (there weren't that many
RB>> entries anyway) and repeated that with all modes (analog, ISDN and
RB>> IP) I could manage. Practically nobody uses PVT nodes here, and those
RB>> that do mostly include their domain so that the node can be reached.
RB>> There were none in my segment anyway, so the question never arose.

ml> that's fine... i am just saying that you don't need to manually add
ml> them to your binkd connections list if you use the binkd.txt file or
ml> generate your own from the distributed nodelist...

 RB> Which is basically what I do now. But the "include" lists are never
 RB> complete. Not a big deal.

you can always create your own, ya know... the software is available... not
just the perl one but others coded in other languages that may be binary and
thus not easily fixed or enhanced when desired...

RB>> The point was, if their system reacts properly to a poll, it exists.

ml> and what happens if they are on a dynamic connection that was down at
ml> that time you tested?

 RB> I didn't test just once, or only on one day. This went on over a
 RB> period of 7-10 days and at least in R24, no dynamic connection is
 RB> down that long. 

i guess... mine was down for several weeks a while back when a nasty storm came
thru... and then there are those who bounce up and down all the time where it
is quite possible that one may rarely ever get in sync with them for connection
validation... this is one reason why i specifically request that all systems
feeding from me poll me to get their mail... if i cannot deliver something that
may be important, then they need to come get it themselves... hopefully that
will happen while my system is operational, of course :)

ml> were you doing this all at the same specified time?

 RB> No. I just repeated, on various days and times until I was sure
 RB> that either the system wasn't online or was working. Remember,
 RB> these are guys in my local area, up to around Bochum, not sysops in
 RB> some other state or even country. It's not that difficult to tell
 RB> if their system is working or not.

of course telco calls to their voice line should work where you can speak with
them, right? ;)

ml> i'm only pointing out possible problems... heck, my POTS side was down
ml> for a week while i waited on more modems to arrive... at one point i
ml> had it busied out but other times it wasn't...

 RB> Which wouldn't have bothered me, if anything else was working.
 RB> Really, it isn't that difficult to tell if a system is online here.
 RB> Last week, our main mail mover had a problem with his power supply
 RB> burning out and apparently a couple of other things, so he was
 RB> unreachable (I also tried modem and ISDN connections, all "not
 RB> online"). That occasionally happens for a day or so, but after the
 RB> second day, I mailed a couple of other people here in the region
 RB> and asked them to check, too. That's how I found out about the
 RB> problem. It was solved in 2-3 days, and was not a really big deal -
 RB> most of the netmail and echos affected were R24-internal, anyway.

yeah, i know how that goes... i just received a routed netmail the other day
that had been hung up for a month at a mail mover's system... i didn't ask what
the problem was but whatever it was took a month to fix... might have been
waiting on a part to come in or they might have been on vacation or business
and the machine locked up or was turned off... i dunno but the netmail finally
did make it thru the other two hops to my system :)

)\/(ark

 * Origin:  (1:3634/12)