Retain customizations without breaking daily.sh

Help
1
Summary

This text will be hidden

Hi All. We made changes to config/snmptraps.php, added mibs in mibs/ and custom php files in LibreNMS/Snmptrap/Handlers/ while trying to write custom trap handlers. daily.sh was fine for a few days but has been failing the last couple of days with the following error:

We just attempted to update your install but failed. The information below
should help you fix this.
error: Your local changes to the following files would be overwritten by
merge:
config/snmptraps.php
Please, commit your changes or stash them before you can merge.
Aborting

validate.php advises running scripts/github-remove. But when that is run with the -d flag, all changes are reverted, php files added to LibreNMS/Snmptrap/Handlers/ are all deleted. Is there a best practice that anyone is using to prevent this revert action from happening and to maintain our customizations while still allowing daily.sh to run? We have gone down the path of backing up our changes prior to running github-remove and then restoring our changes but it’s becoming tedious to have to do that.

Results of validate.php:

====================================

Component Version
LibreNMS 1.51-16-g308145d
DB Schema 2019_02_10_220000_add_dates_to_fdb (132)
PHP 7.2.16
MySQL 5.5.60-MariaDB
RRDTool 1.4.8
SNMP NET-SNMP 5.7.2

====================================

[OK] Composer Version: 1.8.5
[OK] Dependencies up-to-date.
[OK] Database connection successful
[OK] Database schema correct
++++++++++++++++++++++++++++++++++++
Any advice/direction would be helpful and appreciated. Thanks in advance.

2

If possible I’d run multiple instances of LibreNMS, one for production which only gets changes from the repo and another for testing on a separate server. I’m planning on doing this prior to bringing LibreNMS into production. For the time being I’m doing exactly what you are doing though.

3

Yep, having 2 servers, one for dev and one for prod seems a minimum.

4

Thanks for the responses. We’re completely new to LibreNMS. The issue was discovered on the test/dev system prior to going into production. The environment is setup with a test/dev, qa, and 2 prod servers (active-warm standby). I was hoping the community had dealt with this more efficiently and did not want to have to do what both myself and Heath are doing - backing up changes, updating, then putting the changes back - once we go to production.

5

On the prod server, you are not supposed to change anything. And prod is the important one.
On dev server, you do developpement. For this purpose, you have all the ‘git’ power (branches, commits, pull requests to send your changes to LibreNMS community) and this will do the trick. No more changes copy/pastes will be necessary.