[Dxspider-support] Some network data

Tue Feb 21 10:36:00 GMT 2023

Hi Howard,

No, I don't have a lot of time, but when I do a job I am 100% committed, one flaw as another hihihi.
At no time was my intention *got dinged* for not being up to date, I didn't even think of such a thing, I'm peaceful.

I who have a node with between 10/20 users also value the availability of the service, as my goal is 24x7x365, and I think I achieve it. 
When I do an update, my users lose service for about 3 seconds, which is how long it takes for my node to go from down to up. And if the new build fails, in 5 more seconds they are all working with the previous one, in the worst case I could say it's 10 seconds of disconnection. I don't think my users will ever appreciate this outage.
As I also manage the EA4URE cluster, where there are a lot more users, I can say that *NEVER* the traffic is interrupted by spider updates, why? because EA4URE is in high availability, which allows to have several nodes in load sharing, being able to update one of them without affecting beyond an immediate disconnection/connection of users.

As a system administrator for a long time, I have to admit Howard that updates are always worrying, but waiting for others to do the testing does not guarantee our own success: different scenarios, probably different results. By this I don't mean that I'm a proponent of always running the latest build, because by reading the Changes file I can see if it's i.e. a fix for Windows or something else, which I evaluate and decide to do.

How many different sysops have reported abuses on this list? How many have taken the action that Dirk has proposed?

I don't think you have been able to read all the comments on the list, because as you said you are busy. I can tell you that I sent an email to 80% of the sysops informing them of what is happening on the network and asking for their cooperation. I have received all kinds of replies, for which I am very grateful. Others have simply answered NOTHING - they were not obliged to - and others have simply got the wrong email. So it hasn't been as simple as just putting up a list and having it *shoot* to the nodes either. For example, I remember sending you an email requesting the blocking of some nodes, but I must have got the email wrong.

I think there are neither guilty nor innocent here, there are sysops who manage and sysops who don't, the reasons are diverse, but that is a reality that affects us all. And as I said a few days ago, joining a node to the network entails a responsibility because it can affect other nodes, so we have to assess whether we are willing to *play as a team* or not. This list is a great place for questions and clarifications, help and advice.

Developers of software for dxclusters know - or should know - that modifications, improvements and changes are made, and they, who add value by connecting to dxclusters, should not be surprised that passwords are used. For example, N1MM has received several requests to integrate it into their software, we are still waiting.
If this change or any other change depends on those client developers deciding whether or not to implement it, this is where the future ends.

One thing we agree on Howard: I'm not a fan of change for change's sake either. The changes proposed so far have been published for discussion, seeking collective improvement and not immobilism.

I am making my reply public because I believe there is still a lack of constructive debate.

Excuse my English.

73 de Kin EA3CV

-----Mensaje original-----
De: Dxspider-support <dxspider-support-bounces at tobit.co.uk> En nombre de Howard Leadmon via Dxspider-support
Enviado el: lunes, 20 de febrero de 2023 23:18
Para: dxspider-support at tobit.co.uk
CC: Howard Leadmon <howard at leadmon.net>
Asunto: Re: [Dxspider-support] Some network data

   I have stayed out of most of this, and to be honest I am pretty much to darn busy to be in the middle of this on a day to day basis. Apparently Kin has a lot of time to put into this at the moment, and that's great, not all of us do, and I fit that category.   As I run a hosting facility, I do make sure the node is very highly available and as close to 100% uptime as is possible.

  That said, I did add in the routines to update and track the bad spotter lists, but I also have zero desire to run around setting lockouts and such just because someone is behind a little.  I keep
WB3FFV-2 fairly current, at Mojo 497 currently, but when I dipped a version behind for a few, I got dinged by Kin for not being current.   I value uptime and stability over making sure I track every little revision change, as many running the various ham software stay connected
24/7 all the time, hundreds of users, so why keep kicking them off. Also at times stability or bugs are found in a new release, so shy of a big security fix, why jump the second something comes out.

  So I have to say, creating a list, and then just locking sites out due to this list someone decided to make, is a sledgehammer approach.  If we have a node we know is being abused, we know bad spots are going out from, then sure set a lockout so the op can be informed of the issue, and why this temp lockout was set.

  Also as Mike mentioned, for sure we are shooting total innocents on this, as not everyone follows everything going on with this list, so people just find out the hard way they have been blocked.   As easy as it is to setup a node, I would not be surprised if some of them are little Pi's for personal use by the op,  and maybe a few other hams, it's that easy to do.

 From a different email thread, but I wanted to mention it.  I have always enforced registration to post spots, but do not enforce passwords and at this point and don't currently plan too.   I don't believe we have had any issues with my node, and I know the author of the N3FJP contest software, and it has issues with passwords, so enforcing passwords at this point without notice would break some really popular software that is in use.  I am not a fan of going out of our way to break the network, and it seems this has been done for some recently.

  So in conclusion, I will again agree with Mike, and say that we have been implementing improvements, so not sit back and see how much trouble we still have, and what is required to solve any glaring problems. Hopefully what has already been done, will have greatly improved the situation..

73's...

---
Howard Leadmon - WB3FFV
PBW Communications, LLC
http://www.pbwcomm.com

On 2/20/2023 2:53 PM, Mike McCarthy, W1NR via Dxspider-support wrote:
>
>
> On 2/20/2023 2:16 PM, Kin via Dxspider-support wrote:
>
>> I think that the execution of the lock request is not being so 
>> traumatic. It is clear who has not participated in any way.
>>
>> I ask you, what do you think the next step should be?
>>
>> Kin EA3CV
>
> Dirk may clarify this but if an outdated node has one link to an 
> updated node, any bad spots originating from that old node should get 
> dropped by the updated partner's filtering and not propagate any 
> further. Correct?
>
> I still say that blindly disconnecting and locking out older nodes is 
> an authoritarian sledgehammer approach and really isn't necessary if 
> the majority are up to date.
>
> Also, 3 of my partner nodes who were on your block list whom you claim 
> could not be contacted were contacted directly by me and were unaware 
> of this whole thing.
>
> Let's now just stop and observe how and if what we have is working.
>
> Mike, W1NR
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support

_______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk
https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support