Output to file in /proc
Hello list, As most of the functionality of "sshguard", "fail2ban" and others is in syslog-ng, I'm trying to use syslog-ng to add entries to my Linux kernel based firewall (iptables). I'm almost ready to implement one, but I have a question about undeliverable log lines: what happens if a certain file() destination blocks? Will syslog-ng retry to deliver the same message, or will it lose the message? What I'm doing is using the "ipt_recent" module; with this module, one can check if a certain IP address was seen before. For example, the following rule will block you if you were seen 5 or more times ("hitcount 5") in the "violators" list last minute ("seconds 60): iptables -A INPUT -m recent \ --rcheck --hitcount 5 --seconds 60 --name violators -j DROP The fun part is, that you can add IP adresses by stuffing them into a file in /proc: echo '+127.0.0.1' > /proc/net/xt_recent/violators ... will add 127.0.0.1 to the "violators" with the current time. However: echo 'whatever' > /proc/net/xt_recent/violators ... gives an error: Invalid argument (22) As far as I can see, syslog-ng will not try again to deliver the same message; but is this by design? I.e. can I trust syslog-ng to not "block" because of a single malformed IP address? Because then, an implementation of sshguard could be simply swapped with a simple: destination df_ipt_recent { file ("/proc/net/xt_recent/blocker" template("+${usracct.device}\n") ); }; filter f_ipt_recent { tags("secevt") and match("REJECT" value("secevt.verdict")); }; log { source (s_all); parser(pattern_db); filter(f_addtofirewall);destination(df_addtofirewall);}; ... which would be cool! Best regards, Valentijn
On Thu, 2011-02-17 at 16:02 +0100, Valentijn Sessink wrote:
Hello list,
As most of the functionality of "sshguard", "fail2ban" and others is in syslog-ng, I'm trying to use syslog-ng to add entries to my Linux kernel based firewall (iptables).
I'm almost ready to implement one, but I have a question about undeliverable log lines: what happens if a certain file() destination blocks? Will syslog-ng retry to deliver the same message, or will it lose the message?
What I'm doing is using the "ipt_recent" module; with this module, one can check if a certain IP address was seen before. For example, the following rule will block you if you were seen 5 or more times ("hitcount 5") in the "violators" list last minute ("seconds 60):
iptables -A INPUT -m recent \ --rcheck --hitcount 5 --seconds 60 --name violators -j DROP
The fun part is, that you can add IP adresses by stuffing them into a file in /proc: echo '+127.0.0.1' > /proc/net/xt_recent/violators ... will add 127.0.0.1 to the "violators" with the current time.
However: echo 'whatever' > /proc/net/xt_recent/violators ... gives an error: Invalid argument (22)
As far as I can see, syslog-ng will not try again to deliver the same message; but is this by design? I.e. can I trust syslog-ng to not "block" because of a single malformed IP address?
if a write error occurs, syslog-ng suspends the destination question for time_reopen() amount of time, then will try to write it again with the last unsuccessful write. which will probably cause the same error message to be returned... do you perhaps have a suggestion what we should do instead? bear in mind that we have to handle ENOSPC (=disk full) errors properly. -- Bazsi
Balazs Scheidler schreef:
On Thu, 2011-02-17 at 16:02 +0100, Valentijn Sessink wrote:
As far as I can see, syslog-ng will not try again to deliver the same message; but is this by design? I.e. can I trust syslog-ng to not "block" because of a single malformed IP address? if a write error occurs, syslog-ng suspends the destination question for time_reopen() amount of time, then will try to write it again with the last unsuccessful write.
That is rather weird, because it's not what I'm seeing: I do see the time_reopen() messages, but after that, syslog-ng doesn't try to deliver the same message. I used the following pattern to be able to generate wrong messages: <?xml version='1.0' encoding='UTF-8'?> <patterndb version='3' pub_date='2011-02-16'> <ruleset name='valentyn' id='07d59af0-65ff-c847-9c07-ef69fa8cf50e'> <description> This ruleset covers valentyn </description> <pattern>valentyn</pattern> <rules> <rule id='foo' class="logger"> <patterns> <pattern>foo</pattern> </patterns> <values> <value name="usracct.type">login</value> <value name="usracct.sessionid">$PID</value> <value name="usracct.application">$PROGRAM</value> <value name="secevt.verdict">REJECT</value> <value name="usracct.device">KANARIE</value> </values> <tags> <tag>usracct</tag> <tag>secevt</tag> </tags> </rule> </rules> </ruleset> </patterndb> Now you can spoil your xt_recent destination with the following command: logger -t valentyn "foo bar baz" As far as I can see, syslog-ng does NOT try to re-deliver the message.
do you perhaps have a suggestion what we should do instead? bear in mind that we have to handle ENOSPC (=disk full) errors properly.
Maybe a "lost messages is not a problem" flag for certain destinations? I'm not sure. Also, whenever $usracct.device contains an IP address, there is no problem. But the larger the patterndb grows, the greater the chance that a wrong pattern slips through... Best regards, Valentijn -- http://www.openoffice.nl/ Open Office - Linux Office Solutions Valentijn Sessink v.sessink@openoffice.nl +31(0)20-4214059
On Wed, 2011-02-23 at 18:50 +0100, Valentijn Sessink wrote:
Balazs Scheidler schreef:
On Thu, 2011-02-17 at 16:02 +0100, Valentijn Sessink wrote:
As far as I can see, syslog-ng will not try again to deliver the same message; but is this by design? I.e. can I trust syslog-ng to not "block" because of a single malformed IP address? if a write error occurs, syslog-ng suspends the destination question for time_reopen() amount of time, then will try to write it again with the last unsuccessful write.
That is rather weird, because it's not what I'm seeing: I do see the time_reopen() messages, but after that, syslog-ng doesn't try to deliver the same message. I used the following pattern to be able to generate wrong messages:
<?xml version='1.0' encoding='UTF-8'?> <patterndb version='3' pub_date='2011-02-16'> <ruleset name='valentyn' id='07d59af0-65ff-c847-9c07-ef69fa8cf50e'> <description> This ruleset covers valentyn </description> <pattern>valentyn</pattern> <rules> <rule id='foo' class="logger"> <patterns> <pattern>foo</pattern> </patterns> <values> <value name="usracct.type">login</value> <value name="usracct.sessionid">$PID</value> <value name="usracct.application">$PROGRAM</value> <value name="secevt.verdict">REJECT</value> <value name="usracct.device">KANARIE</value> </values> <tags> <tag>usracct</tag> <tag>secevt</tag> </tags> </rule> </rules> </ruleset> </patterndb>
Now you can spoil your xt_recent destination with the following command: logger -t valentyn "foo bar baz"
As far as I can see, syslog-ng does NOT try to re-deliver the message.
It depends on what the write() syscall returns to syslog-ng. The only way to check that is to use strace on the syslog-ng process and see if writing the proc file returns failure on write or not. -- Bazsi
Op 01-03-11 22:40, Balazs Scheidler schreef:
It depends on what the write() syscall returns to syslog-ng. The only way to check that is to use strace on the syslog-ng process and see if writing the proc file returns failure on write or not.
OK, so I'm just lucky for not forcing sync() on this file. Would there be any way around this, i.e. a way to force syslog-ng to act as if a certain message has been delivered OK, without retry? Best regards, Valentijn
On Wed, 2011-03-02 at 07:31 +0100, Valentijn Sessink wrote:
Op 01-03-11 22:40, Balazs Scheidler schreef:
It depends on what the write() syscall returns to syslog-ng. The only way to check that is to use strace on the syslog-ng process and see if writing the proc file returns failure on write or not.
OK, so I'm just lucky for not forcing sync() on this file.
Would there be any way around this, i.e. a way to force syslog-ng to act as if a certain message has been delivered OK, without retry?
well, not currently. But with this patch it can: commit bae327dc1754909bba62b09c7a5dda6dadf534eb Author: Balazs Scheidler <bazsi@balabit.hu> Date: Wed Mar 2 10:42:17 2011 +0100 LogWriter: added support for a new flag 'ignore-errors' This flag make syslog-ng ignore write errors, since in special cases a write error may indicate a temporary failure related to the current message being written out. Such an example is /proc/net/xt_recent/violators, where an ill formatted message will cause a write error, but suspending the destination because of that is not good. The LogWriter will cancel the complete I/O operation, e.g. it is not recommended to use flush_lines() or any other kind of write coalescing. Reported-By: Valentijn Sessink <valentyn@blub.net> Signed-off-by: Balazs Scheidler <bazsi@balabit.hu> It is on 3.3 currently, but should probably be quite easy to backport it to 3.2 -- Bazsi
Hi Balázs,
LogWriter: added support for a new flag 'ignore-errors'
Unfortunately, I can't get syslog-ng to re-write a broken message, even with fsync(yes). However, with your patch, it feels safer, because *if* a blocking message would be there, it would be ignored from now on. On 02-03-11 10:42, Balazs Scheidler wrote:
It is on 3.3 currently, but should probably be quite easy to backport it to 3.2
Yes, that was easy. For those interested: diff --git a/lib/logwriter.c b/lib/logwriter.c index b14cb57..968d22b 100644 --- a/lib/logwriter.c +++ b/lib/logwriter.c @@ -731,10 +731,18 @@ log_writer_flush(LogWriter *self, gboolean flush_all) status = log_proto_post(proto, (guchar *) line->str, line->len, &cons if (status == LPS_ERROR) { - msg_set_context(NULL); - g_string_free(line, TRUE); - return FALSE; - } + if ((self->options->options & LWO_IGNORE_ERRORS) == 0) + { + msg_set_context(NULL); + g_string_free(line, TRUE); + return FALSE; + } + else + { + consumed = TRUE; + g_free(line->str); + } + } if (consumed) { line->str = g_malloc0(1); @@ -991,6 +999,8 @@ log_writer_options_lookup_flag(const gchar *flag) return LWO_SYSLOG_PROTOCOL; if (strcmp(flag, "no-multi-line") == 0 || strcmp(flag, "no_multi_line") == 0) return LWO_NO_MULTI_LINE; + if (strcmp(flag, "ignore-errors") == 0 || strcmp(flag, "ignore_errors") == 0) + return LWO_IGNORE_ERRORS; msg_error("Unknown dest writer flag", evt_tag_str("flag", flag), NULL); return 0; } diff --git a/lib/logwriter.h b/lib/logwriter.h index 46244f4..7a316a1 100644 --- a/lib/logwriter.h +++ b/lib/logwriter.h @@ -45,6 +45,7 @@ #define LWO_NO_STATS 0x0004 /* several writers use the same counter */ #define LWO_SHARE_STATS 0x0008 +#define LWO_IGNORE_ERRORS 0x0020 typedef struct _LogWriterOptions {
On Wed, 2011-03-02 at 12:28 +0100, Valentijn Sessink wrote:
Hi Balázs,
LogWriter: added support for a new flag 'ignore-errors'
Unfortunately, I can't get syslog-ng to re-write a broken message, even with fsync(yes). However, with your patch, it feels safer, because *if* a blocking message would be there, it would be ignored from now on.
did you check that with strace? I now checked the kernel source, and the recent match really seems to error out on invalid formats with EINVAL. I'd really like to know what is going on, syslog-ng should try that operation again, and it feels like a bug. -- Bazsi
On Wed, Mar 02, 2011 at 05:55:54PM +0100, Balazs Scheidler wrote:
On Wed, 2011-03-02 at 12:28 +0100, Valentijn Sessink wrote:
Hi Balázs,
LogWriter: added support for a new flag 'ignore-errors'
Unfortunately, I can't get syslog-ng to re-write a broken message, even with fsync(yes). However, with your patch, it feels safer, because *if* a blocking message would be there, it would be ignored from now on.
did you check that with strace?
I now checked the kernel source, and the recent match really seems to error out on invalid formats with EINVAL.
I'd really like to know what is going on, syslog-ng should try that operation again, and it feels like a bug.
Could the problems be prevented by using a PCRE rule to verify the message passes a regex format validity filter before kicking it into the file? Matthew.
On Wed, 2011-03-02 at 09:10 -0800, Matthew Hall wrote:
On Wed, Mar 02, 2011 at 05:55:54PM +0100, Balazs Scheidler wrote:
On Wed, 2011-03-02 at 12:28 +0100, Valentijn Sessink wrote:
Hi Balázs,
LogWriter: added support for a new flag 'ignore-errors'
Unfortunately, I can't get syslog-ng to re-write a broken message, even with fsync(yes). However, with your patch, it feels safer, because *if* a blocking message would be there, it would be ignored from now on.
did you check that with strace?
I now checked the kernel source, and the recent match really seems to error out on invalid formats with EINVAL.
I'd really like to know what is going on, syslog-ng should try that operation again, and it feels like a bug.
Could the problems be prevented by using a PCRE rule to verify the message passes a regex format validity filter before kicking it into the file?
yes, sure that could be possible. -- Bazsi
Op 02-03-11 18:10, Matthew Hall schreef:
Could the problems be prevented by using a PCRE rule to verify the message passes a regex format validity filter before kicking it into the file?
Preventing non-IP-addresses to be entered - yes. However, you still rather would not want any message re-delivered here, because it has a different meaning ("I saw you do that twice!"). I know it's rather theoretical for now as we don't have spurious non-IP-addresses in the logs. Also, the kernel seems to have secret measures to get rid of unwanted messages as well ;) V.
Hello list, I'm replying to a 2 year old issue - now it has become a problem :-S I'm using syslog-ng to file() messages into /proc/net/xt_recent/violators. This used to work well in version 3.1.2-1~lucid1 (Ubuntu 10.04), but now, in 3.3.4.dfsg-2ubuntu1 (Ubuntu 12.04), I get: Aug 27 13:01:55 duikboot syslog-ng[13037]: I/O error occurred while writing; fd='23', error='Illegal seek (29)' Aug 27 13:01:55 duikboot syslog-ng[13037]: Suspending write operation because of an I/O error; fd='23', time_reopen='60' This is probably because the /proc/net/xt_recent/somefile isn't a real file. However, I can't find what to do about this. Is there a special setup that makes it possible to use file() for files in /proc? Background: We use syslog-ng to protect our servers, with the following setup: iptables -A INPUT -m recent \ --rcheck --hitcount 5 --seconds 60 --name violators -j DROP You can add IP adresses by stuffing them into a file in /proc: echo '+127.0.0.1' > /proc/net/xt_recent/violators ... will add 127.0.0.1 to the "violators" with the current time. Syslog-ng does this for me, based on the following configuration options: destination df_ipt_recent { file ("/proc/net/xt_recent/violator" template("+${usracct.device}\n") ); }; filter f_ipt_recent { tags("secevt") and match("REJECT" value("secevt.verdict")); }; log { source (s_all); parser(pattern_db); filter(f_addtofirewall);destination(df_addtofirewall);}; As said, this issue has been discussed before, in a somewhat different form; the problem back then wasn't the seek() error. See my message on this mailing list on 17-02-11 16:02. Best regards, Valentijn
Valentijn Sessink <valentyn@blub.net> writes:
I'm replying to a 2 year old issue - now it has become a problem :-S
I'm using syslog-ng to file() messages into /proc/net/xt_recent/violators. This used to work well in version 3.1.2-1~lucid1 (Ubuntu 10.04), but now, in 3.3.4.dfsg-2ubuntu1 (Ubuntu 12.04), I get:
Aug 27 13:01:55 duikboot syslog-ng[13037]: I/O error occurred while writing; fd='23', error='Illegal seek (29)' Aug 27 13:01:55 duikboot syslog-ng[13037]: Suspending write operation because of an I/O error; fd='23', time_reopen='60'
This is probably because the /proc/net/xt_recent/somefile isn't a real file.
This has been fixed in 3.4's git tree, and will be part of 3.4.4 release. I do not plan to backport it to 3.3. Debian packages for 3.4.4 will be provided at the usual place[1]. [1]: http://asylum.madhouse-project.org/projects/debian/ Thanks for the report, and to Bazsi for the fix! -- |8]
Hi Balazs, hi Gergely, hello list, Thanks for the fix - now I see a "lseek(self->fd, 0, SEEK_SET)", but doesn't that mean that all logfiles will be truncated? (Sorry, as you can see I'm not much of a programmer, so I'm probably talking garbage, just wondering...) Best regards, Valentijn On 04-09-13 14:40, Gergely Nagy wrote:
This has been fixed in 3.4's git tree, and will be part of 3.4.4
-- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579
On 04-09-13 14:40, Gergely Nagy wrote:
This has been fixed in 3.4's git tree, and will be part of 3.4.4 release.
I tried it, but it doesn't seem to help. There's something weird about the xt_recent.c file handling. I tried to understand it's source, but I couldn't find out. It seems that *loff is different from file->f_pos, and can't be simply changed with lseek(). Bottom line is, that although *loff should be 0, an lseek() will not help. So I kindly suggest: please revert any changes that you made to accomodate to this /proc thing - they are of no use, at this moment. For now, xt_recent should be written with single lines only, open()-write()-close() and repeat. Even using program("cat > ....") doesn't work correctly; it will write the first IP address, then fail with the second, bail out, and syslog_ng will start another cat to write the next IP-address. "most proc files support only one-shot writes" is what I learned from someone at #kernelnewbies, so that's probably the final word on this. I think the best thing is using some sort of piping program in between; I'm not sure what I'm going to use - should any of you readers have a good idea, please say so. After a couple of days of trying to grasp xt_recent.c in combination with syslog-ng file() - without avail :-( - I'm going to have a beer. That won't help my logging, but it will help my mood! Happy friday afternoon, dear fellow Europeans ;-) and have a nice weekend for all of you. Best regards, Valentijn
I think we could accomodate this use case with a separate driver/scl snippet. Smtg like Destination { procfile(...) }; What options eould you think are needed in this usecase) On Sep 6, 2013 5:43 PM, "Valentijn Sessink" <valentyn@blub.net> wrote:
On 04-09-13 14:40, Gergely Nagy wrote:
This has been fixed in 3.4's git tree, and will be part of 3.4.4 release.
I tried it, but it doesn't seem to help. There's something weird about the xt_recent.c file handling. I tried to understand it's source, but I couldn't find out. It seems that *loff is different from file->f_pos, and can't be simply changed with lseek().
Bottom line is, that although *loff should be 0, an lseek() will not help.
So I kindly suggest: please revert any changes that you made to accomodate to this /proc thing - they are of no use, at this moment.
For now, xt_recent should be written with single lines only, open()-write()-close() and repeat. Even using program("cat > ....") doesn't work correctly; it will write the first IP address, then fail with the second, bail out, and syslog_ng will start another cat to write the next IP-address.
"most proc files support only one-shot writes" is what I learned from someone at #kernelnewbies, so that's probably the final word on this.
I think the best thing is using some sort of piping program in between; I'm not sure what I'm going to use - should any of you readers have a good idea, please say so.
After a couple of days of trying to grasp xt_recent.c in combination with syslog-ng file() - without avail :-( - I'm going to have a beer. That won't help my logging, but it will help my mood! Happy friday afternoon, dear fellow Europeans ;-) and have a nice weekend for all of you.
Best regards,
Valentijn
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
Couldn't you just use flush_lines(1) for that destination? Evan Rempel 250.271.7691 University Systems, University of Victoria Balazs Scheidler <bazsi77@gmail.com> wrote: I think we could accomodate this use case with a separate driver/scl snippet. Smtg like Destination { procfile(...) }; What options eould you think are needed in this usecase) On Sep 6, 2013 5:43 PM, "Valentijn Sessink" <valentyn@blub.net<mailto:valentyn@blub.net>> wrote: On 04-09-13 14:40, Gergely Nagy wrote:
This has been fixed in 3.4's git tree, and will be part of 3.4.4 release.
I tried it, but it doesn't seem to help. There's something weird about the xt_recent.c file handling. I tried to understand it's source, but I couldn't find out. It seems that *loff is different from file->f_pos, and can't be simply changed with lseek(). Bottom line is, that although *loff should be 0, an lseek() will not help. So I kindly suggest: please revert any changes that you made to accomodate to this /proc thing - they are of no use, at this moment. For now, xt_recent should be written with single lines only, open()-write()-close() and repeat. Even using program("cat > ....") doesn't work correctly; it will write the first IP address, then fail with the second, bail out, and syslog_ng will start another cat to write the next IP-address. "most proc files support only one-shot writes" is what I learned from someone at #kernelnewbies, so that's probably the final word on this. I think the best thing is using some sort of piping program in between; I'm not sure what I'm going to use - should any of you readers have a good idea, please say so. After a couple of days of trying to grasp xt_recent.c in combination with syslog-ng file() - without avail :-( - I'm going to have a beer. That won't help my logging, but it will help my mood! Happy friday afternoon, dear fellow Europeans ;-) and have a nice weekend for all of you. Best regards, Valentijn ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
On 07-09-13 16:12, Evan Rempel wrote:
Couldn't you just use flush_lines(1) for that destination?
No, the problem is with the file (write-)pointer; the kernel source wants it to be 0, otherwise an error will occur. This means, in a nutshell, that you must open()-write()-close() the destination. flush_lines(1) doesn't do that. Something like "time_reap(0)" ("close destination file after 0 seconds") could do this theoretically, but I don't think bending the configuration this much is feasible... Best regards, Valentijn
Could the file be kept open but lseek(0) before each write, rather than lseek("end") before each write? Perhaps a flag to seek to the beginning (rewrite(true) ) would work as a concept. On 09/09/2013 01:37 AM, Valentijn Sessink wrote:
On 07-09-13 16:12, Evan Rempel wrote:
Couldn't you just use flush_lines(1) for that destination?
No, the problem is with the file (write-)pointer; the kernel source wants it to be 0, otherwise an error will occur.
This means, in a nutshell, that you must open()-write()-close() the destination.
flush_lines(1) doesn't do that.
Something like "time_reap(0)" ("close destination file after 0 seconds") could do this theoretically, but I don't think bending the configuration this much is feasible...
Best regards,
Valentijn ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
-- Evan Rempel erempel@uvic.ca Senior Systems Administrator 250.721.7691 Data Centre Services, University Systems, University of Victoria
Hi Evan, Unfortunately: On 09-09-13 17:28, Evan Rempel wrote:
Could the file be kept open but lseek(0) before each write, rather than lseek("end") before each write?
No. That's what I thought after looking in the xt_recent.c source. But unfortunately, lseek() seems to alter the file reading position, but not the writing position. See here the strange effects: https://plus.google.com/109970014070894558897/posts/bX35vy6s1mS I even compiled a version with lseek(..,0,0) instead of (..0,2), but it did not function.
Perhaps a flag to seek to the beginning (rewrite(true) ) would work as a concept.
lseek() doesn't work, due to a half baked implementation in /proc. (Sorry for the misunderstanding; part of this discussion was off-list between Balasz and me, he most generously patched syslog-ng for me but it didn't work). Best regards, Valentijn
Hi Balazs, On 07-09-13 07:22, Balazs Scheidler wrote:
I think we could accomodate this use case with a separate driver/scl snippet.
Smtg like
Destination { procfile(...) };
What options eould you think are needed in this usecase)
Well, the only somewhat important thing I can think of is what to do when errors occur: - an option to keep messages until the /proc file comes into existence, or to throw them away. This means ignoring or reacting on errors during the open() phase of writing the message to /proc - an option that tells syslog-ng to ignore write errors, i.e. during the write() phase. Normally, syslog-ng queues any writes that did not succeed, but in this case, you most likely want to ignore writing errors. You might even want to ignore them really, really thoroughly (i.e. without an internal error), or ignore them - but do log them internally. Being able to ignore write errors is vital, IMHO, because otherwise a single write error will basically just stop the rest of the messages, i.e. kill the proc-writing. Also, for /proc output to be useful, you're going to need template(). I think log_fifo_size() could come in handy, too. Maybe throttle() is of some use. I don't think the other options in file() are necessary: things like flush_lines, fsync, various time-zone-options, uid, gid and permission stuff, mark_mode (should be "none"), various create_ and overwrite options are all unnecessary when writing to /proc, I think. (As a side note: back in 2011 you had this "ignore-errors" flag, in commit bae327dc1754909bba62b09c7a5dda6dadf534eb, for the very same reason; I'm not sure if it's still there, but if it is: I don't think it's documented...) I hope the above is of use. I'd be happy to try things out. Best regards, Valentijn
Hello Balazs, Just wondering, is there any news on the "procfile()" destination? Best regards, Valentijn On 07-09-13 07:22, Balazs Scheidler wrote:
I think we could accomodate this use case with a separate driver/scl snippet.
Smtg like
Destination { procfile(...) }; -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579
Valentijn Sessink <valentyn@blub.net> writes:
Hello Balazs,
Just wondering, is there any news on the "procfile()" destination?
Not yet, but I'll try to squeeze something into the next 3.5 beta. -- |8]
Hi list, Gergely, Balazs, ... is anything happening on the procfile() destination? Or did this end up somewhere deep down under a stack of more important things ;-) ? Best regards, Valentijn On 27-09-13 16:39, Gergely Nagy wrote:
Valentijn Sessink <valentyn@blub.net> writes:
Just wondering, is there any news on the "procfile()" destination? Not yet, but I'll try to squeeze something into the next 3.5 beta.
I have something in the works, but not ready yet. Ill keep you posted. On Dec 6, 2013 5:34 PM, "Valentijn Sessink" <valentyn@blub.net> wrote:
Hi list, Gergely, Balazs,
... is anything happening on the procfile() destination? Or did this end up somewhere deep down under a stack of more important things ;-) ?
Best regards,
Valentijn
On 27-09-13 16:39, Gergely Nagy wrote:
Valentijn Sessink <valentyn@blub.net> writes:
Just wondering, is there any news on the "procfile()" destination? Not yet, but I'll try to squeeze something into the next 3.5 beta.
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
Hi, There's an implementation of the procfile destination in 3.6/f/procfile branch on github. I'd like some feedback before integrating it, but I'll send my questions in a separate email. On Tue, 2013-12-10 at 22:58 +0100, Balazs Scheidler wrote:
I have something in the works, but not ready yet.
Ill keep you posted.
On Dec 6, 2013 5:34 PM, "Valentijn Sessink" <valentyn@blub.net> wrote: Hi list, Gergely, Balazs,
... is anything happening on the procfile() destination? Or did this end up somewhere deep down under a stack of more important things ;-) ?
Best regards,
Valentijn
On 27-09-13 16:39, Gergely Nagy wrote: > Valentijn Sessink <valentyn@blub.net> writes: >> Just wondering, is there any news on the "procfile()" destination? > Not yet, but I'll try to squeeze something into the next 3.5 beta. ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
participants (6)
-
Balazs Scheidler
-
Balazs Scheidler
-
Evan Rempel
-
Gergely Nagy
-
Matthew Hall
-
Valentijn Sessink