pfSense compile requirements for 3rd party software

encrypt1d

Nope.

The package doesn't load on the firewall - missing a dependency on libpfctl. My gut (and past experience with 2.6.0) tells me that to build miniupnpd, you have to build the full pfSense enchilada.

bmeeks

@encrypt1d said in pfSense compile requirements for 3rd party software:

Nope.

The package doesn't load on the firewall - missing a dependency on libpfctl. My gut (and past experience with 2.6.0) tells me that to build miniupnpd, you have to build the full pfSense enchilada.

You need to build it in an environment that at least duplicates fully the regular pfSense kernel and package builder system. Practically speaking that means you need a functioning build system created from the pfSense-supplied scripts. But as you and I have discovered, you can't create such a system from the scripts as they are default distributed. There are code issues in the various scripts that "break" the creation of the required builder environment.

The libpfctl dependency just recently came over from pfSense Plus into the CE tree. It is also going into upstream FreeBSD. It converts what was formerly a shared library distributed with the kernel into a separate FreeBSD ports package that can be updated outside of kernel updates. This makes it ultimately more flexible.

bmeeks

@encrypt1d said in pfSense compile requirements for 3rd party software:

The platform seems to be going in a direction that isn't so much of a "community edition" anymore. Likely should just be rebranded as "free edition" to set expectations.

I don't disagree with you here. Building pfSense and/or the associated FreeBSD-ports packages tree is simply not possible with the currently posted open-source code on GitHub.

Some of the shell scripts used in the builder creation steps are faulty, and at least two critical packages required now in even the CE build are hidden behind the private Netgate GitLab account instead of being on the public GitHub repo. Those two packages are security/pfSense and sysutils/pfSense-repoc.

guiambros

@encrypt1d, have you been able to compile miniupnpd under 2.7.2? I tried again this week, but no luck so far.

Using the default devel branch I can finish the poudriere jail, but can't compile packages due to missing pfSense-pkg-zabbix-[agent4|proxy4] pre-reqs. If I use the RELENG_2_7_2 branch, jail creation fails with make[4]: don't know how to make aes-586.S. Stop.

I don't want to compile the kernel; just need to be able to compile a few packages.

This gave me a deep appreciation for every pfSense package maintainer out there. This is unbelievably painful.

bmeeks

@guiambros said in pfSense compile requirements for 3rd party software:

@encrypt1d, have you been able to compile miniupnpd under 2.7.2? I tried again this week, but no luck so far.

Using the default devel branch I can finish the poudriere jail, but can't compile packages due to missing pfSense-pkg-zabbix-[agent4|proxy4] pre-reqs. If I use the RELENG_2_7_2 branch, jail creation fails with make[4]: don't know how to make aes-586.S. Stop.

I don't want to compile the kernel; just need to be able to compile a few packages.

This gave me a deep appreciation for every pfSense package maintainer out there. This is unbelievably painful.

Do this to work around that poudriere build error:

