Messages

1

Documentation and Translation / Re: cron log

« on: August 25, 2024, 06:40:20 pm »

I added this config for cron support (/usr/local/etc/syslog-ng.conf.d/syslog-ng-cron.conf):

Code: [Select]

filter f_cron { facility(cron); };

destination d_local_cron {
  file(
    "/var/log/cron/cron_${YEAR}${MONTH}${DAY}.log"
    create-dirs(yes)
    flags(syslog-protocol)
  );
};

log {
  source(s_all);
  filter(f_cron);
  destination(d_local_cron);
};

Unfortunately there's no way to add this to the application list for remote logging, so you ether have to add a duplicate destination or use the generated one by opnsense:

Code: [Select]

…
  destination(d_6bf9323eda944bbd9b28befeb8e2ce55);
…


2

22.1 Legacy Series / Re: os-ddclient

« on: April 10, 2022, 04:46:22 am »

Created an account just to second this:

I wanted to say, from my point of view the ddclient is way behind what is available in the dyndns plugin and I really don't understand who made the decision and why switch to ddclient only, "the world is using it" is, I believe, not a valid reason, especially given ddclient hasn"t seen a release in over a year and ther is definitely a lot less polish and integration into opnsense.

I just wanted to list some of my gripes with the ddclient :

• there is no widget for it on the dashboard
• it does not provide a way to check that the public DNS has the proper IP
• it doesn't play nice with multi-WAN and NAT
• there is no way to force an update
• settings are less granular (general verbosity vs per account, same for checkip provider)
• not all checkip providers that were supported are still provided

There are several threads on this already, but like many others I was surprised a working and really comprehensive solution is being deprecated soon-ish (I think 6 months is inappropriate amount of time for migration) in favor of something that doesn't provide even a half of the "old" functionality. A good comparison would be how OpenBSD handles cases like this: when they rewrite something or throw away old cruft, they make sure the new candidate is better, not worse or at least on par with what the previous tool provided. I'm obviously not active in the development process, but maybe someone could clarify the urge of throwing away current dynamic DNS client now. I fail to see (even from the code maintenance perspective) the priority it's given today.

I understand the desire for OPNsense devs to offload most of maintenance/work to another project, but I don't really see ddclient as a good alternative for current phpDynDNS and what it has to offer. Not in this state. And I'm a little confused about maintenance cycle for this choice then: if OPNsense decided to add missing providers or functionality to the list themselves, will the patches go upstream? Given low maintenance for ddclient (also this), if there's a strategic decision has to be made in the end and current DynDNS client to be deprecated for good, I think inadyn would be a better option (simply because it's Joachim Wiberg – many abandoned projects thrive under his umbrella).

As for me.. I'd be really happy to see Linode DNS support in ddclient with support for subdomains, new API, etc. But even without it: so many good modern providers are there – Route53, Azure DNS, all flavors of Cloudflare, custom, DO, Hetzner; some IPv6-ready. For now I'll likely stay with os-dyndns until it stops working entirely, in which case I'll either fallback to alternatives the community will have ready (like os-dyndns hosted somewhere else) or dig into fixing and maintaining phpDynDNS myself. Because it's too good to die.