Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - rsk

#1
Hi,
while upgrade is in progress and also after reboot the syslog-ng startup script logs this error message:

Configuring system logging...Error opening plugin module; module='examples', error='/usr/local/lib/syslog-ng/libexamples.so: Undefined symbol "random_choice_generator_parser"'

It seems to be only a cosmetic issue, everything is working. I'm using syslog-ng with a remote TLS target.
#2
Quote
for me it is not related to ntpd.
it is the same behaivor again as descripted here:
https://github.com/opnsense/core/issues/5788

me too. ntpd / system time was fine. I also think that there is a regression regarding alias #5788
#3
Quote# cat /usr/local/etc/filter_tables.conf

the files looks the same between versions. I re-applied the 23.1.5 update, rebooted and the issue was still present. I looked at the commits in Github and found Firewall/Aliases - refactor alias update script. I just did a rm -f /var/db/aliastables/* && /usr/local/opnsense/scripts/filter/update_tables.py and everything was working again.
#4
I have also issues regarding aliases / NAT. While IPv6 network aliases work I also have mixed network allies which includes IPv6 and IPv4 networks. After the upgrade to 23.1.5 only IPv6 works, all IPv4 inbound NAT rule which are filled with alias does not work. They are all populated correctly under Aliases. Even when I hoover over them in UI they are listed there. I reverted back to  23.1.4_1 using opnsense-revert -r 23.1.4_1 opnsense and NAT / port forwarding does work instantly without a reboot. I compared the /tmp/rules.debug file with the  /tmp/rules.debug.old where the latter was the version from 23.1.5 and the first from  23.1.4_1 and indeed all RDR and NAT which are using aliases where missing from the  23.1.5 file. 
#5
Thank you for fixing this so fast. It works now.
#6
Quote from: franco on July 28, 2022, 08:52:01 PM
Quote from: rsk on July 28, 2022, 07:11:23 PM
'parse error. not well formed'

So that's the output on the 22.1 or 22.7 system?

My guess would be 22.1?


Cheers,
Franco

No, the sync was broken after upgraded both instances to 22.7. Before the upgrade XMLRPC sync was running fine.
#7
I have the same issue. Running /usr/local/etc/rc.filter_synchronize debug results in 'parse error. not well formed'

Maybe this is a regression as there was a issue in the past triggered the same behavior.