On Wed, 4 Nov 2009, Rainer Gerhards wrote: >>> The problem is that you would not get the information BEFORE you >> turned in >>> on. In theory, it should even be possible with the current system and >> a file, >>> but I need to check this out (I never used it that way, but the >> engine >>> probably is capable of doing it). >> >> yes, this would not help see what triggered the problem, but could be a >> huge help in figuring out what the current state of things are. > > definitely > >> going to a file could work as well. in either case a config option >> would >> have to be created to specify the destination. > > traditionally, this is done via environment options, please see: > > http://www.rsyslog.com/doc-debug.html > > It may very well work just be specifying a file and sending SIGUSR1 - but I > have never tried that in a production run (which also means I *never* tested > it). > > When I added this mechanism, I selected envrionment variables because that > enables to change the settings without touching the config file. Obviously it > wouldn't be much of a problem to create config options for them as well.
given that in a production environment, rsyslog is started from an init script of some sort, setting environment variables before it starts is just editing a different config file. it would probably be much better to have it in the rsyslog config than to hunt down the correct (distro specific) init file and edit it to set an environemnt variable there. >>> NO, that's the point. If we intend to pursue that path, imdiag always >> needs >>> to be loaded. That does not have any performance impact (but a >> security >>> impact!). Once imdiag is loaded, it could be used to do all sorts of >>> "interesting" things (most of which need to be implemented first...). >> >> it all depends on what imdiag can do, and where the control signals >> come >> from. if the contol is via normal syslog messages it is a problem, on >> the >> other hand if it creates a new socket that it listens on that can only >> be >> written to by root it's probably far less of a problem. >> >> I guess the real response is that I don't know enough about imdiag to >> know >> the risks. > > Most of that needs to be written, so we can specify what is acceptable. So > far it listens to a network socket. This was intended so that testcases can > be build without the need to fiddle with local socket creation policies. One > potential was would also to selectively enable/disable imdiag functionality > inside the config file. > > The GUI front-end I (barely) started to write talks to imdiag, but this is > not really anything decent so far. In the long term, I'd like to be able to > pull things like queue status, modules loaded, action status and the like > from a running instance as well as inject not only messages but change some > settings on the fly. My initial need was to provide a consistent rsyslog/UDP > monitoring solution (for performance testing) as well as problem analysis. in a production environement you may not be able to use a GUI, and a network socket (on anything other than localhost) is definantly a problem. if you have it create a network listener on localhost that can be connected to via telnet it's not nearly as big of a security problem. then it can be scripted or a user can cut-n-paste to it while still allowing a nice GUI (or text based equivalent) to be created as time permits. but for now just use a simple line-based interface and it would be usable. if the listening address and port are configurable you can have the address default to 127.0.0.1 (relativly safe), but be configurable to 0.0.0.0 so that you can hit it over the network with other machines as needed. David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
