[Dxspider-support] DXSpider mojo branch build 482
Keith Maton
g6nhu at me.com
Fri Jan 20 14:51:57 GMT 2023
Thank you Dirk, I have changed my overnight cron job that searches for updates to run now. All looking good.
DXSpider v1.57 (build 482 git: mojo/33e829e2[r]) using perl v5.28.1 on Linux
For those interested, I can confirm that Net::CIDR::Lite appears to already be installed on Raspbian Bullseye lite. I ran apt install libnet-cidr-lite-perl and it told me it’s already there.
73 Keith
> On 20 Jan 2023, at 14:41, Dirk Koopman via Dxspider-support <dxspider-support at tobit.co.uk> wrote:
>
> There is a new release on the mojo branch.
>
> The main changes that will be of interest are:
>
> 1. There is now a complete implementation of stopping logins from TOR nodes and some other bad IP addresses. I maintain the badip.torexit, badip.torrelay and badip.global files. If you follow the instructions below for your local crontab, you will keep a current set of 'bad ip addresses'. You can also add your own local bad ip addresses with the set/badip command. But if you think this IP address is a problem, tell the support mailing list and I will add it to the 'global' list, which will be distributed around those nodes that download the master lists.
>
> You will need to install Net::CIDR::Lite to utilise the badip stuff.
>
> 2. There is a mechanism for aliasing localhost on client connections and/or other rfc1918 addresses for more complex node arrangements such as web clusters etc. The default arrangement a simple node with one external ip address will "just work" automatically, once it has either connect to another node, or an external user connects.
>
> This means that sshing into a node, running a console and doing a few dx commands will result in the external address appearing in the routing tables locally and externally automatically. If you have a more complex networking arrangement, please get in touch on here (or privately) for advice.
>
> 3. There is a mechanism that uses information from incoming PC92 A records as well as PC61 spots to "upgrade" PC11 spots into PC61s. There is command 'show/spotstats' (or 'sh/spot' for short) that displays some statistics as to how this is all going where you are in the network. Don't be disheartened if you only see a small percentage of upgrades. It depends very much on how many and which nodes that only send PC11 spots you are connected to. I happen to get upwards of 6% on my test machine, but that means there will be that many fewer for some other node to do.
>
> I expect that there will be questions....
>
> 73 Dirk G1TLH
>
> Here is the Changes file:
>
> 20Jan23=======================================================================
> 1. Add the variable @main::localhost_names to allow other IP addresses to
> be treated in the same way as localhost in item 1 on 19Jan23 below. NOTE
> you must include ALL the normal localhost names + any other interface
> names that you might want to include:
>
> set/var @main::localhost_names qw(127.0.0.1 ::1 192.168.1.30)
>
> using the qw() construction is easier than:
>
> set/var @main::localhost_names ('127.0.0.1', '::1', '192.168.1.30')
>
> but either will work. You can define as many IP addresses as you like and
> they can be IPV4 or 6.
>
> You do NOT need to fiddle with this unless you specifically have more
> than just the normal definitions of localhost. So for 'normal' nodes with
> one external interface, you DO NOT NEED TO DO ANY OF THIS.
> 2. Added CTY-3304 prefix data
> 19Jan23=======================================================================
> 1. Introduce aliasing for localhost in DX Spots and outgoing PC92 A records
> on login. There are two variables which can be set with the alias to use:
> $main::localhost_alias_ipv4
> $main::localhost_alias_ipv6
> These can be set in the /spider/scripts/startup, but this is only
> necessary if the node has more than one interface, or virtual hosts. If
> there is ONLY ONE ipv4 and/or ipv6 IP address on the node machine then
> these variables will be automatically populated on first use. But the SAFE
> thing to do is to set them in the startup file.
>
> THIS FEATURE IS EXPERIMENTAL...
> 18Jan23=======================================================================
> 1. Make sure than *every* channel has an IP address. Thank you (I think) Kin
> for pointing out that PC92 A records were not going out with IP addresses.
> I'm guessing that other things (like spots) had a similar problem.
> 15Jan23=======================================================================
> 1. Fix strange errors for carp on missing route_*_cache files on startup.
> 14Jan23=======================================================================
> 1. Fixed route PC11 promotions so that a new PC61 is actually generated and
> also sent instead of the original PC11 (to PC61 capable nodes).
> 13Jan23=======================================================================
> 1. Periodically store Routing tables and, if they are young enough (def: 3hrs)
> autotically restore them on restart of the node. This will short circuit
> the need to rebuild the routing tables from scratch on every restart -
> which is normally for something like software update.
> 2. Fix pc11 debugging stats with the correct figures. Sigh... Also move some
> of the totals to a different place.
> 3. Add show/spotstats command which gives the current spot statistics shown
> during pc11 debugging (which means you don't need to set/deb pc11 unless
> you really want that extra noise).
> 12Jan23=======================================================================
> 1. Regularise 'set/debug pc11' output to track all the routes through PC11 and
> PC61 processing and statistics.
> 11Jan23=======================================================================
> 1. Improve (?) the PC11 -> PC61 upgrading process that delays incoming PC11s
> for a very short time in the hope that a PC61 will come in to be used
> instead. It will also upgrade a PC11 if we have an uptodate IP address
> that has come in from the routing system PC92s. do a 'set/debug pc11' to
> see it in action.
> 2. I have chosen a definitive list of TOR exits and relays which can be
> downloaded from http://www.dxspider.net/download/badip.torexit,
> http://www.dxspider.net/download/badip.torrelay and finally, for those IP
> addresses that are deemed to be 'bad':
> http://www.dxspider.net/download/badip.global. I have added the following
> lines to my /spider/local_cmd/crontab:
>
> 24 * * * * spawn('cd /spider/local_data; wget -qN http://www.dxspider.net/download/badip.torexit')
> 24 * * * * spawn('cd /spider/local_data; wget -qN http://www.dxspider.net/download/badip.torrelay')
> 24 * * * * spawn('cd /spider/local_data; wget -qN http://www.dxspider.net/download/badip.global')
> 25 * * * * run_cmd('load/badip')
>
> The tor files are downloaded from https://lists.fissionrelays.net/tor/ at
> 15 minutes past every hour, please would you use some other minute than
> 23 or 24 to get your own local copies.
>
> A 'set/debug badip' will show you what is being blocked.
> 3. Fix set/badip so that it appends new IP addresses correctly.
> 10Jan23=======================================================================
> 1. Add baddx on incoming callsign in RBN.
> 2. Search for all /spider/local_data/badip.* files to allow more control on
> which IP addresses are detected. e.g. badip.torexit, badip.torrelay as well
> as baddx.local. The suffixes, apart from .local (created by set/badip) are
> completely arbitrary. You can use whichever suffix name you like. This is
> a more useful arrangement for the ever increasing sources of "bad ip
> addresses" that we need to deter.
>
> NOTE: all badip.<suffix> are read only EXCEPT badip.local (which can be
> altered in real time by the sysop using set/badip <ip address> ...).
> If one uses periodic crontab jobs to update any other badip.<suffix>
> files from web resources then don't forget to 'load/badip' afterwards.
> 3. Add a /spider/data/baddx.issue file which can be copied to (or used as a
> basis to create) /spider/local_data/baddx
> 09Jan23=======================================================================
> 1. Finish implemention of DXCIDR ip address filtering. This works on both
> logins (treated the same as locked out - i.e. just disconnected) and also
> with PC61s where these sentences are just dropped. Also attempt to prevent
> any *following* PC11s with the same data getting through.
>
> YOU WILL NEED either 'cpanm Net::CIDR::Lite' or debian/ubuntu based distros
> 'apt install libnet-cidr-lite-perl'. RedHat based systems will have similar
> packages available.
>
> 2. Recognise PC18s coming from CC Clusters more nicely.
> 04Jan23=======================================================================
> 1. Fillout DXCIDR, attach checks in PC61 and logins. Login that fail will
> simply disconnect, like locked out callsigns
> 2. Fix qrz.com URL in stock Internet.pm.
> 3. Fix DXHash issues (baddx, badnode, badspotter etc)
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20230120/399bb178/attachment-0001.htm>
More information about the Dxspider-support
mailing list