[PR #106] [MERGED] feat: revamp logs #241

New issue

Closed

opened 2026-05-07 00:19:57 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-07 00:19:57 +02:00

Owner

📋 Pull Request Information

Original PR: https://github.com/ovh/the-bastion/pull/106
Author: @speed47
Created: 12/28/2020
Status: ✅ Merged
Merged: 1/5/2021
Merged by: @speed47

Base: master ← Head: logs

📝 Commits (1)

a479810 feat: revamp logs

📊 Changes

9 files changed (+236 additions, -162 deletions)

View changed files

📝 bin/admin/install (+5 -22)
📝 bin/helper/osh-accountCreate (+4 -4)
📝 bin/shell/connect.pl (+7 -7)
📝 bin/shell/osh.pl (+14 -8)
📝 doc/sphinx/administration/bastion_conf.rst (+5 -5)
📝 etc/bastion/bastion.conf.dist (+5 -5)
📝 lib/perl/OVH/Bastion.pm (+2 -2)
📝 lib/perl/OVH/Bastion/execute.inc (+15 -14)
📝 lib/perl/OVH/Bastion/log.inc (+179 -95)

📄 Description

All connections and plugin executions emit two logs, an 'open' and
a 'close' log. We now add all the details of the connection to
the 'close' logs, those that were previously only available in the
corresponding 'open' log. This way, it is no longer required to
correlate both logs with their uniqid to have all the data:
the 'close' log should suffice. The 'open' log is still there if
for some reason the 'close' log can't be emitted (kill -9, system
crash, etc.), or if the 'open' and the 'close' log are several
hours, days or months appart.

An additional field "duration" has been added to the 'close' logs,
this represents the number of seconds (with millisecond precision)
the connection lasted.

Two new fields "globalsql" and "accountsql" have been added to the
'open'-type logs. These will contain either "ok" if we successfully
logged to the corresponding log database, "no" if it is disabled,
or "error $aDetailedMessage" if we got an error trying to insert
the row. The 'close'-type log also has the new "accountsql_close"
field, but misses the "globalsql_close" field as we never update
the global database on this event. On the 'close' log, we can also
have the value "missing", indicating that we couldn't update the
access log row in the database, as the corresponding 'open' log
couldn't insert it.

The "ttyrecsize" log field for the 'close'-type logs has been removed,
as it was never completely implemented, and contains bogus data if
ttyrec log rotation occurs. It has also been removed from the sqlite
log databases.

The 'open' and 'close' events are now pushed to our own log files,
in addition to syslog, if logging to those files is enabled (see
enableGlobalAccesssLog and enableAccountAccessLog), previously
the 'close' events were only pushed to syslog.

The /home/osh.log is no longer used for enableGlobalAccessLog, the
global log is instead written to /home/logkeeper/global-log-YYYYMM.log.

The global sql file, enabled with enableGlobalSqlLog, is now
split by year-month instead of by year, to
/home/logkeeper/global-log-YYYYMM.sqlite.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/ovh/the-bastion/pull/106 **Author:** [@speed47](https://github.com/speed47) **Created:** 12/28/2020 **Status:** ✅ Merged **Merged:** 1/5/2021 **Merged by:** [@speed47](https://github.com/speed47) **Base:** `master` ← **Head:** `logs` --- ### 📝 Commits (1) - [`a479810`](https://github.com/ovh/the-bastion/commit/a479810d83e32ce8805520a9678e8678888446c9) feat: revamp logs ### 📊 Changes **9 files changed** (+236 additions, -162 deletions) <details> <summary>View changed files</summary> 📝 `bin/admin/install` (+5 -22) 📝 `bin/helper/osh-accountCreate` (+4 -4) 📝 `bin/shell/connect.pl` (+7 -7) 📝 `bin/shell/osh.pl` (+14 -8) 📝 `doc/sphinx/administration/bastion_conf.rst` (+5 -5) 📝 `etc/bastion/bastion.conf.dist` (+5 -5) 📝 `lib/perl/OVH/Bastion.pm` (+2 -2) 📝 `lib/perl/OVH/Bastion/execute.inc` (+15 -14) 📝 `lib/perl/OVH/Bastion/log.inc` (+179 -95) </details> ### 📄 Description All connections and plugin executions emit two logs, an 'open' and a 'close' log. We now add all the details of the connection to the 'close' logs, those that were previously only available in the corresponding 'open' log. This way, it is no longer required to correlate both logs with their uniqid to have all the data: the 'close' log should suffice. The 'open' log is still there if for some reason the 'close' log can't be emitted (kill -9, system crash, etc.), or if the 'open' and the 'close' log are several hours, days or months appart. An additional field "duration" has been added to the 'close' logs, this represents the number of seconds (with millisecond precision) the connection lasted. Two new fields "globalsql" and "accountsql" have been added to the 'open'-type logs. These will contain either "ok" if we successfully logged to the corresponding log database, "no" if it is disabled, or "error $aDetailedMessage" if we got an error trying to insert the row. The 'close'-type log also has the new "accountsql_close" field, but misses the "globalsql_close" field as we never update the global database on this event. On the 'close' log, we can also have the value "missing", indicating that we couldn't update the access log row in the database, as the corresponding 'open' log couldn't insert it. The "ttyrecsize" log field for the 'close'-type logs has been removed, as it was never completely implemented, and contains bogus data if ttyrec log rotation occurs. It has also been removed from the sqlite log databases. The 'open' and 'close' events are now pushed to our own log files, in addition to syslog, if logging to those files is enabled (see ``enableGlobalAccesssLog`` and ``enableAccountAccessLog``), previously the 'close' events were only pushed to syslog. The /home/osh.log is no longer used for ``enableGlobalAccessLog``, the global log is instead written to /home/logkeeper/global-log-YYYYMM.log. The global sql file, enabled with ``enableGlobalSqlLog``, is now split by year-month instead of by year, to /home/logkeeper/global-log-YYYYMM.sqlite. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>