Messages

That's a lot pf Perl dependencies and it doesn't build for me either. I'm relatively sure that's a FreeBSD ports tree error.


Cheers,
Franco

Well it briefly worked, but we had to revoke the fix due to a cosmetic error that would show sections as not synced when they were indeed synced.

We'll reintroduce the proper fix in 25.10.2.


Cheers,
Franco

It's hard to say for sure, but you should try to rebuild once per major OS upgrade (not OPNsense upgrade).


Cheers,
Franco

Nice catch.

That's one of the reasons why the date is in the update output but it's easy to miss the way that OpenSSL handles this as a "general protection fault" instead of being forward about it :)

> Currently running OPNsense 25.1.12 (amd64) at Fri Jan 13 10:10:09 +08 2023

And:

% git grep X509_V_ERR_CERT_NOT_YET_VALID
x509_vfy.h:# define X509_V_ERR_CERT_NOT_YET_VALID                   9

There's your error (9).


Cheers,
Franco

Historically wg-quick would do exactly that too. It can be disabled. It depends on what you want to achieve.


Cheers,
Franco

Some day perhaps, but not a priority for the project as long as there are pages to convert to MVC/API (including firewall pages).


Cheers,
Franco

Well we also have a ports tree https://github.com/opnsense/ports/tree/master/net-mgmt/smokeping ;)

And a tool to fetch and build a port:

# opnsense-code -uo net-mgmt/smokeping ports


Cheers,
Franco

The submitter tone was inappropriate and the information provided inadequate. There is no policy in place that would prevent retrying a well phrased question even by the original submitter.

OTOH, if the /24 is in the GUI screenshot which uses the API why should it be missing from the API output the page is using? A full API dump in the ticket would have likely had the information or not?


Cheers,
Franco

Performance degradation is linear, starting to be noticeable at around 500 parallel clients, but it also depends on the hardware in use.


Cheers,
Franco

I want to make this snappy and the TLDR is in the subject. This is not to fish for solidarity or discussion at length, but if you have questions I will try to answer them below.

On Friday, September 5 at 21:55, I got a no further signed mail from a "FreeBSD Core Team Secretary":

Due to repeated behavior that violates our community's code of conduct,
your access to FreeBSD Project services (Bugzilla, Wiki, Phabricator,
and the mailing lists) is suspended for three months, until the end of
November 2025.

It's now two weeks into December and I'm still blocked. I appreciate good rules as long as everybody also follows them, but in the many years I've contributed to FreeBSD I've seen exceptions and loopholes time and again. I don't wish to see them any longer.

According to the mail this is in direct relation to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283795 which is basically a continuation of a bug caused by https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701 where the core team made clear that proper bug reports must be raised. To me it seemed wrong that the relevant topic was then still ignored for roughly half a year until a different user and not a committer found and fixed the issue. Only then it seemed right to answer and correct users asking what is going on?

Perhaps the ban is deserved and I've gladly done my time, but I still don't know what the punishment of an external contributor is meant to do other than give me a number of sleepless nights and the cozy feeling on a Friday evening that I'm a very bad person (thanks I guess). If this is how contributors are structurally treated I don't see the point in contributing. Or maybe me throwing the towel is the goal?

I've moderately contributed to FreeBSD roughly since 2013 with very mixed success. The key was to persistently ask for committers all the time because a patch is still nothing compared to the commit it will be going into the tree which takes a couple of seconds. I've seen many committers come and go. My patches do resemble the average quality of FreeBSD committers submissions. I've studied computer science and helped run OPNsense as a volunteer for many years. My patches are now committed by people who have been on the project for much shorter periods of time if they are not being ignored. Commits being made by others don't follow standards I was trained on in the early years of my tenure in FreeBSD.

There is a lot more to tell here but I know it's a waste of time given what I've been through. At some point the self-fulfilling prophecy of me being an unlikable, unreasonable, inept and uncooperative person/coder started by FreeBSD adjacent enthusiasts around 2015 had taken a life of its own. I've told several people and core team members about a pattern of neglect and abuse towards me, but it seems that throwing me under the bus is the easiest solution for everyone involved to this day. I'm ok with that, but I am free to say that I don't very much enjoy it. A number of people from FreeBSD are actually active in the OPNsense scope these days. PfSense uses code contributed by OPNsense. We are all benefiting from each other. The situation is perfectly natural for open source efforts, so I don't understand why I am not being tolerated. I'd really like to hear the explanation for a 3 year old but upon asking I haven't gotten any answer either.

So now I'll have a lot more time to build community and code and releases in OPNsense and that's a good thing. People can look up to our standards instead. Use our patches or leave them. Be friendly and cooperative or not. It will be neat and we will know it's because we're doing great things here together. :)


Cheers,
Franco

So you can already add a cron job with any kind of schedule, right?

I don't mind disabling the default one or adding a visibility in cron for it which may be even better. It's just something that needs to be done in the right way and the current settings page where it sits is still a static PHP page we don't want to make more complex unless we have to. All input on GitHub regarding a dependable solution or an actual feature request is welcome.


Cheers,
Franco

The problem with RRD graphs has always been that it's dependent on the input scaling being consistent, but didn't really care about the units (technically and implementationally) and cannot really change units afterwards anymore.

Perhaps be we can improve the RRD metadata to properly show the units now that there is a class for each graph abstracting the input command (work carried out for 24.7.7).

A ticket on GitHub would be useful.  Thanks in advance.


Cheers,
Franco

user: 2,304  <------ 2,3 or 2304?
nice: 0
system: 1,59      <------ 1,59 or 159 ?
interrupt: 0
processes: 370,081      <------ What is this, 370 or 370,081 (three hundred seventy thousand and eighty-one)

Looking at the screenshot I would assume I see a decimal point.  Looking at your post I see commas that add to the confusion.  RRD/system health uses averages so it's very likely decimal points as shown in the GUI.


Cheers,
Franco

This sequence is certainly bad, but I don't know why it would happen since it was fixed by the revision 1 of 2.3.1 in the first place.

[24/79] Deinstalling opnsense-business-25.10_2...
Stopping configd...done
Resetting root shell
Updating /etc/shells
Unhooking from /etc/rc
Unhooking from /etc/rc.shutdown
[24/79] Deleting files for opnsense-business-25.10_2: .......... done

(does update headless)

[79/79] Installing opnsense-business-25.10.1...
[79/79] Extracting opnsense-business-25.10.1: .......... done
Updating /etc/shells
Registering root shell
Hooking into /etc/rc
Hooking into /etc/rc.shutdown
Starting configd.

(proceeds to install the business package as the last step)

So far we're not overly happy with the jump of pkg from 1 to 2, but there is not a lot we can do. But I'll try to improve the recovery procedure which clearly stops when it should but it should then check if a core package is actually found or not and attempt to reinstall it, which could possibly break because pkg decided to remove a "vital" package for no visible reason. I just keep wondering how badly this would impact FreeBSD on pkg-base as well, but we're going to have to see what 2026 brings.


Cheers,
Franco

Why would the documented default be counter productive to other users using it sucessfully?


Cheers,
Franco