On Tue, 22 Nov 2016, Rich Megginson wrote:
On 11/22/2016 09:27 AM, David Lang wrote:
On Tue, 22 Nov 2016, Rich Megginson wrote:
Then can it be made a dynamically loadable module? Same with every module
- is there a way to build them and provide them so that they are not part
of the base rsyslog executable/library?
All of this can be done, it's just a matter of how the packages are
compiled and the command line used to start it
But it's a bunch of stuff that makes me think it's a bad idea to try to do
this in the main rsyslog package.
what modules to include by default
what config file to open by default
all these things can be set at compile time, and that's why I'm saying that
a new package with a slightly different name that has different defaults
may be the answer.
Having done a lot of package maintenance for Fedora/EPEL/RHEL, I would rather
not have two slightly different versions of rsyslog packages . . .
I understand, but I'm trying to make something that can be looked at as if it
was a completely separate program, and operates independently from any syslog
daemon on the system.
Ideally something that could have a trival command line like
logsend /path/to/file destination
where destination only needs to be specified the first time, and must be the
same for all files.
This is a combination of simpler configs and possibly a wrapper around rsyslog.
The idea is to make it trivial to use for the simple use-case, while still
having the power available under the covers as needs grow more complex.
IMHO, The biggest problem with using rsyslog to do this is the same
problem we have with using rsyslog to create /dev/log in containers,
the fact that the config is fixed at startup time.
Can you explain more about what you mean by this?
rsyslog can create additional /dev/log equivalent sockets, and as such,
you could create them in each container so that there is no need for a
copy of rsyslog in each container.
What if the container could mount the /dev/log from the host?
You could do a bind mount in each container (something I hadn't thought
of), but then rsyslog can't tell which container the message comes from.
IMHO, that's valuable metadata that I want to know.
So if there were a way to get container metadata this way, it would be a
viable solution?
possibly, I'm having to think hard about this and don't see how you would get
the metadata.
the path of the socket you get it from wouldn't help, because rsyslog would see
them all as the /dev/log in the host OS.
SCM_Credentials may be able to do something here, but it would have to get info
on the container namespaces, which starts getting ugly.
It seems much easier to have the ability to do something like
rsyslog-ctl add --name "container1" /containers/foo/dev/log
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