Edit /usr/local/etc/poudriere.d/src.conf in your builder machine and add the line "WITHOUT_LIB32=y". This will tell it not to try and build the 32-bit binaries (which it shouldn't be doing anyway because there is no longer a 32-bit build of pfSense CE).

encrypt1d

@bmeeks @guiambros
I threw in the towel and gave up after the revelation that the git repo is not up to date, nor are key pfSense dependencies being made available. The port I was trying to build (miniupnpd) has dependencies that are out of reach to the community. From my own perspective and needs, the CE version is dead.

All I was after at this point was enhanced logging from miniupnpd so I tried asking the owners to improve it - but that hasn't gone anywhere yet.
https://github.com/miniupnp/miniupnp/issues/707

Then I created a patch that can put miniupnpd in verbose mode, and one of the admins suggested that become permanent - so I opened a feature request for that:

https://redmine.pfsense.org/issues/15355
https://forum.netgate.com/post/1158289

After that I had to rewrite the regex log decoders in my SIEM, so it's functional but not elegant.

guiambros

@bmeeks said in pfSense compile requirements for 3rd party software:

Edit /usr/local/etc/poudriere.d/src.conf in your builder machine and add the line "WITHOUT_LIB32=y".

I don't have a src.conf, and /usr/local/etc/poudriere.d is virtually empty (just folder structure and two .sample files).

I tried editing /usr/local/etc/poudriere.conf, but same error. Then I realized this conf file is being recreated every time by tools/builder_common.sh, (line 1723). Tried adding the WITHOUT_LIB32 there, but also no success.

Also tried adding an export WITHOUT_LIB32 to build.conf (in the hope that a child subprocess would inherit the variable), and also no luck.

@bmeeks -- would appreciate if you have any other ideas, but I realize I already took a lot of your time in this seemingly pointless wild goose chase. I'm getting to the same conclusion as @encrypt1d: it seems Netgate made it (intentionally?) impossible to compile or do anything with CE.

luckman212

Been casually watching this thread for months. Apologies if I'm misunderstanding, but I really was hoping for a different ending than Netgate made it impossible to compile or do anything with CE. Is that the end of the story here? I have some package ideas I've been working on, and this is discouraging me from continuing if at the end I'm going to face these impossible hurdles.

encrypt1d

@guiambros @luckman212
I was able to build the jail using the WITHOUT_LIB32=Y option, but that is as far as I could go. It would be cool to see if you find a way forward. I don't want to discourage effort, but man, I just don't see how it would be possible without some rework on the git repo. I was an embedded systems dev for 15 years, so I know they CAN do it, they just haven't done it.

bmeeks

@guiambros said in pfSense compile requirements for 3rd party software:

I don't have a src.conf, and /usr/local/etc/poudriere.d is virtually empty (just folder structure and two .sample files).

You must create that file if it is missing. Sorry I was not more clear on that point.

bmeeks

The state of the CE builder is "poorly maintained" to put it as kindly as I can .

I will not ascribe any ulterior motives as to why that is the case, but one possibility is that developer hours invested in CE don't pay the bills the same as developer hours invested in pfSense Plus. There are currently several issues that need correcting in the CE builder tree. These include package dependencies that reference proprietary GitLab repo locations for their source code, configuration problems within the RELENG_2_7_X builder tree (that 32-bit library problem being one glaring one), and little gotchas scattered around the scripting functions in builder_common.sh.

I wish the builder would be split out into two separate configurations: (1) one setup script for creating a kernel builder, which those of us in this thread- and most others- would never use; and (2) a separate setup script that creates a package builder ecosystem for those of us who maintain the third-party packages and only want to build the packages and copy them into a private testing repo so that we can test the full pfSense package installation process (rather than having to simply install the package as a local file from the CLI).

Right now it is impossible to run the builder setup script for the RELENG_2_7_2 CE branch and have it produce a functioning builder subsystem. Nor is it possible, after you futz around and finally hack the builder script so that it creates a poudriere jail package builder, to actually build the pfSense packages repo unless you manually go in and comment out some runtime dependencies for packages whose source code is behind the private GitLab location.

guiambros

Good news: I was finally able to compile all packages!

Only 1 package failed (pfSense-repoc, which the source is now proprietary), and 2 skipped (pfSense@php82, pfSense-upgrade); 547 compiled successfully.

After sorting out the issue with LIB32 (thanks again @bmeeks!), I kept bumping into an issue with pfSense-pkg-zabbix-[proxy|agent]4, that didn't exist in the Ports repo.

I tried moving to FreeBSD 15.0.dev, which solved the zabbix dependencies, but then the compiled packages didn't run properly in pfSense 2.7.2 (not surprisingly; the packages compiled in 15.0 linked to libraries that didn't exist in 14.0).

After enabling debug (set -x), I finally spotted the problem: the Poudriere jail kept defaulting to devel branch, so it was using zabbix packages that didn't exist in 14.0. Checking the Ports branch downloaded, I confirmed it was devel, and not 2.7.2

The solution was to add POUDRIERE_PORTS_GIT_BRANCH in build.conf. It then changed to the right Ports branch, and properly, and finally the packages as expected.

I was able to change, compile and move miniupnpd to 2.7.2 production, and has been running stable for the last 24h.

Here's my build.conf:

export PRODUCT_NAME="pfSense"
export PRODUCT_URL="https://pfsense.org/"
export FREEBSD_REPO_BASE=https://github.com/pfsense/FreeBSD-src.git
export FREEBSD_BRANCH=RELENG_2_7_2
export DEFAULT_ARCH_LIST="amd64.amd64"
export PKG_REPO_BRANCH_DEVEL="RELENG_2_7_2"
export PKG_REPO_BRANCH_RELEASE="RELENG_2_7_2"
export POUDRIERE_PORTS_GIT_BRANCH="RELENG_2_7_2"

Also adjusted tools/builder_defaults.sh to:

PKG_REPO_BRANCH_DEVEL="v2_7_2"
PKG_REPO_BRANCH_RELEASE="v2_7_2"
PKG_REPO_BRANCH_PREVIOUS="v2_7_1"

All the other instructions above are still valid: e.g., comment out gnid in tools/builder_common.sh, create the file /usr/local/etc/poudriere.d/src.conf with WITHOUT_LIB32=y, etc.

@encrypt1d -- I remember you were also trying to compile miniupnpd. I've been running my modified version, and seems pretty stable so far. In my case I just wanted to fix the logging, removing some useless interface mismatch log spam, and flip some messages from LOG_INFO to LOG_WARNING (so I can audit them if necessary).

This time I took detailed instructions so I can reproduce the build, so lmk if you still have problems compiling it.

Thanks for all the help folks!

ps: of course, all this will be wasted effort once Netgate upgrades to 2.7.3+.