The Global Login Requirements (default: blank) are used for any sever that doesn't have it explicitly set.

This resolves issue #666 (the issue of the beast) for Keyop

e.g. User.downlaoded_file() will now publish to the appropriate MQTT topic and changes to system.node_list[] will get published to MQTT.

The JS objects will still log to the terminal server (regardless of which server created/used the objects) however - so that's still a TODO.
Change do_cryptInit() to return bool, since it does.
Log detailed error if pthread_once() call fails.
Lowered-severity (to DEBUG) the log messages related to TLS private key and cert creation and destruction.

FIrst commit from within MSVS, so this might look weird.

Private key objects in cryptlib are not copied into sessions when
they're added, only the refcount is incremented.  These objects
contain a bignum context, which therefore ends up shared across all
instances of the private key.  Unfortunately, the locking is on the
session context, not the private key objects, so shared bignum contexts
can cause memory corruption.

Further, even if the locking issue was fixed, the performance handbrake
would still exists... activating sessions that use the same private key
would be serialized, with the results we've been seeing lately.

With this, each session gets a unique private key, which is loaded
from the file.  When a session is finished with the key, it is cached
in a list with an epoch, so when the date on the key file changes, old
private keys will be eliminated.

While this solves a lot of issues, logging of certificate generation
and loading issues has regressed to the point where it's effectively
not done at all. Logging was previously passed back to the caller,
but given the much longer call chain to get to where a cert is created,
the extra parameters was just too much. Something better should be
done here at some point.

We'll hold a reader lock under the session is established, which
should prevent blocking other threads unless something is beating
on get_ssl_cert() (which would be a different bug).

This still needs to be figured out, but at least this should fix
the immediate issue.

Holding the lock around session establishment should not be needed,
but we need to protect tls_certificate read and usage.  Since we
don't have rwlocks in xpdev (yet?), hack together a crappy rwlock
that does what we need.

Also, remove "CONSECUTIVE", which doesn't really make sense when the number
of login attempts in 1.

More readable/friendly log messages and ip.can reason strings

Now a sysop can "perm block" a client (IP address) for a limited amount of
time rather than always forever.

Add more displays of the ip.can details when actively blocking a client.

Moved twit/trash functions from userdat.c to trash.c

... especially around incoming connection acceptance, blocked-IPs/hostnames

Using "Warning" log levels more for things that the sysop might be able to do
something about. If it's just an input data validation (from a random TCP/IP
client), use "Notice" log level instead.

The terminal server log output is still the odd ball.

The time span over which consecutive failed logins are attempted is important

The log format and details might need some adjustment, but this is a start.

Also, don't delay 3 seconds before disconnecting socket when mail server has
reached maximum number of clients - we should immediately release resources
(the socket) and be able to accept another connection ASAP instead.

Deal with new CID 470557 and 470554 in mail server: resource (file*)
leaks in error paths (corner case).

Set minimum severity of TLS messages in web sever to INFO. Debug-level would
hide some common TLS session errors.

The user name is better to log than the user number. Include user name in
brackets.

This macro hasn't done anything meaningful since we stopped using really old
versions of Borland compilers (and std libraries) where strerror() returned a
string terminated with a line-feed (\n) character.

Or even weirder, u_long?

And dereffing a ulong/u_long pointer where you expect to find an IPv4 address?
Yet even weirder still.

Fix that spit: It appears in_addr_t is defined on all platforms (?), so use
that type instead.

No known sightings of these sites actually being the location of a segfault,
but as we learned from the segfaults in rblchk(), the first entry in the
h_addr_list can be NULL in some cases.

This bug only impacted non-passive FTP connections. Using an FTP client
with active (not passive) data connections over an IPv6 connection would
false-trigger the "bounce attack" detection and the FTP server responded with
"504 Bad port number" and logged a hack attempt in data/hack.log.

The issue was that we were comparing the socket address structure (which
contains other fields besides the address itself) between the control and
proposed-data connections. While this logic worked okay for IPv4,
it did not for IPv6 (the 2 structs contained some non-address differences).
Rather than modify the socket address structures to match where needed, I'm
just comparing the string representation of the addresses, since that's
what we really care about anyway.

Thank to "mark i" of Truck Stop BBS for alerting me to this issue

The lower of the configured maximum file size (for the FTP server) and
the available disk space minus the configured minimum free disk space
is used as the maximum file size to allow upload. Appended files
are accounted for too.

Disallow uploads when free disk space falls below minimum configured
minimum free disk space.

This fixes issue #535

Handles integer overflow in the summing of user's credits and remaining daily
free credits.

Mostly [s]printf format fixups

Publish all login-failures to this new topic.

This commit also includes a few 64-bit free disk space fixes in the FTP server.

... not before. This explains why FTP-uploaded actions had a (null) filename.

Since v3.19 (the new filebases), when a user FTP-downloaded a file, we failed
to properly find/load that file's record from the filebase (searching for the
file's full path, rather than just the filename), so the code the increments
the file's download counter, notifies the uploader, awards credits, etc. did
not ever execute. This means that FTP-downloads for all files downloaded via
FTP were effectively "free" (and nobody noticed). No error was logged either.

I discovered this while debugging the case of "(null)" filenames in the
action/download MQTT topic messages being published by the FTP server. So
that issue is fixed as part of this commit as well.

Oh, and if this code had executed before, it would have memory-leaked the
file information, so that's fixed too (added call to smb_freefilemem). Ugh.

- Most published messages (besides log entries) have a timestamp (in ISO8601 format) prepended and tab-separated
- The order and number of elements in client messages (list and activities) has been updated, now includes user number
- Server client lists are now published to .../SERVER/client/list
- Server client activities (connect, disconnect, update) are now published to .../SERVER/client/action/#
- Server client count is now published to .../SERVER/client (with the maximum client count, if applicable)
- Server states are now just represented by name (e.g. initializing, ready, stopping, stopped) and not number
- BBS errors are logged to sbbs/BBS/action/error/LEVEL (where LEVEL is the log level name, e.g. "critical" or "error')
- All server hack-attempts, SPAM attempts, logins, logouts, uploads, downloads, are published to sbbs/BBS/action/ACTION/*
- Chat pages are published to sbbs/BBS/action/page/node/#
- New users (on the terminal server) are published to sbbs/BBS/action/newuser
- Posted messages and executed external programs (on the terminal server) are published to sbbs/BBS/action/ACTION/CODE topic
- The event thread started/stopped status is published to .../SERVER/event

Yeah, the wiki will get updated soon to reflect/document all these changes

This fixes issue #495.

This is more consistent with how these events are logged in a BBS-common log file in data/*.log.

This change also restores the server abbreviation to the error log entries that used to be there until recently.

Each Synchronet server is now its own MQTT client. This means there's no
longer any MQTT logic in the Synchronet "hosts" (e.g. sbbscon.c, ctrl/*.cpp)
and none needed for SBBS NT services (they'll "just work" with MQTT).

This also means that just about everything (except for nodes, spam and hack)
is now published per-server (in the sbbs/BBS-ID/hostname/server/ topic branch)
and if you want aggregated totals or client lists, you'll have to do that in
your own MQTT client or dashboard.

I also removed the publishing of thread_count and socket_count topics as
they weren't universally supported across all servers and are of questionable
value. They can be added back later if determined to be useful.

Now support subscriptions (e.g. recycle topics, node input topics) in SBBSCTRL.
This required a lot of search/replace and fun with circular struct pointers.