Messages

19.1.2 released, I didn't see any changes in this regard in the changelog. However I tried to (after taking snapshots) my test-environment from 18.x to 19.1.2. However, as far as the logs go, I see it first tries to 19.1:

***GOT REQUEST TO UPGRADE: maj***
Fetching packages-19.1-OpenSSL-amd64.tar: ...............................pgrep: Cannot open pidfile `/tmp/opnsense-fetch.pid.oUd52D': No such file or directory
done
Fetching base-19.1-amd64.txz: ........ done
Fetching kernel-19.1-amd64.txz: .... done
!!!!!!!!!!!! ATTENTION !!!!!!!!!!!!!!!
! A critical upgrade is in progress. !
! Please do not turn off the system. !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Extracting packages-19.1-OpenSSL-amd64.tar... done
Extracting base-19.1-amd64.txz... done
Installing kernel-19.1-amd64.txz... done
Please reboot.
***REBOOT***

19.1.2 update was available in the updates-list though. Would this mean we will have a hard time updating these affected machines to a 19.x version that has this issue fixed later on, as it'll always first update to this non-working version? So maybe offtopic here, but how do we update to a 19.1.x version in this case, skipping the faulty 19.1 release?

Is there an update yet from the OPNSense team? Easy to reproduce even on a Windows 10
hyper-V box. Would the next update cover this issue?

Hi,
when I have aliasses with FQDN in it, and I (accidently or not) flushed the pftables for them, how to reload them? When I add a new FQDN to that alias, that ends up in the pftable, but the other ones aren't. I remember from pfSense I could kill filterdns and restart that, but I can't see a filterdns process running at all, so OPNsense probably works different here.

I'm trying not to clutter the forum too much by posting another thread. I've been looking in the documentation but can't find an answer there, in fact, the word 'flush' doesn't show up when searching.

I'm working on those aliasses, but also testing some things to get a grip on OPNsense. Say I erroneously flushed an alias table. How can I re-populate that? When I add something to the alias, the added host ends up in the table, but the existing ones (which I flushed) don't. Is there a way to repopulate them?

[edit]
you just replied so I'll discuss that as well:

Thanks for your consideration.

Over the years we have had to make a choice: listen to the users that we have or listen to potential users who only miss this one feature X. We choose to listen to the former group as that is the one we can depend on. And we also like to build solutions for them, not only take things away.

Maybe this is a little harder to understand as an outsider. We have no reason for your trust yet.


Cheers,
Franco

Ok, fully agree that existing users are somehow more important than new / not existing ones. Still, I don't see how anyone would want those descriptions to be dropped completely? If you don't like 'em, don't use 'em, and if you do like 'em, DO use 'em. Sorry to be an @ss about that, but I still don't see the point in removing them. Did people explicitely ask to remove a descriptive field?

Yet, I don't like dumb work. So I'm trying to build me a script that generates me an alias.xml with nesting I can import, rather then go through them one by one.

Hmm ok. Well I fully understand adopting to whatever new software takes time to get used to it, and we certainly should expect 1:1. However, I must say I still can't understand this move. Forcing us to create nested aliasses makes for twice as many work when creating one (first create an alias for a new FQDN, THEN add it to another alias), as well as it consuming more resources, even though if it's measured in bytes rather than kilobytes or megabytes even. But the most important issue I have with it is that is certainly adds unnecessary complexity to the aliassing. Our list would expand from about 150 aliasses to over 500 because of this. And we are a just a small shop.
I'll try to get myself over the point to accept this.

Hmm. And what's the reason behind dropping that functionality? Really trying to understand why such changes are made. Don't pretty much all users want descriptions in their aliasses? How could one ever keep track of what's in otherwise?
I'm just trying to be constructive and understand how to use OPNsense opposed to pfSense.

Was there actually a problem with performance then? We are considering moving from pfSense, but this would certainly be a deal-breaker. Missing seperator lines in the firewall rules being the other.

Ouch. We are doing in test a migration from pfSense to OPNsense, but this might very well be a deal breaker for us. We have several aliasses like 'IMAPS hosts required by customers' with several IP's in them. In the description we store for which customer it actually is. This prevents us from creating a seperate firewall rule for each IMAPS connetion in this example. However, now OPNsense is unable to show the descriptions (they are still in our config file by the way) it makes it impossible for us to distinguish which IP or 'random' hostname belongs to which customer.

Nesting aliases gets extremely dirty very quickly. Having read the release notes, I still don't understand why the descriptions are deprecated now?

What is / will be the replacement? Is this final?

+1 for me though too. 'We won't' is a bit of a sad answer honestly. We are currently migrating to OPNsense (and the reason is pure ideological), and really the rule-list look like a long mess in OPNsense. The ability to put some descriptive lines in there like 'Exchange', 'RD Servers' and such is a real addition. They are certainly not non-functional. Network wise they may be, but it's certainly functional to us.

Everyone has their own believes, but we think it's really useful. For example we used red seperators when we had rules we had to review later on.