| |||||||||||||
Stepping closer to practical containers: "syslog" namespacesStepping closer to practical containers: "syslog" namespacesPosted Dec 13, 2012 5:41 UTC (Thu) by eternaleye (guest, #67051)In reply to: Stepping closer to practical containers: "syslog" namespaces by eternaleye Parent article: Stepping closer to practical containers: "syslog" namespaces
Ah, looks like I misread your statement, and you were suggesting that the initial namespace's syslog daemon would redispatch to containers. That makes more sense, but it also increases the maintenance burden - you need a way of mapping the tags to the delivery endpoint of the syslog daemon in the container, and it still will be apparent that the source is an external syslog daemon (tcp, udp, what have you) rather than fulfilling the stated goal of the container appearing to be a fully isolated system.
(Log in to post comments)
Stepping closer to practical containers: "syslog" namespaces Posted Dec 13, 2012 9:43 UTC (Thu) by nlucas (subscriber, #33793) [Link]
You will already need to do that if you do it on the kernel, and it would be more difficult to modify the mapping (and puts policy on the kernel). The only difference is the kernel now doesn't need to have a default policy (it doesn't break anything because it's a new feature). The default can just be that all containers start in the same "syslog" namespace (like now).
As for not being transparent, I'm talking of a ring-buffer per container, so it's fully transparent for the applications. dmesg will output the namespace ring-buffer contents.
The initial namespace "syslog" daemon would dispatch messages from the unfiltered ring-buffer to the other namespaces ring-buffers. The difference would be that the syslog(2) syscall would be namespace aware and return messages only from the current namespace ring-buffer.
|
|||||||||||||