Messages

Hi Pawel, consider it fixed!

I've notified the maintainers about the issue with poeditor.com and thus opened a PR for this single-line bugfix instead, which just got merged. You can expect a bump to the opnsense-lang "soon-ish".

Hi Pawel

Interesting, definitely reproducible, here is what I saw:
The source of the polish translation is located here in the 'lang' repository: https://github.com/opnsense/lang - however translations happens on translate.opnsense.org / poeditor.com.

• Languages where the string isn't (yet) translated, work, for example German
• Languages where the string is translated, but the link to the documentation (at the end) is missing, work. for example French
• Languages where the string is translated, and the link to the documentation (at the end) is formatted, also work. For example Italian.

I think I found the culprit! The source currently says:

Code Select Expand


#. File: /usr/core/src/opnsense/mvc/app/library/OPNsense/Backup/GDrive.php, line: 68
#:
msgid "You need a private key in p12 format to use Google Drive, instructions on how to acquire one can be found %shere%s."
msgstr "Do korzystania z Dysku Google potrzebny jest klucz prywatny w formacie p12, instrukcje jak go zdobyć można znaleźć %tutaj%s."


The last line is missing an opening markup to the documentation (%s):

Code Select Expand


msgstr "Do korzystania z Dysku Google potrzebny jest klucz prywatny w formacie p12, instrukcje jak go zdobyć można znaleźć %stutaj%s."


In order to (hackishly) update languages I had to do the following

• Clone the repo
• Follow the readme describing the installation of dependencies
• Ignore 'make fetch' since I wanted to use the current .p files (but did 'make test')
• I edited the line, issued a 'make test', then 'make install'
• Restarted all services from the console menu ('11')

The later was required since switching the language in the UI didn't fully reload the translations.
Can you confirm it fixes your issue to?

I'd have directly contributed the fix on translate.opnsense.org, but currently I can't join the project on poeditor.com ("This project can't accept new contributors a this time. Please try again later")

Hi there

I've realized that while LDAP autocreation of (in my case admin) users work pretty well (definitely appreciate it!) and newly-created accounts get the right permissions in the Web UI based on LDAP group memberships, even sudo worked - but the login shell defaults to /sbin/nologin.

The result is that even if they add their SSH keys such users cannot log in via SSH nor can they log into a shell on i.e. the local VGA or serial console.  ;)

I've realized this on our OPNsense cluster on 22.4 but was able to reproduce this on my personal system running 22.7 I know it's minor but I tried finding options in the UI and source code for either:

• Define the login shell based on an LDAP attribute mapping (this can have disadvantages if LDAP is unavailable)
• Set a selectable default shell for new-ly created users in the auth server?

It took me some time to realize what (seems) was happening at first. Looking forward to an input, maybe I can figure out a small addition to the Authentication code in the core repository.

Any other/better ideas?

Short update: So far said E810 has been recognized by 22.1, not 21.7: A quick look into the commit history showed that the ice(4) driver was only part of FreeBSD starting with 12.2 and 13.0. OPNsense 21.7 was still based on HardenedBSD 12.1 which in turn was based on FreeBSD 12.1. 22.7 is likely going to be rebased on the latest FreeBSD 13-STABLE branch and will contain a newer version, while 22.1 ships ice(4) 0.28.1.

What I can confirm is that the like the 700 series (Fortville) they also have an integrated LLDP agent which does interfere with lldpd when instaled on the OS side. I prefer to disable via UEFI in this case. This is an unbranded Intel card, so options might be different for people that might have an OEM card.

I can't share any experiences yet on how fast and / or how stable it works though, if time permits and I remember, I'll share updates.

Hi there

I wanted to ask if anyone could share some experiences on the new PCIe 4.0 800er series Intel NICs as I've only found someone having intially had some performance issues with them in this thread: https://forum.opnsense.org/index.php?topic=24302

Global delivery chain issues have now come to the point where obtaining known-to-work Intel 700 series NICs has become difficult. After considering more readily available Broadcom NICs instead, I realized that Netmap support, as required by Suricata and Zenarmor looks dim with bnxt(4) based on reading FreeBSD manpages. So I was looking at the 800 series cards like the E810-XXVDA2.

However I'm partially burned by the ugly issues the earlier firmware I've initially faced when I got the first 700 series NICs. Most of these stability issues and bugs I've faced on FreeBSD, Linux and Windows are now fixed by current firmware (which for some OEM cards can be difficult) and drivers. They are not new anymore and usually they are now "OK to work with" in my opinion.

The 800 series however are using new chips have more feature-rich firmware (read: potential for new bugs) and use a new driver ice(4) instead...

Hi

A colleague and I have mostly migrated from pfSense to OPNsense since summer and besides of some human habits that need to change a bit, the migration has been very smooth. (and we definitely plan on getting a business subscription).

While migrating the remaining OpenVPN service to it, my colleague and I ran into an issue that is due to the divergence between OPNsense and pfSense: Our 3 OpenVPN instances (that have different access policies) are currently authenticated against RADIUS backend and therein lies the issue:

Currently we are not able to clearly identify if a RADIUS Access-Requests coming from the OpenVPN server, nor which instance it is.

• On pfSense NAS-Identifier is "openVPN" while NAS-Port contains the port on which the OpenVPN server is running (i.e. 1194, 1195 etc.).
• On OPNsense NAS-Port seems to always be 0 while NAS-Identifier is a random string per RADIUS server backend defined in OPNsense (as <refid></refi> on config.xml)

Technically we can move that to LDAP, but we have been quite happy with the fact that we delegated the authorization part to our FreeRADIUS servers instead of implementing this logic on the Firewall side.

Based on checking both source code repos, this differentiation in RADIUS requests was only added after the split between both projects. And that code was only added when pfSense has switched their license and has diverged quite a bit by now.

It seems that expanding some bits in https://github.com/opnsense/core/blob/96214877bef00c196903a9ec8b4e1afac75b7a18/src/opnsense/mvc/app/library/OPNsense/Auth/Radius.php#L106

Bin zwar nur ein bis vor kurzem aussenstehender (nicht-registrierter) Mitleser und deshalb ist meine Stimme nich sooo relevant.  :P

Als Kontext: Bei mir kein absolut zwingender Grund (das "gute alte" UFS ist auch solid), aber mit ZFS kann ich zumindest Updates entspannter angehen lassen. Seit FreeBSD selber 'bectl' von Haus aus mitbringt, kann ich ohne jegliche Zusatzpakete (beadm) ein boot environment machen, lasse das Update durchlaufen und wenn es Problem gibt, boote ich halt ins alte BE zurück. Ausser der Zeit fürs rebooten weiss ich, dass ich ohne Schmerzen auf einen "known good" Zustand zurückkehren kann.

Eine Frage an Franco: Wäre das das relevante repository? https://github.com/opnsense/installer/

Zeit habe ich auch nicht im Überfluss, aber einen Blick werfen, was fehlt, sollte ich noch schaffen, vielleicht reichts einmal für 1-2 Zeilen Patches, wer weiss...  :)