On Mon, 6 Dec 2021 15:28:18 +0000, "Gabor Nagy (gnagy)"
<[email protected]> wrote:
> Dear Andrea!
>
> I'm forwarding my answer to make sure you get it anyway.
> Looking forward to hearing from you!
>
> Best Regards,
> Gábor
> ________________________________
> From: Gabor Nagy (gnagy) <[email protected]>
> Sent: Sunday, December 5, 2021 17:49
> To: Syslog-ng users' and developers' mailing list
> <[email protected]> Subject: Re: [syslog-ng] [patch] new
> feature for file destination: persistent symlinks
>
> Hello Andrea!
>
> Thank you for your contribution! We always welcome feedback and
> contribution from the community!
>
> I've quickly checked your patch, and it looks good. Maybe minor
> things could be changed, but we will see this during a thorough
> review.
>
> We integrate patches via pull requests on GitHub. [1]
> How would you like to continue this contribution?
> Would you like to open a pull request on GitHub?
>
> I see a corner case of the feature: if the filename template is not
> time-based, like e.g. $PROGRAM or $HOST, it can happen that the
> symlink is changed several times in a short time. This is not an
> argument against the feature, it's just a behaviour that should be
> considered and documented. As I see, the feature in general creates a
> symlink with the name given in "symlink_as" option when a new file is
> opened. In other words: the configured symlink always points to the
> latest file that were opened.
>
>
> Best Regards,
> Gábor
>
> [1] https://github.com/syslog-ng/syslog-ng
>
> ________________________________
> From: syslog-ng <[email protected]> on behalf of
> [email protected] <[email protected]> Sent: Saturday, December 4,
> 2021 15:29 To: [email protected] <[email protected]>
> Subject: [syslog-ng] [patch] new feature for file destination:
> persistent symlinks
>
> CAUTION: This email originated from outside of the organization. Do
> not follow guidance, click links, or open attachments unless you
> recognize the sender and know the content is safe.
>
>
> Hi all,
>
> I'm new here. I love syslog-ng: it's well written and documented and
> each time I need some new feature, I dig up the documentation and I
> find it's already implemented!
>
> Like many others, I use macros in file destinations (say,
> "/var/log/cron.${YEAR}${MONTH}"), but I also want to maintain a
> persistent symlink to the current logfile (that would be
> something like "/var/log/cron") in order to have "easier" access if
> I'm grepping for something manually.
>
> I couldn't find this feature in syslog-ng, so I wrote the code myself;
> in the configuration file, it looks like this:
>
> destination d_file_cron {
> file("/var/log/cron.${YEAR}${MONTH}" symlink_as("/var/log/cron"));
> };
>
> It works for me on my Slackware boxes. I'm sharing the patch I put
> together, hoping that it may be useful to others and perhaps even
> considered for inclusion in mainstream.
>
> From a functional perspective, the "symlink_as" file inherits both
> "create-dirs" and file ownership from its file destination
> (permissions are not applicable to symlinks, at least on linux).
>
> Patch applies cleanly to latest production release (3.33). I tried to
> keep the original coding style for easier review (admittedly, the code
> could have gone into the function that opens the file destination, but
> I didn't want to change too much).
>
> Thanks for the good work and happy logging!
>
> Andrea.
Hi Gábor,
Sorry for the delay, daytime job keeps me busy :) Will submit a PR
through github asap.
I did not consider the case where the template contains something like
$PROGRAM or $HOST. As you point out, the code wouldn't fail but you'd
get an ever-changing symlink of dubious usefulness. Worth documenting.
Cheers,
Andrea.
______________________________________________________________________________
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.