Could you netmail me some details of what your netmail bases setup looks like
/ this filter? I do run makenl
I am running makenl for multiple networks but not clear what the best set up would look like for HPT in this regard. The robots things sounds curious
too...
/etc/ftn/config:netmailarea robots /fido/msgbase/robots
-b Jam -p 30
/etc/ftn/net/fsxnet/areas:netmailarea FSX_NETMAIL
/fido/makenl/21/netmail -b Msg -a 21:3/100
there at all, because I have the hub "unattended" and if you netmail anybody at the hub, you'll get a "bounce message" saying "nobody at the hub". But what does end up there are the pings and any messages from
husky about areas being autocreated - which I need to re-direct...)
For makenl to work, it creates a MSG netmail in the "messages" path of makenl.ctl, so with this area configured as a "-b Msg" for husky, it
sees those outgoing messages in hpt pack and sends them out. (I have a makenl.ctl for each zone in it's own subdirectory, and in that subdirectory is a "netmail" area.)
Filefix messages are "posted" to the robots area with my filter in
husky's config file "hptperlfile /usr/local/tools/filter.pl"
is robots netmail area defined in config using some additional
keyword(s)? I'm guessing yes. Just wondering how it knows to drop
areafix messages there?
/etc/ftn/net/fsxnet/areas:netmailarea FSX_NETMAIL
/fido/makenl/21/netmail -b Msg -a 21:3/100
So only fsx is set to Msg base type but the others all seem to be JAM so I'm picking only fsx is getting that makenl treatment you mentioned?
there at all, because I have the hub "unattended" and if you netmail anybody at the hub, you'll get a "bounce message" saying "nobody at the hub". But what does end up there are the pings and any messages from
husky about areas being autocreated - which I need to re-direct...)
..and that's due to some other scripting you have in place - right?
For makenl to work, it creates a MSG netmail in the "messages" path of makenl.ctl, so with this area configured as a "-b Msg" for husky, it
sees those outgoing messages in hpt pack and sends them out. (I have a makenl.ctl for each zone in it's own subdirectory, and in that subdirectory is a "netmail" area.)
..and these netmail areas are also used by you to reply to any netmails sent
to your HUB addresses? I can understand why you may place them as sub dirs in makenl... I'm not sure I will but rather place them as sub dirs in a /msgs/nmail folder instead I think... not 100% sure.. will keep pondering.
Filefix messages are "posted" to the robots area with my filter inhow is this file run? is it each time on incoming toss etc. can called within
husky's config file "hptperlfile /usr/local/tools/filter.pl"
a .sh file somehow?
Based on this I take it that rules that set noroute instructions for a given node should be stated above rules that set more catch-all/blanket routing statements?
route crash noroute 3:770/100
route crash 3:712/848 3:*
I think should work OK.. but if I reversed those lines... would HPT route all netmail intended to 3:770/100 via 3:712/848?
But looking at this manual description I'm not 100% clear on why you run a separate netmail base for Filefix? It appears netmails sent to both commands would land in your defined 'robots' base using the one keyword.
/etc/ftn/net/fsxnet/areas:netmailarea FSX_NETMAIL
/fido/makenl/21/netmail -b Msg -a 21:3/100
For makenl to work, it creates a MSG netmail in the "messages" path of
Right. First match wins.
anybody at the hub, you'll get a "bounce message" saying "nobody at
hub". But what does end up there are the pings and any messages from
husky about areas being autocreated - which I need to re-direct...)
..and that's due to some other scripting you have in place - right?
That's all due to my perl filter which is part of the hptperlfilter /usr/local/tools/filter.pl
areafix messages are processed during the run of "hpt toss", however hpt doesnt process filefix messages, so they need to be stored, so that
"htick scan" can find them and process them.
"htick" only looks for robot messages (areafix/filefix) in the "robots" area (or the first netmail configuration), but hpt puts filefix messages in the netmail area that is defined for the zone (or the global catch all). Sometimes there is a mismatch (as in my case), so I have to move filefix messages to the robots area manually (or rather
programmatically) for htick scan to find them.
For makenl to work, it creates a MSG netmail in the "messages" path ofHow many files do you end up with in this base when people send netmails to 21:3/100 ?
I'm thinking (and it's been some time since I used them) with the MSG style base you can end up with hundreds of files in a
dir, one for each message. Sound right? Al? And how to purge such files when I think the only utils
I've looked at so far seem to handle just JAM and Squish bases?
Based on this I take it that rules that set noroute instructions for a given node should be stated above rules that set more catch-all/blanket routing statements?
route crash noroute 3:770/100
route crash 3:712/848 3:*
I think should work OK.. but if I reversed those lines... would HPT route all netmail intended to 3:770/100 via 3:712/848?
route crash noroute 3:770/100
route crash 3:712/848 3:*
Yes, if "route crash 3:712/848 3:*" was listed first, netmail for 3:770/100 would be routed there. Your example above is what you want.
What no love for the other nets in z3 that you have connections to? %-(
But running tparser I get this
tparser/lnx 1.9.0-cur 2020-10-16
Test /hub/husky/config for all modules
"/hub/husky/links", line 80: unrecognized: AutoAreaCreate on "/hub/husky/links", line 81: unrecognized:
AutoAreaCreateDefaults -g B -lr 100 -lw 100 -p -1 -$m -1
Please correct above error(s) first!
I've also hit a snag with Tparser whereby the suggested config file syntax generated by the converter script from Fastecho to Husky had the following commands in it for some links
AutoAreaCreate on
AutoAreaCreateDefaults -g A -lr 100 -lw 100 -p 999 -$m 5000
But running tparser I get this
tparser/lnx 1.9.0-cur 2020-10-16
Test /hub/husky/config for all modules
"/hub/husky/links", line 80: unrecognized: AutoAreaCreate on "/hub/husky/links", line 81: unrecognized: AutoAreaCreateDefaults -g B -lr 100 -lw 100 -p -1 -$m -1
Do you know what the correct keywords are for a given link to allow echomail area creation and the defaults that should be used?
Looks like the FE -> Husky config tool has used hpt 1.4 keywords, I hope you don't run into more of that.
I don't use AutoAreaCreate so I am not sure but I know some keywords have changed. I think you need AreafixAutoAreaCreate and AreafixAutoAreaCreateDefaults now. Try that and see if tparser likes that better.
Indeed, that keyword doesnt work with 1.9. Those keywords are now
- AreaFixAutoCreate
- FileFixAutoCreate
tparser/lnx 1.9.0-cur 2020-10-16
Test /hub/husky/config for all modules
"/hub/husky/links", line 80: unrecognized: AreafixAutoAreaCreate on "/hub/husky/links", line 81: unrecognized: AreafixAutoAreaCreateDefaults
-gB -lr 100 -lw 100 -p -1 -$m -1
"/hub/husky/links", line 127: unrecognized: AutoAreaCreate on "/hub/husky/links", line 128: unrecognized: AutoAreaCreateDefaults -g
G -lr100 -lw 100 -p 730 -$m 5000
"/hub/husky/links", line 127: unrecognized: AutoAreaCreate on "/hub/husky/links", line 128: unrecognized: AutoAreaCreateDefaults -g G -lr 100 -lw 100 -p 730 -$m 5000
Hmm
-killsb
no seen-by & path kludges stores in message base (*)
-nokillsb
seen-by & path kludges stores in message base (*) if echoareadefaults set -killsb;
Al (and others) I read this and it looks like I need to set both switches if I want seen-by and path kludges to be stored in message bases. Seems like a good idea to me - thoughts?
Al I noticed you run
-sbkeepAll
Keep all seen-bys when zone-gating (prevails over -sbkeep).
If I used the two earlier switches and this one as well, do you think all would be fine?
-tooOld <number of days>
Move incoming echomail older than the given number of days to BadMail
I'm wondering what everyone is using for this setting? I'm thinking 60 days, a value too low could filter legitimate traffic.
I'm not sure what the correct keywords are.. a little experimentation might be needed, or help from someone who uses the auto create features.
Do see benefit in using these keywords?
echotosslog
importlog
linkwithimportlog
Despite reading up on them I'm not 100% clear in the merits of using them or if it's going to be fine to do without?
There's also seqdir , again not sure on that one as it also seems linked to seqoutrun ... which if not set, I'm not sure what the worth of setting just the dir would be? I'm picking leave both off and msgid would still be fine?
When you setting up a lockfile (LockFile) be needed? Do you run multiple copies of this software and use some monitoring script?
What no love for the other nets in z3 that you have
connections to? %-(
Now now, thus far I have you listed four times in that file and I
think you may be in the lead :)
Yah. For onece I'm not in the niddle or last. %-)
\/orlon
VK3HEG
EchoArea FSX_ENG msgs/fsx_eng -d "ENiGMA 1/2 BBS Support/Dev"
if fsx_eng does not exist in the /msg folder will the base be auto created?
EchoArea FSX_ENG msgs/fsx_eng -d "ENiGMA 1/2 BBS Support/Dev"
Yes, it will create the msgbase if it doesn't exist already.
If you use a path like msgs/fsx_eng you will have to be sure to always
run hpt from the directory below msgs/. If in doubt use an absolute path.
Yes, that is true of message bases and file base directories. You need
to have your fileareabasedir set, and it must exist but directories for your file areas will be created if they don't already exist.
Ah yep, OK so if I create a root dir called msgs I'll be sure to set things up as /msgs/fsx_eng - that should do the trick.
I'm wondering about how best to design/config for multiple networks? Specifically netmail, dupe and bad message bases.
Easy peasy :)
I use include files. Config for multiple network is in /etc/ftn/net/xxx (eg:sportsnet, fsxnet, videotex, etc)
In each subdir I have an "areas", "nodes" and "routes".
I'm wondering about how best to design/config for multiple networks? Specifically netmail, dupe and bad message bases.
Do you state specific netmail, bad and dupes for each network or just
use onecommunal base for each that covers all networks?
I use only one bad, dupe and netmail base. It's possible to use more
than one netmail base, one for each network but I have never done that.
If you do that filefix might have trouble finding netmail addressed to
it, there are ways to work that out but I haven't gone down that road.
Do you state specific netmail, bad and dupes for each network or just use onecommunal base for each that covers all networks?
I just use one of each here.
Do you state specific netmail, bad and dupes for each network or just use one communal base for each that covers all
networks?
I'm not sure you can have one for each network - and if you can I dont know how.
I use only one bad, dupe and netmail base. It's possible to use more than one netmail base, one for each network but I have
never done that.
If you do that filefix might have trouble finding netmail addressed to it, there are ways to work that out but I haven't
gone down that road.
Do you state specific netmail, bad and dupes for each network or justne communal base for each that covers all
networks?
I'm not sure you can have one for each network - and if you can I dont know how.
Another uncertainty for me. In Fastecho when I first set it up I set up node entries for the HUB aka addresses I fly. It was done way back when I first started setting up FE and I think from memory may have been needed to ensure netmail sent to my AKA addresses for the various network hubs was accepted.
Yes, I have more than 1 netmail base - I need that for makenl to send segments to upstream hosts.
Yes, I have more than 1 netmail base - I need that for makenl to send segments to upstream hosts.
To get around filefix not finding messages, in my filter (that controls the robot), I move the message into a "robot" message area, since
filefix looks into it.
Carbon copy can be used as well - but I havent played with carbon copy, since the filter can do it too...
Sysop: | Gary Ailes |
---|---|
Location: | Pittsburgh, PA |
Users: | 132 |
Nodes: | 5 (0 / 5) |
Uptime: | 109:44:07 |
Calls: | 733 |
Files: | 2,171 |
Messages: | 81,483 |