Feedback on challenges with the pfSense package development process
-
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.