Open trevor-vaughan opened 6 years ago
Yes, good idea, thank you, @trevor-vaughan.
Hello @trevor-vaughan
I wanted to check with you if this is still a valid request from your side.
Testing on tlog-5.1
in Fedora I am unable to reproduce the configuration validation failure as described in your example. Could you help provide the configuration file contents which cause this issue, or if you have other examples that would be helpful for me to identify a fix here.
# cat /etc/tlog/tlog-rec-session.conf
//
// Tlog-rec-session system-wide configuration. See tlog-rec-session.conf(5) for details.
// This file uses JSON format with both C and C++ comments allowed.
//
{
// The path to the shell executable which should be spawned.
// "shell" : "/bin/bash",
// A message which will be printed before starting
// recording and the user shell. Can be used to warn
// the user that the session is recorded.
// "notice" : "\nATTENTION! Your session is being recorded!\n\n",
// The number of seconds to cache captured data for before logging.
// The encoded data which does not reach payload size
// stays in memory and is not logged until this number of
// seconds elapses.
// "latency" : 10,
// The maximum encoded data (payload) size per message, bytes.
// As soon as payload exceeds this number of bytes,
// it is formatted into a message and logged.
// "payload" : 2048,
// Logged data set parameters
"log": {
// If true, user input is logged.
// "input" : false,
// If true, terminal output is logged.
// "output" : true,
// If true, terminal window size changes are logged.
// "window" : true
},
// Logging limit parameters
"limit": {
// The maximum rate messages could be logged at, bytes/sec.
// "rate" : 16384,
// The number of bytes by which logged messages are allowed to exceed
// the rate limit momentarily, i.e. "burstiness".
// "burst" : 32768,
// The logging limit action.
// If set to "pass" no logging limits will be applied.
// If set to "delay", logging will be throttled.
// If set to "drop", messages exceeding limits will be dropped.
// "action" : "pass"
},
// File writer parameters
"file": {
// The "file" writer log file path.
// "path" : ""
},
// Syslog writer parameters
"syslog": {
// The syslog facility "syslog" writer should use for messages.
// "facility" : "authpriv",
// The syslog priority "syslog" writer should use for messages.
// "priority" : "info"
},
// Journal writer parameters
"journal": {
// The syslog-style priority "journal" writer should use for messages.
"priority" : "info",
// If true, the "journal" writer copies the following JSON fields
// to Journal fields: user -> TLOG_USER, session -> TLOG_SESSION,
// rec -> TLOG_REC, and id -> TLOG_ID.
"augment" : true
},
// The type of "log writer" to use for logging. The writer needs
// to be configured using its dedicated parameters.
"writer" : "syslog"
}
# tlog-rec-session -c "echo test"
ATTENTION! Your session is being recorded!
test
# tlog-rec-session --configuration
{
"shell":"\/bin\/bash",
"notice":"\nATTENTION! Your session is being recorded!\n\n",
"latency":10,
"payload":2048,
"log":{
"input":false,
"output":true,
"window":true
},
"limit":{
"rate":16384,
"burst":32768,
"action":"pass"
},
"file":{
},
"syslog":{
"facility":"authpriv",
"priority":"info"
},
"journal":{
"priority":"info",
"augment":true
},
"writer":"syslog",
"configuration":true,
"args":[
]
}
It eases the management of different types of systems when configuration files can warn, but not fail on, unknown keys.
Additionally, given the rapidly changing nature of
tlog
in general, this would allow for easy backward and forward compatibility of configuration files on upgrade without potentially breaking the login shell/sequence for users.Example: If I place a
tlog-rec-session.conf
with thejournal
section present but thewriter
set tosyslog
on an EL6 system,tlog
fails on validating the configuration file.