System: Settings: Tunables Duplicates and Missing entries 19.7.5

Started by AhnHEL, October 12, 2019, 09:48:07 PM

Previous topic - Next topic
I upgraded to 19.7.5 so not sure when this started but if I create a new Tunable, the setting seems to take effect but the Tunable will not be listed with the others.

Also, there are two entries for net.inet.ip.redirect duplicated.  If I delete one, then there will then be a duplicate entry for security.bsd.see_other_uids which is the Tunable right above it. 

Yes, I've already tried using the Default button and it re-creates the same behavior.  I see this on all 3 of my boxes.

Strange, can anyone else confirm?
AhnHEL (Angel)

On the face of it, the two last entries seems duplicated.

hw.igb.tx_process_limit      Unlimited packet processing    1
hw.igb.tx_process_limit      Unlimited packet processing    1

But the actual content of the very last entry is different from the previous:

Tunable:       hw.igb.tx_process_limit
Description:  Unlimited packet processing
Value:          1

Tunable:       net.link.ether.inet.max_age
Description:  ARP table refresh time (default 1200 sec)
Value:          300

@AhnHEL

I can't confirm your specific settings. Probably because I'm on a different hw platform: PC Engines APU2C4 (AMD)

I'm also om 19.7.5-amd64

Err, it looks like a PHP core error.  "Fixed" it with https://github.com/opnsense/core/commit/9299386602f but both versions should be equivalent for what $tunable will hold although they are certainly not...

old: <?php foreach ($a_tunable as $i => $tunable): ?>

new: <?php foreach ($a_tunable as $i => &$tunable): ?>


Cheers,
Franco

Fixed, thank you.  Will there be a 19.7.5_6?
AhnHEL (Angel)

Thank you.

This incident sparked a thought. Is the best practice between versions to revert tunables to default settings? And how does restoration of an older configuration backup file affect tunables? What I really would like to know, is if there is a risk that I at some point is having a system running obsolete tunable settings impacting the system negatively?

The risk should be minimal and you can see if the settings deviate from defaults. It's only a little hard to see which ones have defaults and which have none. I'm not sure how to change it from the current way of doing it: embedding the sysctls into the config.xml and having a second set of sysctls in system.inc for "default" purposes.

There will be no hotfix since this is cosmetic. 19.7.6 will be out next week with the patch.  :)


Cheers,
Franco