just like client->user is set if the client is a user.
Rename client->srvptr to client->uplink: this is the uplink that the client
is connected to. If the client is a user then it is set to the server that
the client is connected to, if the client is a server then it is set to the
server that the server is connected to (the.. tadah.. uplink).
For local clients it is always set to &me.
We now also correctly disable color support if someone is on
a color-capable terminal but redirects the output of the boot
to a file, eg: bin/unrealircd >boot.log 2>&1
Just as a reminder: don't blindly assume that if anything is set here
that the user is logged in, there is IsLoggedIn(client) for that.
Reason: if the account name starts with a digit or is "*" then the
user isn't actually logged in ;)
to match the order on IRC. IOTW: subsystem.EVENT_ID and loglevel are
now swapped. New log format on disk is:
[timestamp] subsystem.EVENT_ID loglevel: message
This because in UnrealIRCd we may encounter non-UTF8 sequences,
which this function will censor out.
Also, this takes care of returning json_null() if the string was
NULL, which is usually what we want as well.
we will now only send the JSON in the first message.
Also fix log file timestamp missing with multiline.
And rename do_unreal_log_ircops() to do_unreal_log_opers()
Add safe_free_message_tags()
Any \n's will be expanded to multiple lines.
* For JSON disk logging there is no change.
* For text disk logging it will show as:
[time] facility subsys.CODE+
[time] facility subsys.CODE+
[time] facility subsys.CODE
So a plus sign is added if another message is to follow.
* For notices to opers/snomasks exactly the same (plus sign if needed).
Untested. More changes to follow eg to notice dropping the json
in the followup msgs.
This also changes the logging format for text disk to match
the output on server notices, we no longer log as:
[TS] facility subsystem event_code: msg....
But as:
[TS] facility subsystem.event_code: msg....
Saves a bit of room, especially when the JSON travels over network this
maybe save some "crucial" bytes (and in that case it looks better too,
since the \s's in message tags only make it less readable).
This basically enhances the regular snomask/ircop notices with
JSON logs, the same logs that are logged to disk (with type 'json').
This allows bots/machines to much more easily parse server notices
such as connect notices or.. anything.
Note that JSON logs are quite large, so make sure the ircop has
a BIG class::sendq!
Also, everyone can set the cap but it is only effective for IRCOps.
snomasks, opers, global (remote), ..
For disk logs we currently ignore the sources and log everything.
NOTE: REHASH is untested and will memory leak for sure.
This means we now have $client.user.username but the expansion system
does not allow items more than 2 deep atm (only $client.something
but not $client.something.other). Will fix later. (TODO)
In the meantime the connection notice will look weird :D
Also rename them to describe better what they do.
ConfigFile:
cf_filename -> filename
cf_next -> next
cf_entries -> items
ConfigEntry:
ce_fileptr -> file
ce_varlinenum -> line_number
ce_fileposstart -> file_position_start
ce_fileposend -> file_position_end
ce_sectlinenum -> section_linenumber
ce_varname -> name
ce_vardata -> value
ce_cond -> conditional_config
ce_entries -> items
ce_next -> next
ce_prevlevel -> parent
Also add doxygen docs for both structs.
Note that without such a block nothing will be sent to ircops at all
(anything that comes from unreal_log anyway).
In a later commit either a snomasks.default.conf will be added and/or
an internal default mapping.
This also moves the recursion trap to earlier in the logging code,
which has the side effect that debug traffic regarding snomasks is
no longer logged.
when any of these are wrong. Obviously this should probably be changed to
only do it in DEBUGMODE in a final stable release :D
We also crash if 'msg' contains a percent sign ('%'). This is to avoid
mistakes where someone uses eg '%s' in there, which is not supported.
Unfortunately it also prevents stuff like '100%' so this should probably
be removed too at some point.
The former is an integer and may not always be available (eg: very early
before the user is connected). The latter is an array.
TODO: opt-in/out of all these expansions as they come at a performance penalty
a wrapper that will return a 'null' JSON object for null strings and
otherwise a string object for non-NULL. It seems by default this is
not the case which is a bit annoying. Maybe we should re-wrap all
code to use this. We'll see.
The problem is when this is not done, then a $variable won't be
expanded and would show up like literally "$variable" as if the
variable was never passed on.
logging. We already did so for the "timestamp" of the log message,
but now also do it in other log messages that have a timestamp,
such as "set_at" and "expire_at" in TKL entries.
Bram Matthys