OPNsense Forum
Archive => 18.7 Legacy Series => Topic started by: advcron on August 02, 2018, 07:47:56 am
-
After upgrade to 18.7 alias description/detail is missing (in attach).
But in configuration backup exist.
<alias>
<name>FQDN_CRL</name>
<type>host</type>
<descr>Adresy List CRL ocsp</descr>
<address>crl.certum.pl ovcasha2.ocsp-certum.com tg.symcd.com tg.symcb.com gj.symcb.com gj.symcd.com repository.certum.pl crl2.alphassl.com ocsp2.globalsign.com crl3.digicert.com crl4.digicert.com ocsp.digicert.com cacerts.digicert.com</address>
<detail>CRL Certum||OCSP Certum||OCSP Thawte||CRL Thawte||CRL GeoTrust||OCSP Geotrust||CERT Info Certum||CRL GlobalSign||OCSP GlobalSign||CRL DigiCert||CRL DigiCert||OCSP Digicert||Wystawca Digicert</detail>
</alias>
This is Bug ?
This field was very helpfull to identify specific entry.
-
https://forum.opnsense.org/index.php?topic=9280.0
specifically:
o In preparation for the firewall alias API the per-item descriptions have been removed along with support for the deprecated types urltable_ports and url_ports.
-
OK. I understand.
Will there be any tool for identifying alias entries?
For example, I have 10 ip addresses in host alias, and I would like to now which workstation has certain address.
-
We've discussed how we can retain this, but were unable to find a useful way.
What you can do is nest your aliases by creating single aliases for your devices with a unique description, then merge them into another alias by typing the alias name of the individual ones instead of providing addresses, e.g.
Alias 1: 10.0.0.1 Host 1
Alias 2: 10.0.0.2 Host 1
Alias 3: Alias 1, Alias 2
Cheers,
Franco
-
Yes. I also think this is only way.
But I notice one issue:
When you have this "Alias group" and rename individual host alias. In alias group name chaged. This is correct.
When you delete individual host alias, the entry in alias group not delete. This is not correct.
@franco I don't now it is possible to prevent from delete "individual host/port alias, when it use in alias group or delete this entry in alias group.
-
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?
-
Yes, it is final.
-
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.
-
plain and simple, if it's an entity worth describing, treat it like that. create an alias, and bundle sets of aliases for the firewall rule you want to create.
This is pretty standard in a lot (most?) firewall systems.
In detail:
client_1_machine_a [192.168.1.100]
client_1_machine_b [192.168.1.101]
client_1_all_machines [client_1_machine_a, client_1_machine_b]
-
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.
-
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
-
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.
-
We've rebuild the feature from the ground up, which has many advantages (api support, less fragile loading, ..).
It's not a matter of removing something as it is to fit the most important use-cases when building new software. (addresses + descriptions don't fit the ui model and would complicate our data model, since in the end, it would always be separate entities).
There are always manners to improve input, we likely will add some kind of import export feature at some point in time. How it works under the hood won't change (for reasons explained)
Scripting to push aliases is pretty easy, as mentioned before, our new components always are api enabled.
-
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.
I was an OPNsense user and I never saw a poll asking if I would be okay with losing countless alias item descriptions I had entered. Had I seen such a poll here, I would have registered at the time to voice my objections.
I had blacklist aliases I developed to protect our servers, with descriptions that included type(s) of abuse, whether the entry was to be permanent or temporary, and what ISP/organization owned the IP block. Without those descriptions, it became all-but-impossible to maintain those aliases. That's why I went through the extremely time-consuming process of migrating back to pfSense.
Imagine if you updated to a later revision of your IDE (integrated development environment) and all of the comments were stripped out of your source code. That's what it was like. My well-documented aliases turned into the firewall equivalent of source code with all of the comments and line breaks stripped out.
plain and simple, if it's an entity worth describing, treat it like that. create an alias, and bundle sets of aliases for the firewall rule you want to create.
That's as silly as saying that if a line of C is worth describing with a comment, then it should be worth putting into its own standalone file that you can #include into the parent source file.
I hope that the OPNsense developers reconsider the decision to remove the alias item description from the web GUI. Its removal might not bother a hobbyist using OPNsense to implement a simple home firewall, but it's a serious blow to many of us trying to maintain OPNsense firewalls on networks with multiple servers, multiple WANs, and large aliases used to block malicious traffic.
-
As previously stated the core team will not spend time bringing the feature back. The time is better spent elsewhere.
Thank you for your understanding,
Franco
-
The time is better spent elsewhere.
Thank you for sharing your opinion and for your prompt reply.
-
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.
I was an OPNsense user and I never saw a poll asking if I would be okay with losing countless alias item descriptions I had entered. Had I seen such a poll here, I would have registered at the time to voice my objections.
I had blacklist aliases I developed to protect our servers, with descriptions that included type(s) of abuse, whether the entry was to be permanent or temporary, and what ISP/organization owned the IP block. Without those descriptions, it became all-but-impossible to maintain those aliases. That's why I went through the extremely time-consuming process of migrating back to pfSense.
Imagine if you updated to a later revision of your IDE (integrated development environment) and all of the comments were stripped out of your source code. That's what it was like. My well-documented aliases turned into the firewall equivalent of source code with all of the comments and line breaks stripped out.
This is one the reasons we did NOT make the move to OpnSense. There might be a reason for removing the descriptions, but it's a feature sorely missed. The fact that other vendors might not have it (most I've seen DO have it) should not be the reason to remove it. But more so, the attitude from the developers towards users or prospects made us scratch our heads.
The time is better spent elsewhere.
So are our bucks.
But hey, it's a free world, choose whatever suits you.
-
Please stop barking and put in some effort instead:
https://github.com/opnsense/core/pulse/monthly
Constant stream of work going into OPNsense says you're simply pissed you don't get what you want for no effort given. Spoiler alert: effort is needed to get what you want.
Cheers,
Franco
-
Franco,
now that's exactly part of our problem. Your answer to everything (and yes I exaggerate) seems to be 'if you don't like it, contribute'. But you know as well as me that's not feasible. Your users / customers are not supposed to be coders, right? I'm not a coder, nor do I have any coders in the company I own. But if we consider buying or supporting a product, does that mean if we don't like something that WAS in there, we can't try to start a constructive discussion on it? Usually I feel that's one of the advantages of picking an open source product, as there's a community that is usually open minded. Opposed to for example MS who just makes choices for users no matter if they like them or not (Windows 10 update terror anyone? But even THEY gave in and reverse it, go figure).
It seems my company is not alone in missing this particular feature, but it's not about this one feature. It's about the general attitude. I really wanted to like OpnSense, and I do, but if this is how customers are treated and how discussions are ended, then that's certainly not the company I want to work with. I wish you the very best of luck with it. No hard feelings, but I'm pretty sure this way it'll cost you paying customers. It cost you at least one already.
-
I think someone is confusing the terms company and project. From time to time there are companies needing changes to the (core) system and contribute (financially) making things happen in case they can't drive the change themselves (or just need more guidance).
It's just very easy to ask others to pay for your dish. In some cases you get lucky since people actually willing to sponsor these changes are working on it, or others for whatever reason are willing to pay for it. Today just doesn't seem to be your lucky day in that regard.
We (as a company) have no record of you being a customer, you're more than welcome to become one.
Just for the record, Franco spends a lot of his own time on the project and doesn't get paid for his work.
Best regards,
Ad
-
I think most of it is missing the point completely: we very rarely decide to go against particular wishes, but when we do we have to stay true to what we set out to do and why. These reasons have been stated and the situation since was handled according to this principle. There's no reason to indicate we treat anyone unfairly or stop discussions which have a base.
I'm not going to give examples of where people actually get what they want for free. The general rule is politeness and accordance on what can be achieved with what we have. That is for every individual to decide for themselves. The patch notes may be a general indication of this...
Unfortunately, as said a number of times, this particular case is non-negotiable. Even time spent explaining what non-negotiable means is better spent on software improvements or mirror maintenance or helping users in this forum. If you want to be angry on this view of "time better spent" then so be it. I know some people don't and I do care a great deal for them. :)
If it WAS there, it actually still is if you keep using the old code, which you are allowed to do. There is, however, no privilege associated with old code to be new and secure and up-to-date code. It would be absurd to make this claim openly. I can only guess this is your implicit point and making it explicit helps understand how much you are asking us to do:
1. Reverse a decision against the best of our intentions for code that is neither broken nor unable to perform technical requirements.
2. Keep old and likely flawed code from being replaced by more modern and slim code implementations.
3. Being open for the sake of having to deal with wishes from people who think that open means they can demand whatever of the community, project or open source in general.
I hope this makes it a little bit clearer why we are not going back on this particular issue. Attacking people for their behaviour that you happen to not agree with is not a good case for future discussion. It would rather indicate you see what you want to see and merely try to use common sense now to get what you want without binding yourself to the same understanding of civility.
Cheers,
Franco
-
Attacking people for their behaviour that you happen to not agree with is not a good case for future discussion. It would rather indicate you see what you want to see and merely try to use common sense now to get what you want without binding yourself to the same understanding of civility.
Franco, you seem to be the one attacking people and showing a lack of civility, accusing RGijsen of "barking" and being "pissed you[RGijsen] don't get what you want for no effort given." You even went so far as to condescendingly suggesting that he needs you to explain the term "non-negotiable." By contrast, RGijsen has been courteous and professional, writing:
I wish you the very best of luck with it. No hard feelings, but I'm pretty sure this way it'll cost you paying customers. It cost you at least one already.
As to 'putting in some effort,' to what end? All of us who want alias element descriptions should spend weeks reimplementing them so that you can reject our work?
From time to time there are companies needing changes to the (core) system and contribute (financially) making things happen in case they can't drive the change themselves (or just need more guidance).
This appears to be the first time Deciso has suggested that someone could "sponsor" the reintroduction of the feature. How much money would Deciso require in order to reintroduce alias element descriptions into the GUI, making it a standard, supported feature going forward?
-
Franco, you seem to be the one attacking people and showing a lack of civility, accusing RGijsen of "barking" and being "pissed you[RGijsen] don't get what you want for no effort given." You even went so far as to condescendingly suggesting that he needs you to explain the term "non-negotiable." By contrast, RGijsen has been courteous and professional, writing:
You are absolutely right, albeit dismissing the fact that this is a reaction to an unreasonable stance after having taken the time to explain this multiple times. If people don't like other people's decisions and their reasoning there's no reason to start acting a certain less productive way. That's what happened here.
If you want me to not respond to frustrations you'd have to claim we don't respond to negativity and how much that is disliked. There's no easy way out of this and you keep telling what you don't like and that list never ends if you put your time into it. :)
I wish you the very best of luck with it. No hard feelings, but I'm pretty sure this way it'll cost you paying customers. It cost you at least one already.
As to 'putting in some effort,' to what end? All of us who want alias element descriptions should spend weeks reimplementing them so that you can reject our work?
There's no use for a straw man argument -- let's talk about mergeable work when that work is here. Also, note that this would imply it's reasonable to ask us to spend "weeks reimplementing" which I said I don't agree with and you can't change my mind that something that somebody wants must be done by the people who generally contribute to an open source project because that is what you envision it to be.
Above all, be prepared for a "no, thanks" and don't try to make a fool of yourself on the way out.
From time to time there are companies needing changes to the (core) system and contribute (financially) making things happen in case they can't drive the change themselves (or just need more guidance).
It's just very easy to ask others to pay for your dish. In some cases you get lucky since people actually willing to sponsor these changes are working on it, or others for whatever reason are willing to pay for it. Today just doesn't seem to be your lucky day in that regard.
This appears to be the first time Deciso has suggested that someone could "sponsor" the reintroduction of the feature. How much money would Deciso require in order to reintroduce alias element descriptions into the GUI, making it a standard, supported feature going forward?
Note this is a community forum. Try https://www.deciso.com/request-support/
Cheers,
Franco
-
You are absolutely right, albeit dismissing the fact that this is a reaction to an unreasonable stance after having taken the time to explain this multiple times. If people don't like other people's decisions and their reasoning there's no reason to start acting a certain less productive way. That's what happened here.
You explained your reasoning and we explained ours. We failed to convince you of the value of the feature and you failed to convince us that the non-negotiable, never-to-be-revisited decision to remove it was the right one. I don't think that entitles either of us to lash out at the other.
There's no use for a straw man argument...
It's not a straw man. You suggested contributing to development if we wanted that feature, yet you have categorically ruled out ever putting it back in. You didn't make it contingent on the code being clean, well-documented, efficient, maintainable, etc. You just said it was a "final," "non-negotiable" change.
BTW, I released my first open source software in 1985.
Note this is a community forum. Try https://www.deciso.com/request-support/
This community forum is where AdSchellevis of Deciso suggested that someone could "sponsor" the reintroduction of the feature. So I'm asking him in the same forum because I'd like the answer to be visible to others reading this exchange. Perhaps we could pool our money to pay for it.
-
I admire your principles. I'll mimic whatever level of conversation you want to have. We can indeed get back to a useful discussion.
I merely laid out the reasons from the core team perspective that we will not be working on this. If I'm being pressed on the matter, I'll reiterate again on that stance, likely without the full extent of my intention.
As things are still open source that leaves the door wide open for possibilities.
Cheers,
Franco
-
PS: I reread the thread and it got bad before anyone would ask what it would take to bring it back. The answer is user contribution on top of the newly embedded code. Plain and simple answer to a question missing in action.
-
With the risk of repeating myself:
... In some cases you get lucky since people actually willing to sponsor these changes are working on it, or others for whatever reason are willing to pay for it.......
It's not about this particular feature, it's a general statement, we're not planning to work on this ourselves, for the simple reason that there are valid workarounds which also are very comparable to features other vendors offer.
-
I admire your principles. I'll mimic whatever level of conversation you want to have. We can indeed get back to a useful discussion.
Thank you, Franco.
Unfortunately, my use case (aliases as abuse blacklists) requires the feature -- it's as basic to me as the ability to comment source code. I wish I could make do without it, because the OPNsense GUI for GeoIP aliases is elegant, well thought out, and powerful and would make my life much easier. But I can't maintain other aliases that are dozens, or even hundreds, of lines long without an ability to identify the ISP, country, abuse type, permanence, etc. on each entry.
Apparently, the loss of the feature is not a deal killer for others. Best of luck to you going forward and thank you for the time you've taken on this aspect of opnSense.
Regards,
fmaxwell
-
Hi fmaxwell,
Your reasoning is sound. Everybody shall act according to their requirements.
Thanks,
Franco