* MVC / System status: first draft for backend implementation * fix copyright * fix permissions * MVC / System Status: modify backend implementation and setup front-end * MVC / System Status: minor cleanup, ACL check and fix reporting in production mode * MVC / System Status: copy status sytem to legacy as well, remove the notices system, finish up front-end work * MVC / System Status: remove useless constructor * fix plist * System Status: shorten previous * System Status: add ACL check * System Status: also remove legacy part * System Status: also clean up on legacy page * System Status: ACL check on dismiss action as well * System Status: add readonly privilege check to dismiss action * System Status: do not trust input * System Status: address security concerns * add default return * System Status: move js code to separate script and make sure a logLocation is always provided * System Status: clean up callout in both legacy page and volt template After dismissing a message and closing the dialog, the old message was still bound to the dialog instance. re-registering the onclick callback solves this. * System Status: adjust log location and kick off status system on alias errors * System Status: let's hold off on throwing notifications for aliases for now * System Status: add ACL entry for the dismiss API call, adjust to new deployment situation Without the ACL entry, /api/core/system/dismissStatus calls are rejected for non-root users even when they should have rights to dismiss. Also do a minor consistency improvement and also adjust to the new situation of production & development deployment types. We need to account for the possibility of 'deployment' being empty in the configuration, therefore a direct check of the 'development' type seems most fitting as this is unlikely to change or be subjected to any additions. * System Status: also error out when unable to write new rules * System Status: account for users without permissions * System Status: name collision in FirmwareController * System Status: replace old notices system with a global one (https://github.com/opnsense/core/pull/5875) Review feedback / modifications in this commit: o filter.inc -- remove wedged message, when locked during parallel reloads it likely doesn't help to disable/enable -- flush message to error trigger file o SystemStatus.php -- str_contains --> strpos; eases testing on OPNsense 22.1.x as str_contains is php 8 only o Status collectors -- simplify logic and propagate messages received from status file o CrashReporterStatus - the existence of a /tmp/PHP_errors.log file should be enough to know some process signaled the crash reporter - remove shell exec o FirewallStatus -- as only /tmp/rules.error remains, remove loop to read for non existing files o opnsense_status.js -- add opn-status-group class to container and point css modifications in that single direction to prevent other objects from being affected by our status popup modifications -- windows file endings replaced (^M) o css: keep menu_messages container to ease migration for theme developers NOTE : ** get_crash_report() could likely be simplified as well * filter: change to mwexec, redirection is implied * System Status: handle potential undefined array key seems to be a one-off error: Exception: Error at /usr/local/opnsense/mvc/app/controllers/OPNsense/Core/Api/SystemController.php:90 - Undefined array key 0 (errno=2) in /usr/local/opnsense/mvc/app/controllers/OPNsense/Base/ApiControllerBase.php:159 Co-authored-by: Ad Schellevis <ad@opnsense.org>
OPNsense GUI and system management
The OPNsense project invites developers to start contributing to the code base. For your own purposes or – even better – to join us in creating the best open source firewall available.
The build process has been designed to make it easy for anyone to build and write code. The main outline of the new codebase is available at:
https://docs.opnsense.org/development/architecture.html
Our aim is to gradually evolve to a new codebase instead of using a big bang approach into something new.
Build tools
To create working software like OPNsense you need the sources and the tools to build it. The build tools for OPNsense are freely available.
Notes on how to build OPNsense can be found in the tools repository:
https://github.com/opnsense/tools
Contribute
You can contribute to the project in many ways, e.g. testing functionality, sending in bug reports or creating pull requests directly via GitHub. Any help is always very welcome!
License
OPNsense is and will always be available under the 2-Clause BSD license:
https://opensource.org/licenses/BSD-2-Clause
Every contribution made to the project must be licensed under the same conditions in order to keep OPNsense truly free and accessible for everybody.
Makefile targets
The repository offers a couple of targets that either tie into tools.git build processes or are aimed at fast development.
make package
A package of the current state of the repository can be created using this target. It may require several packages to be installed. The target will try to assist in case of failure, e.g. when a missing file needs to be fetched from an external location.
Several OPTIONS exist to customise the package, e.g.:
- CORE_DEPENDS: a list of required dependencies for the package
- CORE_DEPENDS_ARCH: a list of special -required packages
- CORE_ORIGIN: sets a FreeBSD compatible package/ports origin
- CORE_FLAVOUR: can be set to "OpenSSL" or "LibreSSL"
- CORE_COMMENT: a short description of the package
- CORE_MAINTAINER: email of the package maintainer
- CORE_WWW: web url of the package
- CORE_NAME: sets a package name
Options are passed in the following form:
# make package CORE_NAME=my_new_name
In general, options are either set to sane defaults or automatically detected at runtime.
make update
Update will pull the latest commits from the current branch from the upstream repository.
make upgrade
Upgrade will run the package build and replace the currently installed package in the system.
make collect
Fetch changes from the running system for all known files.
make lint
Run several syntax checks on the repository. This is recommended before issuing a pull request on GitHub.
make style
Run the PSR2 and PEP8 style checks on MVC PHP code and Python, respectively.
make sweep
Run Linux Kernel cleanfile whitespace sanitiser on all files.