Would this allow us to leave multiple pipes open? What I'm working on... is using RabbitMQ for input/output and having a single Input-queue and multiple-output queues (e.g. automation queue, notification-queue, incident-queue).
-----Original Message----- From: Risto Vaarandi [mailto:risto.vaara...@seb.ee] Sent: Wednesday, February 06, 2013 9:38 AM To: Simple-evcorr-users Subject: [Simple-evcorr-users] extending output types hi all, as you know, currently there are number of outputs which are not directly supported by sec. For example, with 'pipe' action one can feed only one event to an external program (with most programs exiting after the 'pipe' action closes the pipe). Also, the 'write' action opens a given file before each access and closes it afterwards. While this makes output file rotation worry-free, it is not very efficient. Finally, sec does not directly support various sockets as output (for example, it is not possible to connect directly to a syslog server on another host and issue syslog events without any intermediaries). Therefore, would there be any interest to an output action which would leave the output open/running/connected, so that the next access of the same output would not have to do reopen/restart/connect again? This action would have to support a number of output types, e.g., write2 udp myserver:514 This is my event write2 tcp myserver:514 Another event write2 file /var/log/myevents Third event write2 program /bin/logger -p user.notice Fourth event It is probably easy to see that with sockets and files it is not that hard to distinguish them from each other, since the filename or server name plus port number can serve as unique identifiers. With command lines, however, it is somewhat more difficult, since an extra space or different ordering of options makes two command lines different, even if their effect is exactly the same. Also, since sec uses positional parameters, there is an issue with parsing, although this could be solved with the use of (). In addition, one workaround for both issues would be storing command line in an action list variable. The action outlines above would also need an output rotation mechanism, but this could be implemented with adding this to SIGUSR2 handler (closing all currently open outputs). Would the action above be of interest, and are there any other ideas for handling these situations? kind regards, risto ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
