[patch] new feature for file destination: persistent symlinks
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.
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 <syslog-ng-bounces@lists.balabit.hu> on behalf of a.biardi@tiscali.it <a.biardi@tiscali.it> Sent: Saturday, December 4, 2021 15:29 To: syslog-ng@lists.balabit.hu <syslog-ng@lists.balabit.hu> 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.
Perhaps the symbolic link name can also permit macros, so for a destination that is partially time based and host/program based you can have a specific symlink. For example: Destination name $HOST.$YEAR.$MONTH.$DAY.$HOUR Symblic link $HOST.latest Just thinking out loud. Evan On 2021-12-05 08:49, Gabor Nagy (gnagy) wrote:
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 <syslog-ng-bounces@lists.balabit.hu> on behalf of a.biardi@tiscali.it <a.biardi@tiscali.it> *Sent:* Saturday, December 4, 2021 15:29 *To:* syslog-ng@lists.balabit.hu <syslog-ng@lists.balabit.hu> *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.
______________________________________________________________________________ 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 Sun, 5 Dec 2021 09:35:25 -0800, Evan Rempel <erempel@uvic.ca> wrote:
Perhaps the symbolic link name can also permit macros, so for a destination that is partially time based and host/program based you can have a specific symlink.
For example:
Destination name $HOST.$YEAR.$MONTH.$DAY.$HOUR Symblic link $HOST.latest
Just thinking out loud.
Evan
Hi Evan, Thanks for the suggestion, hadn't thought of that. Not sure if there's a usecase for that kind of setup, it definitely is outside the scope of my proposal and probably beyond my abilities as well -- I'll leave that for others to decide. Andrea.
Thanks for opening a PR! We will continue the review on GitHub! Regards, Gábor
participants (3)
-
a.biardi＠tiscali.it
-
Evan Rempel
-
Gabor Nagy (gnagy)