Project

General

Profile

Actions
Copy link

Feature #9742

closed

Print Patch ID in log while patching

Added by Viktor Gurov over 4 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Renato Botelho
Category:
System Patches
Target version:
-
Start date:
09/10/2019
Due date:
% Done:

100%

Estimated time:
Plus Target Version:

Description

that would be very useful for support and security perspective.

for now it only run ACB backup while patching.

Files

Screenshot from 2019-10-10 18-33-57.png (69.5 KB) Screenshot from 2019-10-10 18-33-57.png Viktor Gurov, 10/10/2019 10:40 AM
Actions
Copy link
 #1

Updated by Jim Pingle over 4 years ago

  • Target version deleted (2.5.0)
Actions
Copy link
 #4

Updated by Jim Pingle over 4 years ago

  • Subject changed from print Patch ID in log while patching to Print Patch ID in log while patching
  • Status changed from New to Pull Request Review
Actions
Copy link
 #5

Updated by Renato Botelho over 4 years ago

  • Status changed from Pull Request Review to Feedback
  • Assignee set to Renato Botelho
  • Target version set to 2.5.0
  • % Done changed from 0 to 100

PR has been merged. Thanks!

Actions
Copy link
 #6

Updated by Viktor Gurov over 4 years ago

Actions
Copy link
 #7

Updated by Jim Pingle over 4 years ago

  • Target version deleted (2.5.0)
Actions
Copy link
 #8

Updated by Viktor Gurov over 4 years ago

tested on pfSense 2.5.0.a.20191121.2127 with System_Patches 1.2_4
test patch: https://github.com/pfsense/pfsense/commit/15701e03e36051907a23ddbe5ab04f42c94c0944.patch

Works ok, but on every patching I also got such message in logs:

Logging subprocess 84289 (exec /usr/local/sbin/sshguard) exited with status 1.

Actions
Copy link
 #9

Updated by Jim Pingle over 4 years ago

The sshguard log message wouldn't be related.

I see logs for manual patching and reverting, but no log messages when auto-apply happens at boot time. It may not be the fault of the code, though, since it's an early shell command it may be run before logging starts, so logging via syslog at that point may not be possible. It has to run that early or it may not get run before other components that need to get patched before starting.

Instead of using syslog, it could write to its own log file directly, but that seems like overkill just for this.

Actions
Copy link
 #10

Updated by Danilo Zrenjanin over 3 years ago

  • Status changed from Feedback to Resolved

Tested on :

2.5.0-DEVELOPMENT (amd64)
built on Tue Oct 13 19:05:31 EDT 2020
FreeBSD 12.2-STABLE

System Log displays the applied patch ID.

Ticket resolved.

Actions
Copy link

Also available in: Atom PDF