@kmarston fixed it, thanks!

@johnpoz - both of those packages appear to now be in the "available packages" list. Seems odd that for a couple hours they (BIND/Avahi) were 'missing' from the list, but hours later appear. Following the commentary from posts about "install from scratch" (using the copy config.xml to USB for restore) - only impact was where those two packages were absolutely required. Interesting on the naming aspect. Under 2.5.2, made sure that all the packages had been on the latest version, prior to upgrade. Not sure if that artifact is useful.

While a bit off topic - where BIND/Avahi weren't required, the process was flawless and (as others have noted) there appears to be a sense of increased performance. (Hats off to folks responsible)

Thanks!

@luckman212 said in new System Patches v2.0:

@jimp I had to flip my update branch from 22.05 to 22.01 in order to see the 2.0_4 version. I installed it and then flipped back to the 22.05 track. Is that "normal"?

I didn’t have to do this
FYI

The end result (that wouldn't involve recompiling my own kernel/drivers etc) was to simply change the VID/PID in the display from the out of box settings of 0x1b3d/0x0155 to the FTDI defaults of 0x0403/0x6001. You can do this with "FT_Prog" on another computer running Windows or you can do it with another computer using "ft232r_prog" on Ubuntu Linux.....

sudo ./ft232r_prog --old-vid 0x1b3d --old-pid 0x0155 --new-vid 0x0403 --new-pid 0x6001 ft232r_prog: version 1.25, by Mark Lord. eeprom_size = 128 vendor_id = 0x1b3d product_id = 0x0155 self_powered = 0 remote_wakeup = 0 suspend_pull_downs = 0 max_bus_power = 500 mA manufacturer = MO product = LK202-25-USB serialnum = 01wwkXXX high_current_io = 0 load_d2xx_driver = 0 txd_inverted = 0 rxd_inverted = 0 rts_inverted = 0 cts_inverted = 0 dtr_inverted = 0 dsr_inverted = 0 dcd_inverted = 0 ri_inverted = 0 cbus[0] = TxDEN cbus[1] = TxDEN cbus[2] = TxDEN cbus[3] = PwrEn cbus[4] = TxDEN Rewriting eeprom with new contents. /tmp/MO/ft232r_prog-1.25$ sudo ./ft232r_prog --save MO-lk202-25.dump ft232r_prog: version 1.25, by Mark Lord. MO-lk202-25.dump: wrote 128 bytes eeprom_size = 128 vendor_id = 0x0403 <---- IT'S DIFFERENT NOW product_id = 0x6001 <---- AND THIS IS TOO self_powered = 0 remote_wakeup = 0 suspend_pull_downs = 0 max_bus_power = 500 mA manufacturer = MO product = LK202-25-USB serialnum = 01wwkXXX high_current_io = 0 load_d2xx_driver = 0 txd_inverted = 0 rxd_inverted = 0 rts_inverted = 0 cts_inverted = 0 dtr_inverted = 0 dsr_inverted = 0 dcd_inverted = 0 ri_inverted = 0 cbus[0] = TxDEN cbus[1] = TxDEN cbus[2] = TxDEN cbus[3] = PwrEn cbus[4] = TxDEN No change from existing eeprom contents.

Once that's done, you can plug it back in to pfsense and the driver will pick it up and ugen will do it's thing etc.... You'll finally end up with all of the

/dev/cuaU0
/dev/cuaU0.init
/dev/cuaU0.lock

things that you need in /dev/ that you can then use to point the webUI/lcdproc towards.

Typically I believe the Netgate team expects a pull request against the appropriate GitHub repository. For packages, that would be ../pfsense/FreeBSD-ports available here: https://github.com/pfsense/FreeBSD-ports.

There are some specific requirements in order for packages to work within the pfSense ecosystem. You can look over some of the packages to see what those are. GUI packages will start with the string "pfSense-pkg-*". Any underlying binary component is assumed to exist within the regular Ports tree of FreeBSD.

yeah - knew it must be a stupid question. found the option to add the CSP to the specific backend rather than in the shared frontend. all good

@robert_knabe

As far as I know, no one is complaining about the small file size handling capability of pfSense.
The RRD files will still fit into the confiig file, and if logs are important (they are for me) an external syslogger shiould be used.

But, why not, if you want, you can modify the php.ini file, as that's the way to change memory available to PHP.

Two options :
Write a small shell script that modifies the memory_limit if it doesn't contain the right value for you. Have this script started with the startcmd pfSense package. Use commands like 'sed' to replace a text in the file. You probably have to restart the PHP-FPM to take the new setting in account.

Or, edit the php.ini file, and keep the old one.
Create a diff file from these two files.
Use the diff file and the pfSense patch package to patch the existing php.ini file.
You will still have to restart php-fpm to have the modification taken in account.

Both solutions will persist even after a pfSense upgrade.

You could add a feature request, just keep in mind that it would be granted only if a lot of people are asking for it.

Please show the contens of /usr/local/etc/avahi/avahi-daemon.conf, and tail -n 50 /var/log/system.log output after restarting Avahi.

Disregard. Upgraded OS to pfSense 22.01 and the package works fine now.

@steveits
Thanks again!
Yes, if I configure System -> Updates to stay at 2.5.2 (DEPRECATED) I do not see any available updates for my apps.

But when I change to 2.6.0 I see updates for some of the apps. Still not for all, but this should be not an issue as they will run anyways- because there is no red sign then.

Ok, I think I got it!

Thanks a lot!

/KNEBB

@nogbadthebad

Correct. Supermicro IPMI.

Most of my searches found people having issues getting authentication working with Supermicro.

My issue is that all other devices that use RADIUS for authentication are all working (UPS’s, Supermicro IPMI, TrippLite PDU). It’s just the pfSense itself.

Not sure if you figured it out already since this post is a few days old, but I think you need to do two things:

Remove your "Default Backend" entry (if you have a default entry, everything will be sent to that backend, regardless of the ACL you defined above) For the "Use Backend" action, you wanna populate the "Condition Acl Name" field or else the action wont match.
So in your case, set the "condition acl name" to "LookingGlass" (the name you gave your "Host Matches:" ACL)

You now should get a 503 error for all other requests until you define another acl that matches the host name and send that to the same (or a different) backend via another "Use Backend" action entry.

Hope this helps. Still a beginner with ha proxy so not sure if this is the way to go, but for me in a similar situation that was what I had to do.