= Сообщение: 11277 из 12518 ===================================== ENET.SYSOP = От : Ulrich Schroeter 2:240/1120 21 Feb 22 07:59:42 Кому : Matthias Hertzog 21 Feb 22 07:59:42 Тема : Migration review 2:301/1 FGHI : area://ENET.SYSOP?msgid=2:240/1120@fidonet+621350b4 На : area://ENET.SYSOP?msgid=2:301/101+62127534 = Кодировка сообщения определена как: CP866 ================================== ============================================================================== moin Matthias,
Sunday February 20 2022 17:55, you wrote to All:
MH> Hi there! MH> The migration went through like it was planned. We changed the IP MH> address behind the existing hostname entry and minutes later, the MH> first connections went to the new system. That worked for a lot of MH> systems, but not for all of them.
MH> To facilitate possible future migrations, i'd like to discuss that. MH> These are the errors i've noticed:
MH> - Some systems still connect to the old system, even if the DNS end MH> the nodelist entry points to the correct destination. Why is that, MH> that these systems seem to have been configured to ignore the nodelist MH> and connect to what ever was configured? What's the benefit of a MH> nodelist when the content is not used?
think off a static definition in binkd.config (!)
binkd.config doesn't use the raw st.louis nodelist ... instead Binkd make use of static node aka ip-address-or-fqdn password flavour configurations
I've also included a binkd-style nodelist for the rest of unknown nodes, not yet connected to my system. so here, the automatic change of dnsnames in the nodelist gets compiled with a binkd-nodelist compiler and makes it into the real binkd configuration (dynamic input of include binkd-style-nodelist-compiled file)
so my binkd.config lists following fixed, static entries to your system until you've announced, that 2:301/1 will change in the next days ...
node 2:30/0 fidonet.services.hertzog.ch ourpwd c node 2:301/0 fidonet.services.hertzog.ch ourpwd c node 2:301/1 fidonet.services.hertzog.ch ourpwd c node 2:301/101 fidonet.services.hertzog.ch ourpwd c node 39:11/0 fidonet.services.hertzog.ch ourpwd c node 39:110/0 fidonet.services.hertzog.ch ourpwd c node 39:110/101 fidonet.services.hertzog.ch ourpwd c
so if you had not announced the switch a couple of days before, the call to 2:301/1 still would go to fidonet.services.hertzog.ch
but I've was prepared and I've seperated the 2:301/1 line in my binkd.config as static entry to
# CH backbone Alisha on the move Herzog -> Alisha 14.2.2022 node 2:301/1 fnthub.abad1dea.to ourpwd c #node 2:301/113 fnthub.abad1dea.to ourpwd c
so the 2:301/1 did work before the switch and worked after the switch as before the switch
fidonet.services.hertzog.ch and fnthub.abad1dea.to points to the same IP address and after the move both fqdns resolves to two different IP addresses
so my current static config lists:
# CH backbone Alisha on the move Herzog -> Alisha 14.2.2022 node 2:301/1 fnthub.abad1dea.to ourpwd c #node 2:301/113 fnthub.abad1dea.to ourpwd c
node 2:30/0 fidonet.services.hertzog.ch ourpwd c node 2:301/0 fidonet.services.hertzog.ch ourpwd c node 2:301/101 fidonet.services.hertzog.ch ourpwd c
node 39:11/0 fidonet.services.hertzog.ch ourpwd c node 39:110/0 fidonet.services.hertzog.ch ourpwd c node 39:110/101 fidonet.services.hertzog.ch ourpwd c
Now rethink ... not all sysops received your announcement 3 or 4 or 5 days before the move yet, 'cause they've still have not read it ... 'cause they are away from keyboard ... or on the other side of the moon or somewhere else ... for those who read your mail probably made the changes to their static binkd.config before hand, some on the next day so for those, the switch did go smoothly ... but still my tosser config points for aka 2:301/1 to Matthias Hertzog instead of Alisha ... the same goes for the Ticker config as these settings are hardcoded into the config once we've established our connection
The dynamic / static binkd.config with node configurations works like:
# dynamic records, binkd-nodelist compiled every week from raw st.louis nodelist -> binkd.txt # with records without configured session passwords include binkd.txt
# followed by static record with static FQDNs and static session passwords # duplicate records overwrites the records from binkd.txt from above
# CH backbone Alisha on the move Herzog -> Alisha 14.2.2022 node 2:301/1 fnthub.abad1dea.to ourpwd c #node 2:301/113 fnthub.abad1dea.to ourpwd c
node 2:30/0 fidonet.services.hertzog.ch ourpwd c node 2:301/0 fidonet.services.hertzog.ch ourpwd c node 2:301/101 fidonet.services.hertzog.ch ourpwd c
so what ever record for 2:301/1 is listed dynamicly in binkd.txt it gets overwritten by my static record in my binkd.config
MH> - Some of these systems who connect to the old system, send me the MH> PKTs for 2:301/1, even when i'm NOT presenting that address in my MH> Bink. Makes no sense to me, especially not from a security MH> perspective. The mailer should only send PKTs to a destination system MH> if the desired address is presented by the receiving system & the MH> session password matches.
MH> I've noticed some of these systems are running D'Bridge. Were these MH> issues ever discussed and/or adresseed? Or are these simply sysop's MH> errors?
no software error, no sysop error ... this problem is by design ...
each link has to activly update the connection infos to your, now to Alisha's system with the new data in whatever config ... If this re-configuration has not been done yet, it takes some more time for the sysop to enter his link configuration changes
MH> Best wishes & have a nice evening, MH> Matthias
MH> BTW: The actual cleanup (netmailing affected sysops) takes much more MH> time than the migration took.
I did such a migration back in 1999 with a hub switch with approx 100 links I've informed the downlinks weeks before, notified every week about the proposed date and the final switch did it on a weekend I've managed all 100 links remotely ...
sending prepared areafix requests to my areamanager and ticker manager for each link including request for currently linked echo- and fileareas converted these requests and results into a 2nd set of requests to the new switched system to enable the identical configuration on the 2nd system. the last action was a message to the link: "the switch did happen now" this was the notification to all links, that they could start reconfigure their systems with new connection infos sent before.
The 2nd switch I've managed was in 2013 ... a complete net shift from 2:244/* to 2:240/* We've discussed long beforehand in the net, started an election and finaly moved from net 2:244 to 2:240 at 8th Nov 2013 after one week before the new nodelist segment didn't got it into the weekly nodelist. Here the transfer took approx 2 weeks until the last one changed his configuration to the new net configuration.
