[Dxspider-support] New mojo release

Luigi Carlotto IK5ZUK ik5zuk at tiscali.it
Wed Jan 5 20:28:28 GMT 2022


Hi Dirk,

Thank you very much for your prompt reaction.
It seems curing and working perfectly, so the locked out user's number 
is now significantly reduced.

In less than 24 hours you solved a very big problem !

73 | HNY

Luigi, IK5ZUK




Il 05/01/2022 20:11, Dirk Koopman via Dxspider-support ha scritto:
> There is a new version of the mojo branch out (build 402). There are 
> some important changes to do with cleaning up the users file and 
> routing tables that you should look at. Details are in the Changes 
> file, an extract of which I enclose below:
>
> 05Jan22=======================================================================
> 1. Mark nodes that send PC92 K records as spider. These will include VE7CC
>    nodes. NOTE: there appear to be user records marked as user or 
> other sorts
>    of node, which (now) are actually spider (compatible) nodes and will be
>    marked accordingly.
> 2. Adjust nodes currently marked as spider nodes, but are sending versions
>    not in the spider range of versions on PC92 A records as AK1A.
> 3. Try to undo some damage where users have been autocreated with similar
>    attributes as nodes (locked out with privilege set to 1). This will
>    slowly fix this problem over time, but see item 4 for a 'big bang'
>    approach.
> 4. It has come to my attention that there are a large number of users (of
>    all sorts) that have incompatible SSIDs. See 03Jan22/4 for details.
>
>    These are now being scrubbed out of the users file and also will 
> present
>    as their normalised selves. If a -0* SSID is encountered then, if the
>    normalised version of that call is not present, it will be renamed to
>    that normalised call. If the normalised version of that user record is
>    already present, the un-normalised user record (-0*) will be removed.
> 5. Make export_users do a batch clean (as in 3. above) and also get rid of
>    (default) 12+ year old unaccessed user records and (default) 2+ 
> year old
>    "empty" records (with no qra/latlog/qth or handle).
>
>    NOTE: if you do an manual export_users (as opposed to the automatic one
>    done once a week), do not be alarmed by the number of old (i.e. 
> more than
>    12 years old) callsigns that it will get rid of. In my case it was 
> about
>    ~2/5th of the users file. Still left me with over 100,000 "active" 
> users.
>
>    In you are a bit twitchy about this, the code will copy the current
>    user_json and user_json.ooooo to user_json.keep and user_json.backstop
>    respectively. These files will never be overwritten unless you 
> remove one
>    or both, when they will be regenerated on the next export_user.
> 04Jan22=======================================================================
> 1. Fix issue in the RBN (and probably other places) with callsigns that
>    contain trailing / in callsigns like: OH0K/6, K2PO/7 etc.
> 2. Regard strange callsigns like DR4W-HB (seen in skimmer spots) as 
> invalid.
>    This *should be* something like HB9/DR4W or (spit) DR4W/HB9.
> 3. Fix the (probably) spurious locking out of users that are unknown 
> to this
>    node, that come in from other nodes. These create new user records 
> which
>    where then automatically locked.
> 03Jan22=======================================================================
> 1. Allow overrides (on modern versions of perl) with things in 
> DXVars.pm, such
>    $clusterport. This is really only of use for people trying to run 
> more than
>    one instance of DXSpider on the same machine.
> 2. Fix who command to make RBN connections as RBN and not USER.
> 3. Prevent other nodes claiming that $myalias or $mycall is a 
> different type
>    (user or node) from changing our route table and thence the user type.
> 4. Normalise callsigns of incoming connections to G1TST if G1TST-0 or 
> G1TST-00
>    amd G1TST-2 if G1TST-02. There are 800+ instances of callsigns with 
> extra
>    0 characters in the SSID in my users file. Allow SSIDs up to 99.
>
> NOTE: I am only enclosing the earlier changes because there are 
> mentions in the 05Jan22 changes.
>
> You will not affect the size of the users.v3j file with this update 
> and after doing an export_user (manually or automaticaly once a week). 
> But if you want to reduce the size of your user.v3j file because of 
> the large clearout of old or spurious SSID'd callsigns then you can do 
> this by:
>
> 1. Do an manual 'export_user' in the console.
> 2. Stop the node.
> 3. cd /spider/local_data; perl user_json
> 4. Start the node.
>
> This will *significantly* reduce the size of the users.v3j file. And 
> remember: an export_user will create two unchanging copies of the 
> latest and oldest versions of user_json. If in doubt, you can recreate 
> what you had before doing the export_user at any time.
>
> Please send all your brickbats to the usual email address.
>
> 73+HNY Dirk G1TLH
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support


-- 
Questa email è stata esaminata alla ricerca di virus da AVG.
http://www.avg.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20220105/0a552dca/attachment.htm>


More information about the Dxspider-support mailing list