Feedback on challenges with the pfSense package development process
-
@michmoor On one hand, arguably no, but OTOH there’s no free version of UniFi AFAIK.
Open source is a weird middle ground of lots of people wanting updates, but few have the skill and time and will to do the work for free.
-
@SteveITS said in Feedback on challenges with the pfSense package development process:
Open source is a weird middle ground of lots of people wanting updates, but few have the skill and time and will to do the work for free.
This is most certainly true and very well describes the overall situation with regards to packages on pfSense and any other similar open source platform.
-
@michmoor said in Feedback on challenges with the pfSense package development process:
@bmeeks
Curious, do you think the current system of 3rd party packages and support of a volunteer community is scalable?
If you look at other vendor firewalls, the entirety of the system is under control of the company. Unifi may run Suricata in the background but if something breaks on their system they take ownership of it and not wait for a fix to hopefully come upstream.@michmoor, not trying to pick on you with this reply, but your questions and remarks make it appear you seem to expect the same level of support from pfSense and Netgate as you get from the other firewall vendors I see in your signature (Palo Alto and Juniper).
At the price you are paying for pfSense versus what I suspect you are paying for Palo Alto and Juniper, that is just never going to happen . Especially so for the free open source edition of pfSense (and remember the packages tree is essentially the same for both the free and paid editions of pfSense, with the one exception I recall being an AWS package for Plus that is not available in CE).
Netgate could certainly follow the lead of a Palo Alto or Juniper or Cisco and bring all the packages in house and maintain them. But the price of Plus would have to increase substantially and I would not expect to see that support spread to the open source side for free.
-
@michmoor said in Feedback on challenges with the pfSense package development process:
@marcosm Marcos, are packages dependent on point releases of pfsense plus?
What constitutes a new package?
Whats a realistic timeframe new packages like Zabbix can be added to the pfsense repo?I doubt this answer is satisfactory but it's what I've got...
Sometimes. Generally anything with its own page at https://www.freshports.org/. Depends on the situation.
Off-topic: I personally hesitate to spend much effort browsing/responding in social platforms because it often tends to result in additional stress that I prefer to avoid in my life. That's become more and more true as the years pass. Anyway, I say this to offer some insight into why I may not respond to things. I imagine I'm not alone in that.
-
@marcosm No worries Marcos. I appreciate you even responding.
Your answer is satisfactory. I will leave it at that :) -
@bmeeks Always picking on me..why is that ( kidding).
Im not comparing any level of support between vendors in my profile for example and Netgate. There is a gulf between them but that's not the issue (or my issue) in particular.
For some background, I have been using PfSense for about five years now. When I started using the platform, I assumed that everything running on it or installed on it was supported. Much like the OP here, I figured it was the total package, and if you needed white glove support, you could get a TAC support contract.I later found out that there are nuances in what is supported and by whom. The website's marketing and documentation do lead anyone to believe that there is support for third-party packages, but I found out years ago that is not true. Hence why i would advocate for cleaning up the package support list page and only list the packages that are supported by Netgate. Documentation can state otherwise.
-
@michmoor said in Feedback on challenges with the pfSense package development process:
There is a gulf between them but that's not the issue (or my issue) in particular.
Speaking for myself and rather confidently on behalf of others, many of us feel like that "gulf" exists in the opposite direction from what you suggest and are nothing but grateful that Netgate continues to maintain a CE and a free Plus which can utilize third-party packages at all.
@michmoor said in Feedback on challenges with the pfSense package development process:
The website's marketing and documentation do lead anyone to believe that there is support for third-party packages
That's just not true unless you're claiming to speak on behalf of literally everyone.
-
But if I understand this correctly, the community has to provide the necessary files to successfully compile an application/package in PFSense in order to get it in the web-gui and pkg list, right? (which is done using the pfsense/FreeBSD-ports)
Then the netgate team needs to (compile, ) test and put this in the upcoming PFSense release so that every PFSense admin has access to the package, right?
So if that is correct, then why is it taking so long for a new package to be added that is already 5 months in the main branch?(https://github.com/pfsense/FreeBSD-ports/tree/main/net-mgmt/zabbix7-server)
Again, please correct me if I am wrong, I am trying to understand the complete process, and if I can help in any way to speed up this process I am willing to try what I can for the Zabbix package.
-
@tinfoilmatt I think there is a reading comprehension issue here.....I have no idea what you are talking about or really what you are trying to convey.
-
@Mauriced said in Feedback on challenges with the pfSense package development process:
I am trying to understand the complete process
The very moment Netgate decides to place a pfSense package on their "package servers", the one pfSense uses to get updates, upgrades and new pfSense packages, even if the package wasn't created by Netgate internally, they will take "some" responsibility for it.
A pfSense package, as for example Notes or Cron or Shellcmd, are simple packages, with not much more as a collection of php files for the GUI interaction.
Some more data (scripts) like 'where to place it on the menu' and 'what do do when placing the files on the file system' and 'what to do when removing the packages', and that's it.
Then the 'pkg' tool is used to build a real 'FreeBSD' package and voila, a new pfSense-package-xxxx.pkg is born. The file is place on the Netgate pfSense package server, and everybody can now install it.
Easy to understand : every externally written pfSense package has to be authored by Netgate.
A bit like Apple authors every phone app before it enters the app store.
I guess these question must be asked and answered by the Netgate team :
Does the new functionality belong on a firewall ?
Is there an audience (market, usage, etc ?) for it ?
And also :
Who will write the manuals ?
How much config storage will be needed (our xml config file has become rather big lately)
The pfSense documentation web site has to be maintained.
And the most important one : is there any security aspect ? Will there be one ?
These are the questions I could find after a thorough 5 minutes reflection.
Things become much harder when binaries are involved. True, most binaries used are often maintained by others, and if big brother (the FreeBSD repository itself), hosts them, they are probably ok, and tested. Still, using 'whatever' on a desk top, or even a server environment is one thing, using it on a firewall is another.
If one pfSense package provokes a major security issue, the big world out there will not understand that its just a failing "add-on", but it was pfSense (Netgate) who has an issue. That's very bad for the business.Also, keep in mind : what will happen when a package becomes extremely popular ?
And then then author stops maintaining it for whatever reason. Netgate won't have a choice, they have to 'incorporate' the package into their maintenance list.
Only this reason alone will make them think twice before they 'accept' a package from 'some one'.As always : these just my - a pfSense users as we all are - thoughts - and keep in mind, I 'm sure I just scratched the surface of the question.
-
There are lots of good discussions and viewpoints in this thread!
So far, the only way I've found https://www.netgate.com/supported-pfsense-plus-packages is by searching. I would suggest that https://docs.netgate.com/pfsense/en/latest/packages/index.html and https://www.netgate.com/supported-pfsense-plus-packages be linked together.
On https://www.netgate.com/supported-pfsense-plus-packages, I think the list should be updated to include ALL available packages so that the supported and non-supported status is clearer.
Having a link to the supported packages page from within the Packages page of pfSense would also help improve awareness. An official/unofficial label or filter on the Packages page would be great, too.Maybe it's due to the ignorance of people like me comparing pfSense against Big Name Firewalls.
Netgate could improve the messaging about what it means to have an "open source" firewall and how support for third-party packages works.With Zabbix, one could think, "The Zabbix project is still maintained and is releasing new versions," and not be aware that
- a) Zabbix is not releasing FreeBSD versions,
- b) Even if there is a plain FreeBSD version, it's likely not compatible, and
- c) There's no active maintainer of Zabbix for pfSense.
These issues are not immediately apparent when starting out with pfSense.
The numerous Redmin and forum posts go unanswered, and Netgate staff put a target version on Redmine's request, which can reasonably be interpreted as an agreement and commitment by Netgate. I've never seen Netgate staff pushing back on Zabbix and explaining that Netgate does not maintain the package and that if someone else builds a pfSense-compatible version, they can submit it for inclusion.
Regarding paying support to help drive pfSense development, I think that issue is irrelevant with the current paid support options as both CE and Plus have almost the same packages. There is no express or implied statement that purchasing support will affect package development whatsoever. I could purchase $10,000 of support and still not get Zabbix 7.0 anytime soon. There's a Bounty forum, but I haven't seen it widely promoted as a means to get the community to maintain packages.
I'm not trying to trash Netgate or anyone who works on pfSense. I genuinely appreciate their hard work and love using pfSense at home and work.
I'm trying to help move forward with ways to improve it from a business/commercial perspective. All the effort to deliver MiM is great, and better package support would make pfSense even better! Perhaps Plus could get more regular package updates and support compared to CE, either on its own or by requiring TAC Lite or a "Packages Only" subscription. This would be similar to how Plus gets the VPN export package, but CE doesn't. -
I spent some time yesterday learning how to build from ports, and I was able to create Zabbix 7.0.6 proxy and agent binaries using a fully updated FreeBSD 14.2 VM. I didn't use Poudriere jails or anything, just ran
cd /usr/ports/net-mgmt/zabbix7-server/ && make
I copied the binaries to a pfSense 24.11 box for testing and so far they work perfectly.
This is not a proper build and testing process, but it's a good indication that Zabbix 7.0 should work fine on pfSense 24.11.I'm not a developer and don't have a Github repo, so I guess this doesn't help anyone unless I setup an account and submit a PR for my binaries to be included?
Also, is there a guide of what the statuses mean on Redmine? The Zabbix 7.0 package request is "Confirmed", "In Progress", and target is 25.01. Does this mean that Zabbix 7.0 will NEVER be released for 24.03 or 24.11? Is Netgate staff working on the packages to include with 25.01, or is it waiting on someone in the community to submit it?
If 24.11 is the currently supported version of pfSense, and assuming the Zabbix package doesn't require modifications to pfSense, then it should be possible for an official package to be released for 24.11, right? As far as I can tell, it can 7.0 behaves exactly the same as 6.4.
I think my test port uses different default paths for the config, log, and pid files than pfSense does, but the log and pid paths can be set in the config file, and the the config file path is given as a parameter to the binary. Or someone with more knowledge than me could just set those correctly in the build.