consider offering "central" (sys)log services for all jails

[igalic]

rather than having a syslog running per jail, and produces logs on that jails disk, we should consider to offer a single jail which offers (sys)log aggregation.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[foo2342]

This would still require to have a rsyslog running per jail.
In order to have central log aggregation we would need to enable rsyslog up on the host, which might be the case in the stock config on freebsd. Another approach would be to merge all the log files from the jails together from the host, which doesn't require any config change in either jails or host.

[igalic]

i would prefer to have log aggregation in a specialised jail (like kubernetes does)

but could you please describe the two scenarios that you're talking about.

[foo2342]

I agree, using a dedicated jail is the way to go. Networking between the jails is a requirement for that though. The approach i was thinking about was either setting up an rsyslog Server on the jailhost (comes with FreeBSD, just needs to be enabled), and setting up the rsyslog client in the jails to log to the jailhost. The documentation on how that’s done is included in the FreeBSD handbook: https://www.freebsd.org/doc/handbook/configtuning-syslog.html The other approach would be to read the log files from the jails within iocage, and provide a was to search though them. All of these solutions have security implications which need to be evaluated.

…

On 26. Sep 2017, at 19:56, Igor Galić ***@***.***> wrote: i would prefer to have log aggregation in a specialised jail (like kubernetes does) but could you please describe the two scenarios that you're talking about. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[skarekrow]

Correct. This should not be the default.

[gronke]

It seems to be a very common use case to configure centralized log aggregation, but I'm not sure if we should provide an interface for that. When working on #1 (Plugin Support), we could make sure there is a plugin to configure log aggregation available.