User contributed System Patches library?
-
Officially, I gather the System Patches package is used rarely or in a limited way, and doesn't seem to get attention as a way to enhance pfsense.
But Pfsense has a very wide user base, many of whom are enthusiasts and mod or innovate on their own platforms.
I'm wondering what people here who use Pfsense would think about some kind of user-contributed thread or library for patches they use.
Obviously user contributed patches (add-ons, extensions, plugins, scripts, etc) won't have the same level of scrutiny and certainty as "official" code, but that doesn't stop it being a widely adopted model in other platforms and software. People who have adopted a "DIY" soft router in the first place (as opposed to a 'boxed' commercial or ISP supplied router) are also probably competent to understand the implications, risks and need for review, and the implications of informal or no support.
It may help users to find solutions or improvements for their installs that they did not otherwise have, users with specific wishes or preferences that don't match the mainstream or core developers' concepts to find and share improvements to suit their niche, and also it allows insight into what kinds of things (possibly just minor or UI) users actually want that aren't there right now, so it may suggest which patches are worth migrating into the main codebase due to having a higher level of user enthusiasm.
Even if a structured library isn't viable, perhaps a searchable thread would be sensible - a couple of patches I use are below, in case anyone else finds them useful or wants to do the same.
-
Colorise DHCP leases to highlight online/active leases more (works on 2.1 and 2.1.1 beta)
Although "table sort" exists, the existing DHCP leases page doesn't easily lead the eye to the few active leases among many inactive leases.--- /usr/local/www/status_dhcp_leases.php 2013-10-08 23:56:08.000000000 +0100 +++ /usr/local/www/status_dhcp_leases.php 2013-10-08 10:34:09.000000000 +0100 @@ -358,6 +358,16 @@ } else { $fspans = $fspane = ""; } + if ($data['online'] == "online") { + $fspans2 = 'style="background-color:#00ff00"'; + } else { + $fspans2 = ""; + } + if ($data['act'] == "active") { + $fspans3 = 'style="background-color:#00ff00"'; + } else { + $fspans3 = ""; + } $lip = ip2ulong($data['ip']); if ($data['act'] == "static") { foreach ($config['dhcpd'] as $dhcpif => $dhcpifconf) { @@ -408,8 +418,8 @@ echo "{$fspans} n/a {$fspane} \n"; echo "{$fspans} n/a {$fspane} \n"; } - echo "{$fspans}{$data['online']}{$fspane} \n"; - echo "{$fspans}{$data['act']}{$fspane} \n"; + echo "{$data['online']} \n"; + echo "{$data['act']} \n"; if ($data['type'] == "dynamic") { echo "[";](\"services_dhcp_edit.php?if={$data['if']}&mac={$data['mac']}&hostname={$data['hostname']}\") ``` [**Increase max displayable log entries limit from 2000 (works on 2.1 and 2.1.1beta)** Given a powerful router platform, a more paranoid user :) or a need to research visible issues or log anomalies, the option to view more log entries than 2000 could be worthwhile for some users
--- /usr/local/www/diag_logs_settings.php 2011-12-12 21:55:08.000000000 +0000
+++ /usr/local/www/diag_logs_settings.php 2012-03-07 14:05:39.698396700 +0000
@@ -88,8 +88,8 @@
$input_errors[] = gettext("A valid IP address must be specified.");
}- if (($_POST['nentries'] < 5) || ($_POST['nentries'] > 2000)) {
-
$input_errors[] = gettext("Number of log entries to show must be between 5 and 2000.");
-
if (($_POST['nentries'] < 5) || ($_POST['nentries'] > 5000)) {
-
$input_errors[] = gettext("Number of log entries to show must be between 5 and 5000.");
}
if (!$input_errors) {
**Increase number of backed-up configs from default of 30 (works on 2.1 and 2.1.1beta)** A surprising number of changes lead to a new "backed up configuration". As only 30 are stored by default, it can mean that old, useful configs have been deleted by the time they are wanted for restore, if there turns out to be a problem requiring rollback, especially during non-production testing or from the console. Config files are quite small so there is little cost in keeping almost arbitrary many more than 30 past versions, disk space permitting.
--- /etc/inc/config.lib.inc 2013-09-11 23:20:11.000000000 +0100
+++ /etc/inc/config.lib.NEW.inc 2013-12-19 22:17:44.000000000 +0000
@@ -536,7 +536,7 @@
if($g['platform'] == "embedded" or $g['platform'] == "nanobsd") {
cleanup_backupcache(5, true);
} else {-
cleanup_backupcache(30, true);
-
cleanup_backupcache(2000, true);
}
/* re-read configuration */
@@ -725,7 +725,7 @@
return true;
}
-function cleanup_backupcache($revisions = 30, $lock = false) {
+function cleanup_backupcache($revisions = 2000, $lock = false) {
global $g;
$i = false; -
Thanks for these.
-
We use the System Patches package heavily in development and testing, for adding customer-specific fixes/work-arounds, and for deploying fixes to customers between releases.
My directory of patches is by no means "official" but it's close. Eventually those will probably make it into some form of patch list kept somewhere in the packages repository.
I've thought about having it load a patch list/manifest file and offering some common patches, but the more I've thought about it, the more inclines I am to never go that far because if it's too easy, people will start slapping them on without thinking and not knowing what they do. :-)
A thread is fine for keeping user-submitted patches. Might want to add a warning to the first post to caution people against loading random patches without understanding what they do.