Messages

Things are likely changing in the default install of 26.1 as we're trying to unwind these implicit IPv6 behaviours steered from the interface settings  we've inherited.  They don't really work in a post ISC DHCPD world.


Cheers,
Franco

Building a complex solution for a problem that doesn't exist for 99.9% of the users to allow to chose a shell that is not even installed by default in a very tiny shell script that offers a bit of convenience shows how impractical the request is.

Why not set the admin shell to bash? Why not use a separate admin user with bash shell and sudo su for the console menu?  These types of setups have been supported for many years already.


Cheers,
Franco

I can offer you the latest code we shipped. If that's not what you want from upstream acme.sh you need to patch the file manually because it looks like they did not release it yet?

In general it helps to get the data straight before experimenting if the change one wants is actually there.


Cheers,
Franco

You can always install the community one:

# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/MINT/25.7.10/latest/All/acme.sh-3.1.2.pkg
# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/MINT/25.7.10/latest/All/os-acme-client-4.11.pkg


Cheers,
Franco

All of the things that have been said here are normal.

WAN has DHCPv6 mode by default as witnessed by a ps dump with "dhcp6c" in it.

LAN has Track6 mode by default which launches DHCPv6 and Radvd.

If you dont want IPv6 set IPv6 mode of WAN and LAN(s) to "None".

This isn't rocket science. Never has been.


Cheers,
Franco

# opnsense-patch https://github.com/opnsense/core/commit/00687dbe

Mea culpa :)

Thanks, some progress in the ticket now: https://github.com/opnsense/core/issues/9601

The failure detection we added certainly works as expected. Unfortunately the current package manager isn't very good in these instances. We will be looking into it shortly. It's not our territory, but it seems we need to dig into this.


Cheers,
Franco

Thanks for your message and your mailing list thread! There seem to be a number of similar stories out there. Let me add one more that matters.

Here is my one and only 2023 code of conduct complaint that I filed after bit of a backstory of misconduct in the ports scope towards me.

From: Sergio Carlavilla <carlavilla@freebsd.org>
Date: Mon, 9 Oct 2023 11:06:12 +0200
Subject: Re: reporting an inappropriate mailing list reply
To: Franco Fichtner <franco@opnsense.org>
Cc: "conduct@freebsd.org" <conduct@freebsd.org>, FreeBSD Core Team <core@freebsd.org>

On Mon, 9 Oct 2023 at 11:03, Franco Fichtner <franco@opnsense.org> wrote:
>
> Hi,
>
> [REDACTED]
>
>
> Thanks,
> Franco

Hi Franco,

Okay, we've received the message.

We will contact you when we have studied the case and have a response.

Bye!

Sergio Carlavilla
Core Team Secretary.

I never got another reply on this complaint. I eventually chased down a core team member on the issue and the person assured me it would be taken care of internally. I trusted the person so there wasn't a reason to not agree to it. The email gives the offender a very lax outlook. Compared to how the core team handled the complaint against me  I just think both of these instances were inappropriate and unprofessional.

Date: Wed, 6 Mar 2024 10:19:40 +0100
From: XYZ <xyz@freebsd.org>
To: Franco Fichtner <franco@opnsense.org>
Subject: Re: reporting an inappropriate mailing list reply

On Wed, Mar 06, 2024 at 10:08:26AM +0100, Franco Fichtner wrote:
> Hi [REDACTED],
>
> > On 6. Mar 2024, at 10:05, XYZ <xyz@freebsd.org> wrote:
> >
> > Yes [REDACTED] can be border sometime, at even cross dangerous roads sometimes, I do
> > talk quite a lot with him about him, to make sure he improves.
>
> If I can take your word for it I'll let this go then.

You can take my word, on this, he [REDACTED], so I feel like it is kind of my
duty, his behaviour has degraded the time he started getting more involved in
the project, due accumulating lots of frustration, as a result he ends up being
more (too much?) opinionated, and even aggressive sometime, I am trying to cool
him down, as frustration is part of high involvements and at some point we all
need to be able to deal with it, or we simply burnout.

[REDACTED]

still if you see bad interactions, don't hesitate to send me a heads u
directly, I am not tracking all his communication, so I may miss them.

[REDACTED]

Best regards,
[REDACTED]

The trust in the core team was mostly gone in that instance. What came after and anyone can look up is the core team's inability to bring people together even over technical matters.

So I think it's clear the code of conduct is dead and the core team cannot claim it to justify its decisions. The illusion here is that "words" matter and people are supposed to be friendly but actions like systematic neglect and abuse of power are much worse for the code, its users and even its developers in the long run.


Cheers,
Franco

Your CMOS battery is dead?


Cheers,
Franco

Great, thanks for confirming!


Cheers,
Franco

The situation was improved in 25.7.10 with https://github.com/opnsense/core/commit/4b3280e6acd

But mind you a big config XML will parse slower than a small one.

If you have trouble with large configuration sections you can now also flush them from the GUI under System: Configuration: Defaults: Components too.


Cheers,
Franco

When this finishes I see this.

Ok so there's the expected part but then you press update and I guess it cannot fetch the sets?

The changelog truncation is a DNS timeout issue most of the time. It can also impact base/kernel fetch behaviour.


Cheers,
Franco

Well, the right way would be to add a user with limited privileges. Admin + exclusions are not possible. I know that's a churn for "almost everything", but that's also not a typical use case.

You can also remove pages from the menu for everyone via adding menu override files, but the URLs are still accessible manually so only do this if you're not trying to improve security.


Cheers,
Franco

> I think its irresponsible for OPNsense to expect us to not provide a direct iso link

I think it irresponsible to ask for direct bandwidth for uncompressed ISOs that are going to be abused by every cloud provider out there offering a "show me an iso and I'll boot your VM".

You'd think someone would be smart enough to allow decompression in their infinite wisdom. But I'm sure they know how not to support mirror maintainers at all. So a compressed iso is the best we've all got and can offer.  :D


Cheers,
Franco