Filed with Developers syslogd [Case 55062, Case 55064]

[lshaw]

It would be nice to have the option to direct Exim logs to a syslog facility. I know Exim supports this, but I also understand that this could break some cPanel functionality that relies on these logs if the syslog facility were a remote host. This is likely one reason why there is not an option (that I can find) through cPanel/WHM to use syslog for Exim logging.

Perhaps everyone could be made happy by having the option to tee the logs to both a local file and a syslog facility? I'm not sure what the I/O hit would look like, but I would imagine it wouldn't be too bad except on the busiest servers.

Thank you for your time in reading and considering this.

[lshaw]

6+ month bump.

Just wanted to give it one more shot to see if anyone else desires this functionality.

Thanks.

[cPanelDavidG]

We have received many requests for syslogd including from a couple of our Partner NOCs. If we could narrow this down and elaborate upon this to determine what you want, rather than obviously using this utility in some way, that would be greatly appreciated.

This feature request was requested by: United Hosting and Kualo

[Infopro]

I'm unclear on what this post is asking specifically. It seems to be missing some core elements like, what the actual Feature Request is.

[Doobla]

I'm assuming that you are referring to our discussion about cpanel's log rotation implementation.

In order to keep archives of apache logs for individual domains we have to turn on an option to archive the logs from within the Raw Logs section of cPanel. At that point, every time logs are processed (every 24 hours on our server) the log file contents are dumped into an archive in /home/user/logs/ and then the apache log is zeroed out for that domain.

Problems with this approach are as follows:

1. User can turn it off if they want. The sysadmin has no way to keep an archive for sysadmin purposes.
2. User can mess with, alter, corrupt, delete, etc. the archives. Then when the file is missing or broken it causes support issues for us and we get the blame. Beyond that, the sysadmin has no guarantee of an audit trail because of this.
3. There is no flexibility regarding how much logs are retained and on what schedule. If we wanted to have logs archived daily for 2 weeks we couldn't do it. Instead we will always have between a month and 2 months of stored logs. Or what if we wanted a weekly archive kept for a year for auditing purposes?
4. The current implementation is inefficient with how it stores the archives. Each month's logs are stored in a file called domain.tld-Mon-Year.gz. Because the month is all in one file, each time it archives logs it has to gunzip the archive, then append the logs, then gzip the whole thing again. For large logs this can throw a client over quota for a bit causing problems with their site and it can also load the server down when it handles that data over and over again for large numbers of accounts.
   A better way would be to have individual daily log archives that you write to once, compress, and then don't touch again.
5. Because it is a per account setting, there is no server wide setting to set a default for it. So we have to use an API call in a scripted account creation hook or something to make sure it is set up.

[Infopro]

Thank you for the clarifcation, makes sense to me now.

[Kent Brockman]

+1 for this then. Good enough

[UH-Matt]

+1 particularly due to the lack of flexibility of how much is kept how often. Currently its either nothing or 1 or 2 months worth. Other panels allow you to keep say a rolling 1 week of logs on a daily basis...

[cPanelDavidG]

Update: We are planning to accommodate syslogd for all logs relating to cPanel&WHM with exception of the Apache domlogs, as the rotation of those is associated with the generation of web statistics. However, you can use the standard hooks system in version 11.32 to customize how those logs are handled pre-rotation etc. Documentation on this can be found at Stats Functions | Standardized Hooks

[mediagenerator]

I do, in fact.

[cPanelDavidG]

We are moving towards syslogd for basically everything but domlogs, so I'm merging this with our other syslogd thread.