external Logging via Syslog

This Feature Request is still in Progress

1 Initial Problem

The current logging mechanism writes log data directly into files on the web server. This approach introduces several limitations:

These issues collectively hinder effective monitoring, incident response, and long‑term compliance.

As part of a common Logging-Infrastructure ILIAS will therefore provide a possibiltiy to ensure Threat Alert Mechanism and Tracing to a propper cyber-defense via Third-Party Applications

2 Conceptual Summary

The proposed solution introduces external logging via Syslog to replace or complement local file‑based logging. Instead of writing logs to the web server’s file system, ILIAS will transmit log events to a central Syslog endpoint using standardised protocols.

This approach:

The integration will follow established Syslog standards (e.g., RFC 5424) to ensure compatibility with common logging infrastructures.

3 User Interface Modifications

3.1 List of Affected Views

3.2 User Interface Details

An interface providing a form to fill in:

It could be disussed wether Encryption (TLS) shall be merged witin transportprotocoll along with UDP & TCP

To configure the Log Serverity multiple Checkboxes for INFO, ERROR, ...?? shall be provided.

3.3 New User Interface Concepts

none

3.4 Accessibility Implications

The Settings will be provided within a standard form. The Log-Data are transported to an external Log-Server. Therefore there are no Accessibility Implications within the planned Implementation

4 Additional Information

4.1 Involved Authorities

If this request is related to multiple components, please list both authorities for all related components.

4.2 Technical Aspects

{ Necessary technical information have to be provided here, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

4.3 Privacy

{ Personal data that will need to be stored or processed to implement this feature have to be listed here. For each date give a short explanation why it is necessary to use that date. }

4.4 Security

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers:  {Please add related profile link of this person}

4.6 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

5 Discussion

6 Implementation

Feature has been implemented by {Please add related profile link of this person}

6.1 Description and Screenshots

{ Description of the final implementation and screenshots if possible. }

6.2 Test Cases

Test cases completed at {date} by {user}

6.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

6.4 Approval

Approved at {date} by {user}.