Tickit

Tickit (exec/tickit.js) is a simple incoming TICK (TIC File) processor for Synchronet.

It is configured via the file: ctrl/tickit.ini

Managing ctrl/tickit.ini may be done manually or via exec/tickitcfg.js. The preferred method is via tickitcfg which allows for importing your FDN areas as well as access to global and per area options.

Tickit automatically executes exec/addfiles when it processes files sent to your system in FDN areas stored in your file bases. Addfiles is executed for each file as it is processed. Files stored outside of your file bases will not have addfiles run against them during processing.

In a recent change to SBBSecho/EchoCfg v3 and tickit.js, the TIC file password for each FTN-linked node is now stored in the TicFilePwd key of the corresponding [node] section of the sbbsecho.ini file and can be managed via AreaFix and via echocfg.

You should create an event to run it when you get .TIC files...

Internal Code                   TICKIT    
Start-up Directory                        
Command Line                    ?tickit.js
Enabled                         Yes       
Execution Node                  1         
Execution Months                Any       
Execution Days of Month         Any       
Execution Days of Week          None      
Execution Time                  00:00     
Requires Exclusive Execution    No        
Force Users Off-line For Event  No        
Native Executable               No        
Use Shell to Execute            No        
Background Execution            No        
Always Run After Init/Re-init   No        

• If using BinkD, add a line like this to your binkd.cfg file to create a semaphore file which triggers the TICKIT timed-event to execute whenever a .tic file is received:

  flag /sbbs/data/tickit.now *.tic *.TIC

• BinkIT automatically runs the TICKIT timed event when a TIC file is received
• If you would like to treat all imported .tic files as though they have a REPLACES clause, add the -force-replace option to the ticket.js command-line or use the Force Replace options in tickitcfg for global or per-area forced replacements

The following global options are used by TickIT:

• Path Default local path to store files in. If this is set, the file will NOT be imported into a local sub.
• Dir Default BBS file directory internal code to store files in. addfiles will be called to import the file.
• Links Comma-separated list of FTN addresses to forward *all* files to.
• IgnorePassword Set to true to ignore the password in the TIC file along with the packet password for the node. This will allow anyone who can send a TIC file to your board to overwrite files in your file bases, so should be used with caution (and only used with SecureOnly).
• SecureOnly Set to true to only import TIC files from the secure inbound.
• Handler Set to the filename of a handler script as defined below.
• HandlerArg a string that is passed to the handler function.

Path and Dir cannot be used together.

Each section is a FDN area. This must match the AREA tag in the TIC file. Each area supports the following options:

• Path Local path to store files in. If this is set, the file will NOT be imported into a local sub.
• Dir BBS file directory internal code to store files in. addfiles will be called to import the file.
• Links Comma-separated list of FTN addresses to forward the files to.
• Handler Set to the filename of a handler script as defined below. If present, this overrides the global Handler, they do not both run.
• HandlerArg a string that is passed to the handler function.

The following is a sample FDN Area Definition for the DAILYLIST FDN.

[DAILYLIST]
Dir=FDIST-DAILYLIS
Links=1:261/38,1:123/115,1:123/755,1:135/300,1:3634/12.73,1:3634/27
Handler=tickit/nodelist_handler.js
HandlerArg={"domain":"fidonet", "match":"Z1DAILY.Z*", "nlmatch":"Z1DAILY.*"}
SourceAddress=1:18/0
AKAMatching=false
Uploader=DAILYLIST File Dist

The Dir line contains the internal code for this area. In this case, FDIST- is the internal code for the file library and DAILYLIS is the internal code for the specific area. Both are used to determine the full internal code for the area. You do not have to define a code for the library if you do not want to but you must have an internal code for the area defined. These internal codes should be unique between areas or you will have them crosslinked and be putting files in the wrong area.

The Links line should contain at least one FTN address. This will be the address of your feed for the FDNs you carry. Every system that you link this area to will be listed as shown above. No spaces are allowed and each FTN address must be complete. I generally put the addresses in numerical order with the first address listed being the main linked system feeding the area. This is not set in stone. You can list the addresses in any order you like.

See the below nodelist_handler subsection in the Handler Scripts section for the definition of what the file handler related lines do.

The SourceAddress is an override field if you want this area to be distributed from a different FTN address than your main one. Your main FTN address is the first one listed in scfg in the fidonet network configuration section. Each of your fidonet technology addresses will be listed in that same section all together.

AKAMatching is another override for which of your addresses will be used if you have this area connected to more than one system. AKAMatching determines if your main address will be used, if one of your SourceAddress overrides will be used, or if your AKA will be matched to the closest of your addresses for the destination system.

Example: If you have addresses 1:3634/12, 1:18/0, 1:123/0, and 1:3634/0 and you want this DAILYLIST FDN to be sent to each of the above listed links with the closest matching of your four FTN addresses, you would set AKAMatching=true.

The following table shows which of these example FTN addresses will be used for each destination system based on the three address related options provided.

TIC files can be passed to a handler for special processing. The handler is declared in a separate JS file which must not have a null last statement. If the handler returns a true value, the TIC file is assumed to have been processed and no further import actions are taken. A simple “do-nothing” handler script would be as follows:

function Handle_TIC(tic, ctx, arg)
{
    // Do nothing...
    return false;
}
 
0;

If the script returns true, it must ensure that tic.full_path is updated to the path where the unmodified file can be found to ensure it can be transferred to downlinks. If the handler wants to avoid it being sent to downlinks, it can stuff all the downlink addresses into the tic.seenby array like this:

function Handle_TIC(tic, ctx, arg)
{
    if (blackhole(tic)) {
        ctx.tickit.gcfg.links.forEach(function(link) {
            tic.seenby.push(link);
        });
        ctx.tickit.acfg[tic.area.toLowerCase()].links.forEach(function(link) {
            tic.seenby.push(link);
        });
        return true;
    }
    return false;
}
 
0;

There are some TIC handler scripts in CVS now. They live in the exec/load/tickit directory.

This handler script is for keeping nodelists up to date. The HandlerArg is a JSON string containing a domain and optionally a filespec for the received file and for the nodelist file in the archive, as well as a return code. It uses the configured packers from sbbsecho.ini/sbbsecho.cfg, so ensure that the archiver used is defined there. It returns false so the file can also be processed normally (ie: imported into your local file area), and is forwarded to downlinks normally.

Here is my tickit.ini entry:

[DAILYLIST]
Dir=DAILYLIST
Handler=tickit/nodelist_handler.js
HandlerArg={"domain":"fidonet", "match":"Z1DAILY.Z*", "nlmatch":"Z1DAILY.*"}

This means that the Fido file area “DAILYLIST”, files are imported into my BBS file area “DAILYLIST”, and the tickit/nodelist_handler.js file contains the handler for this area. The handler is passed all of the available arguments.

• domain the FTN domain this is the nodelist for. This value is required.
• match the filespec for nodelist archives in this area. If the incoming file doesn't match this, the nodelist is not updated. This defaults to '*.*' on Windows and '*' everywhere else.
• nlmatch the filespec for the nodelist file inside the archive. There must be exactly one file matching this filespec inside the archive, or the nodelist will not be updated. . This defaults to '*.*' on Windows and '*' everywhere else.

• Module Index
• tickitcfg