[Dxspider-support] DXSpider mojo branch build 482

Fri Jan 20 18:11:39 GMT 2023

Done.

IZ5FSA-6> sh/ver
DXSpider v1.57 (build 483 git: mojo/7e7131f35[r]) using perl v5.32.1 on Linux
Copyright (c) 1998-2023 Dirk Koopman G1TLH
IZ5FSA-6>

Il 20/01/2023 15:41, Dirk Koopman via Dxspider-support ha scritto:
> 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/2f62c9bb/attachment.htm>