• Re: A46 idea

    From Avon@21:1/101 to g00r00 on Sat Feb 22 07:08:38 2020
    On 19 Feb 2020 at 08:51a, g00r00 pondered and said...

    To be honest it's not something I'll likely use much for the BBS but be able to manually put in connections who have static IP addressees into a Mystic system running as a HUB is something I do a lot of. It helps the node a lot and saves a few lockouts.

    It doesn't work for the BINKP but I certainly can expand it to do so!

    I'll make a note of it.

    It's not something I feel needs to be added, rather I was just making the observation that being able to add IPs in for known systems to avoid them
    from being blocked when they were keenly fidopolling a HUB was helpful.

    I've only been doing this when I know a node had a static IP. I guess adding something more automated in this regard for nodes with dynamic IP that successfully poll could be helpful. But given that dynamic IPs come and go I think I read somewhere others suggesting some sore of self expiring process
    to remove older dross may be important else risk an ever ballooning whitelist.

    So In short, don;t make this feature a priority on my account :) I think there's other things that would be more further up your TO-DO that others
    will have contributed :)

    A45 seems solid. Only errors at Agency were from two days ago

    2020.20.02 20:33:30 MYSTIC 001 Cannot write to c:\bbs\mystic\data\chat1.dat. Code=2, PID=118280
    2020.20.02 20:33:30 MYSTIC 001 Cannot write to c:\bbs\mystic\data\chat1.dat. Code=2, PID=118280
    2020.20.02 20:33:30 MYSTIC 001 Cannot write to c:\bbs\mystic\data\chat1.dat. Code=2, PID=118280

    No issues at the HUB at this stage. Do you want some logs to scroll through?

    I did note a couple of minor things

    Hatching files from within Mystic file editor is not being logged


    ------------------- Node 1 (Mystic v1.12 A45 2020/02/18)
    2020.02.22 06:34:49 Connect from local (local)
    2020.02.22 06:34:49 Set time left 30 TE=424
    2020.02.22 06:34:53 Avon logged in
    2020.02.22 06:34:53 First login today, setting time to 999
    2020.02.22 06:34:53 Set time left 999 TE=1393
    2020.02.22 06:34:53 Setting time left to 999
    2020.02.22 06:35:11 File search: "LAST"
    2020.02.22 06:35:44 File DIR editor
    2020.02.22 06:40:50 User logged off
    2020.02.22 06:40:50 Shutting down

    No hatching being requested after File Dir Editor

    But it did the business when MUTIL ran

    + Feb 22 06:38:04 Process: Toss FDN/TIC Files
    + Feb 22 06:38:04 Waiting for BUSY nodes
    + Feb 22 06:38:04 Scanning Hatches
    + Feb 22 06:38:04 Hatching: xq-ilc123.zip from Mystic BBS Utils, Mods etc.
    + Feb 22 06:38:04 Tossing to 21:1/114

    [snip]

    + Feb 22 06:38:05 Tossing to 21:1/209
    + Feb 22 06:38:05 Results: 0 import, 68 toss, 1 hatch, 0 bad in 0.28s


    I also noticed that running a file announcement using PostTextFiles generates messages with a tearline that does not show build date.

    - Feb 22 06:41:01 EXEC PostTextFiles
    + Feb 22 06:41:01 Process: Post Messages
    + Feb 22 06:41:01 Post: 3 Subj: Hatched Files
    + Feb 22 06:41:01 Post: 9 Subj: Hatched Files
    + Feb 22 06:41:01 Results: Posted 2 Msgs in 0.00s

    when it lands at 1/101 Agency I see

    --- Mystic BBS v1.12 A45 (Windows/32)
    * Origin: fsxNet HUB (21:1/100)

    but if I post a standard echomail message from 1/100 I see the following at 1/101

    This is a test to check a tearline

    --- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
    * Origin: fsxNet HUB (21:1/100)

    so yeah, minor thing, but my OCD picked it up :)

    --- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From g00r00@21:1/108 to StackFault on Sat Feb 22 07:26:03 2020
    is good for 30 days after a successful authentication. If you don't connect for 30 days, the whitelist goes. This would autoclean the whitelist in case of dynamic IP addresses.

    It would but it would also remove IP addresses that you actually want to manually whitelist too. I am not sure that would even really be a problem though if you're using automatic whitelist but if you're not it certainly would.

    It would also require me to change the format of the whitelist out of a single line text file to something that you couldn't manage easily because it'd have to be associated with (probably) a Unix time stamp value.

    --- Mystic BBS v1.12 A45 2020/02/18 (Windows/64)
    * Origin: Sector 7 (21:1/108)
  • From g00r00@21:1/108 to Avon on Sat Feb 22 07:48:21 2020
    2020.20.02 20:33:30 MYSTIC 001 Cannot write to c:\bbs\mystic\data\chat1.dat. Code=2, PID=118280

    Yeah this is really weird. Let me know if you notice this again. The code=2 means the file doesn't exist and there should never be a situation where chatx.dat is deleted while a user is still online...

    Mystic creates it on startup and removes it on close, so how it got removed in those circumstances is a mystery at the moment.

    It used to be that Mystic would just recreate it, but that was causing some potential race conditions that could cause ghost nodes when I was doing load testing on MIS. So now it doesn't and instead spits an error out.

    --- Mystic BBS v1.12 A45 2020/02/18 (Windows/64)
    * Origin: Sector 7 (21:1/108)
  • From StackFault@21:1/172 to g00r00 on Sun Feb 23 13:13:33 2020
    I'd tweak that just a bit by setting up a whitelist lease. The whitel is good for 30 days after a successful authentication. If you don't connect for 30 days, the whitelist goes. This would autoclean the whitelist in case of dynamic IP addresses.

    It would but it would also remove IP addresses that you actually want to manually whitelist too. I am not sure that would even really be a
    problem though if you're using automatic whitelist but if you're not it certainly would.

    Yes, this is certainly something to keep in mind.

    It would also require me to change the format of the whitelist out of a single line text file to something that you couldn't manage easily
    because it'd have to be associated with (probably) a Unix time stamp value.

    That value could be used for both purposes. A value of 0 would be permanent while a non-zero (epoch for example) would be the expiration. It would also require you to update the file to extend the expiration on successful BinkP connection and so on. I understand this is not a simple change but it would
    add some value.

    Cheers!

    |15 ▀ ▐ |15StackFault |08<|03.|11.|15P|11h|03EN|11o|15M|11.|03.|08>
    |11 ▌ ▀ |11The Bottomless Abyss BBS
    |03 ▀ ▌▀ |03ssh|08.|072222 |08/ |03telnet|08.|072023 |08/ |03https
    |08 ▄■▐ |08bbs|07.|08bottomlessabyss|07.|08net

    --- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
    * Origin: The Bottomless Abyss BBS * bbs.bottomlessabyss.net (21:1/172)