I was just using console menu option 16 Restart PHP-FPM and it hung on a nanoBSD system.
I found /tmp/php_errors.txt with this in it:
"override rw-r--r-- root/wheel for /usr/local/etc/php.ini?"
Flying blind at the console I entered "y", then /tmp/php_errors.txt had this:
--------
rm: /usr/local/etc/php.ini: Read-only file system
override rw-r--r-- root/wheel for /usr/local/lib/php.ini?
--------
Pressed return at the console and it proceeded, presumably without re-writing php.ini
It works much better when the file system is mounted RW :)
Set the time limit to 0 and restore it back to default value when this is detected.
* Do not leak pipes when reloading ruleset for CP since this will consume available descriptors.
This has been noted before but considered fixed, this is the real fix actually for dnpipes.
When a dynamic gateway is disabled (by the user through the webGUI), it was still being returned by return_gateways_array(). But when called like that, disabled gateways should not be returned. The first part of the routine was correctly skipping disabled gateways, but then the later part would effectively re-generate those dynamic gateways on-the-fly and not realise they should be skipped because they were disabled.
This code now remembers gateway details of all the gateways, including skipped ones, so the dynamic gateway code can easily realise all gateways that have been already processed, even those that were processed and skipped.
Forum: https://forum.pfsense.org/index.php?topic=86565.0
It fixes Gateway Status Widget - now if a dynamic gateway is disabled, it does not appear on the display.
This will also stop disabled dynamic gateways from being returned to other callers. So there may/will be impacts on other parts of the system when a user disables a dynamic gateway. e.g. filter.inc - a gateway that has been disabled by a user canot be used in rules any more.
Obviously a typo. But this section is inside:
if (isset($_POST['add_x']) && isset($_POST['if_add'])) {
and I cannot find where 'add_x' is ever sent here, so I do not see how this whole code section is ever executed (and that will be why this typo bug has no symptoms). What is the history here? Can the whole block of code be removed?
The code normally executed is the section for 'Submit' lower down.
Forum https://forum.pfsense.org/index.php?topic=86478.0
PEAR is used by
IPv6.inc
auth.inc
captiveportal.inc
radius.inc
xmlrpc_client.inc
radius_accounting.inc
radius_authentication.inc
I have just changed this 1 function to "public static"
Also used are:
PEAR::raiseError
PEAR::loadExtension (already has "static function")
Not sure if PEAR::raiseError will throw a similar "static method" call
warning, not game to touch it.
Fix various files that can emit messages like:
PHP Strict Standards: Non-static method SimplePie_Misc::array_unique()
should not be called statically, assuming $this from incompatible
context in /etc/inc/simplepie/simplepie.inc on line 5508
php-fpm[16262]: /rc.newipsecdns: PHP ERROR: Type: 8192, File:
/etc/inc/shaper.inc, Line: 4365, Message: Assigning the return value of
new by reference is deprecated
Some of these style messages have been reported on the forum, e.g.
https://forum.pfsense.org/index.php?topic=86448.0
I had RSS widget on, and simplepie sent the system beserk telling about
all this stuff.
- Move redundant code to a function parse_aliases_file(). Before the max
number of items was not being respected when URL content is updated,
only when alias was saved. Same was happening with ip/subnet/port
validation and user could end up with a bad pf.conf
- Remove unused variables
These changes were based on Pull Request #1264. It should fix#4189
Submitted by:▸ PiBa-NL
A few functions such as ipcmp(), subnet_expand(), and check_subnets_overlap() are in illogical places - away from all the other ip comparison and subnet basic functions and in the middle of alias handling and interface enumeration.
No change to functional code, just moving to earlier in the file (next to other IP compare and subnet functions) for ease of future contributors.
