[Dxspider-support] New mojo release

IZ5FSA iz5fsa at gmail.com
Wed Jan 5 20:26:59 GMT 2022


The users.v3j export and update ,ust be done after update or before?

73 de Leo IZ5FSA


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20220105/387b0fcc/attachment-0001.htm>


More information about the Dxspider-support mailing list