Per a ticket request, Squid has the option to accept a remote syslog server.
There would be two options:
- use rsyslog
- use built-in squid option.
Path of least resistance was to integrate the built-in option
Description
Description
Details
Details
- Difficulty level
- Unknown (require assessment)
- Version
- -
- Why the issue appeared?
- Will be filled on close
- Is it a breaking change?
- Unspecified (possibly destroys the router)
- Issue type
- Feature (new functionality)
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | FEATURE REQUEST | c-po | T563 webproxy: migrate 'service webproxy' to get_config_dict() | ||
| Open | FEATURE REQUEST | None | T1730 Adding the remote syslog feature to webproxy |
Event Timeline
This comment was removed by kroy.
Comment Actions
I would rather prefer it to send messages to local syslog and then distribute it to remote hosts. Otherwise we have an async syslog interface.
Also this option os squid related - if we change the proxy in the future will it still work?
Also with using local syslog the user does not need to configure additional server(s).
Comment Actions
Because the amount of logs from this system could be enormous, Is it possible to move these logs to another syslog file to not overcroud the main syslog file?
Comment Actions
To be fair, that’s what prompted this. The logs go to a different file already.
I imagine I could generate an rsyslog config to read the separate file instead
Comment Actions
Okay, after working with this for a while, I believe the whole 'vyatta-webproxy` should be a candidate for deletion in equuleus (see T1732).
With that said, the whole goal here was to address an issue in a ticket to allow remote logging of Squid data.
- The easy option is about four lines of changes to expose the native Squid option as a configuration option to log to a remote syslog server.
- The next easy option is to pass Squid logs into rsyslog. This would allow them to be picked up by the remote syslog option. This is ugly because /var/log/message becomes hugely polluted with data.
Any other option requires modifying multiple modules, probably for a feature that it not used much if ever, and as mentioned, I feel like this module should be removed completely in the future.