plugins icon indicating copy to clipboard operation
plugins copied to clipboard

sysutils/git-backup: rc.syshook.d script does not appear to be running on 22.7-RC2

Open g-a-c opened this issue 2 years ago • 5 comments

Important notices Before you add a new report, we ask you kindly to acknowledge the following:

  • [x] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
  • [x] I have searched the existing issues, open and closed, and I'm convinced that mine is new.
  • [x] The title contains the plugin to which this issue belongs

Describe the bug Since around the time I installed 22.7-RC2, my Git repo in /conf/backup/git has had no commits made to it, even though config backups are correctly being created in the "native" /conf/backup directory.

I temporarily added a print() statement into my local copy of 10-git-backup to write a line to a file in /tmp to prove whether the syshook script was running and found that it appears to NOT run when the configuration is changed. I've tried reinstalling the git-backup plugin, and I've verified that the URL and key are correct. The fact that there are no local commits on the appliance indicates that it's a deeper issue than the config being wrong...

--- 10-git-backup       2022-07-13 09:58:14.000000000 +0100
+++ /tmp/10-git-backup  2022-07-26 22:38:27.034243000 +0100
@@ -26,6 +26,8 @@
 import sys
 import xml.etree.ElementTree as ET

+with open('/tmp/readme.txt', 'w') as f:
+  f.write('readme')

 if len(sys.argv) > 1:
     commit_msg =  "unknown change"

Tip: to validate your setup was working with the previous version, use opnsense-revert (https://docs.opnsense.org/manual/opnsense_tools.html#opnsense-revert)

To Reproduce Steps to reproduce the behavior:

  1. Install 22.7-RC2
  2. Install the git-backup plugin
  3. Configure a remote Git system
  4. Make some config changes
  5. Check that local backups are created in /conf/backup
  6. Check whether any commits were made in /conf/backup/git

Expected behavior Local commits are present, and these are correctly pushed to the configured remote

Screenshots If applicable, add screenshots to help explain your problem.

Relevant log files If applicable, information from log files supporting your claim.

Additional context Add any other context about the problem here.

Environment Software version used and hardware type if relevant. e.g.:

OPNsense 22.7-RC2

g-a-c avatar Jul 26 '22 21:07 g-a-c

I don't think anything changed there recently, best check logs first. syslog-ng is responsible for firing the event, it uses this template (triggers on message config-event: new_config):

https://github.com/opnsense/core/blob/master/src/opnsense/service/templates/OPNsense/Syslog/syslog-ng-config-events.conf

Which executes this hook: https://github.com/opnsense/core/blob/master/src/opnsense/scripts/system/trigger_config_changed_events.py

AdSchellevis avatar Jul 27 '22 06:07 AdSchellevis

OK, I think I fixed the problem, but I'm not sure how...

I took a look at those links, and that made sense to me (watch for an event, send a payload to a command). The trigger_config_changed_events.py alerted me to the fact there's a timestamp file in /conf - mine had a modification time of approximately 6 hours after the last Git commit, with the timestamp inside it being exactly 1 minute after the last Git commit

-rw-r-----  1 root  wheel      40 Jul 17 18:05 event_config_changed.json

root@opnsense:/conf/backup/git # cat /conf/event_config_changed.json
{"last_proccessed_stamp":1658052918.489}

I deleted this file to see if it would be recreated, and as soon as I made a configuration change it was recreated with a fresh timestamp, and a Git commit was made locally. The timer hasn't fired to git push the change but I expect that will work too.

Not sure how my appliance got into this state, it's been rebooted several times since that July 17th timestamp so there should have been no file locks in place and trigger_config_changed_events.py is written to handle the file already being present (i.e. it doesn't fail if it's unable to create the file) so the file already existing with an old timestamp looks like it should have been fine. But deleting that file appears to have got everything working again, just with a missing chunk of history for the last 10 days which is fine.

g-a-c avatar Jul 27 '22 07:07 g-a-c

Same thing here -- I was hitting the problem in https://github.com/opnsense/plugins/issues/2994 and the fix was to manually delete /conf/event_config_changed.json which then allowed me to initiate the backup

feld avatar Jul 29 '22 14:07 feld

this https://github.com/opnsense/core/commit/3b7453ca2bb2bdbc63a101a43b1ac9cc84c33ff2 would be problematic, https://github.com/opnsense/core/commit/c21cafa924d4f4e33ae6c290588f852c43ddd0c6 partially fixes it, but isn't perfect as we'll still loose track of time. Fixing typo's is often a good idea, but values are stored it can be quite problematic cc @jsoref @fichtner

AdSchellevis avatar Jul 29 '22 14:07 AdSchellevis

this opnsense/core@3b7453c would be problematic, opnsense/core@c21cafa partially fixes it, but isn't perfect as we'll still loose track of time. Fixing typo's is often a good idea, but values are stored it can be quite problematic cc @jsoref @fichtner

Thanks, I bet that would do it. I didn't notice the typo in my previous comment, and I hadn't noticed that after I deleted and allowed the file to be recreated, the spelling was now correct. That makes a lot of sense now!

g-a-c avatar Jul 29 '22 14:07 g-a-c

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository, please read https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.

OPNsense-bot avatar Jan 22 '23 21:01 OPNsense-bot