[Dxspider-support] DXSpider mojo branch build 482
Luigi Carlotto IK5ZUK
ik5zuk at tiscali.it
Fri Jan 20 15:47:57 GMT 2023
Hi Dirk,
on the new v1.57 build 482 I've seen set/badip and sh/badip, but it's
missing the unset/badip (just in case of typo or something else)... Are
you planning to add this command later ?
73 Luigi IK5ZUK
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/5b8b5ae6/attachment.htm>
More information about the Dxspider-support
mailing list