I had an interesting enhancement request these days: make rsyslog emit a real interface address with local-generated messages (inside the fromhost-ip property). Until now, rsyslog always uses the localhost IP (127.0.0.1) when it talks of the local machine being the message source. This request makes a lot of sense and I wonder that I didn't receive it earlier.
We started with the imuxsock module, quickly followed by imklog ... and now some other internal message sources. Thinking of a local "problem" I so far have integrated the functionality into each plugin in question. It works via config directives, which enable to tell which interface's (e.g. eth0) IP is to be used. If not specified, we default back to "127.0.0.1", especially important for backward compatibility reasons (this change could cause a lot of harm to analysis tools!).
The current work can be found in the git v5-devel branch. However, the approach seems to be unsatisfactory: it looks like it is the right path to permit each message source to grab a real IP address. With the way it is currently done, the code for doing that needs to be replicated to all sources. That doesn't look very smart.
So I am thinking about refactoring the refactored code ;) The core idea is that a single global function could be used to provide the local IP. Then, each plugin could query that function when it needs to know the local IP (much in the same way this currently happens for the hostname). The drawback of this approach is that only a single IP can be used across all sources. Is that a problem or a feature? Please provide comments! Also, in pre-v6 the config may be somewhat inconsistent depending on where the interface setting is made. The reason is that in pre-v6 we do not have a clear point where we know the config is fully processed (but I may somewhat work around this inside the plugins themselves). Note that this is similar to the max message size config ugliness, where the size must be set right at the top of rsyslog.conf to work properly across all modules (and this causes confusion every now and then). In v6 (6.3 and above to be precise) this is no problem due to the enhanced and much more structured config processing.
Please let me know your thoughts about this issue, so that I can take the right direction!