Bug 1082376 - RFE: custom hooks
Summary: RFE: custom hooks
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: retrace-server
Version: epel7
Hardware: All
OS: All
high
low
Target Milestone: ---
Assignee: Jakub Filak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1000441 1082327
TreeView+ depends on / blocked
 
Reported: 2014-03-30 21:29 UTC by Mateusz Guzik
Modified: 2016-04-19 21:20 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-04-19 21:20:05 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Mateusz Guzik 2014-03-30 21:29:36 UTC
Currently retrace does not support any method for running custom scripts. Two events we are mostly interested in now are:

- when vmcore setup is completed
- once it is decided to remove given vmcore, but before actual removal

Proposed user-visible implementation:
HookUser = blah
HookGroup = blah
HookPostAnalysis = /some/dir
HookPreCleanup = /some/other/dir

Then retrace would switch credentials and run each file located in HookPostAnalysis and HookPreCleanup directories respectively to current event.

Each script would receive the following arguments:
<type of event> <task id> <task directory>

where <type of event> is either "post-analysis" or "pre-cleanup"

Rationale:

We have various stuff which could be done automatically once vmcore is created (including some basic analysis). Hooks make it easy to achieve that and remove results when the core is going away.

Comment 1 Dave Wysochanski 2014-08-15 10:28:50 UTC
Examples of things that could be done with this:
1. Index of core by case # or other data (such as 'sys' output by machine name / date of vmcore - currently run via a cron job
2. Calling 'redhat-support-tool diagnose' on various files (such as the kernel log and/or oops message) - currently run via a cron job
3. Automated vmcore analysis - currently run via a cron job

Comment 2 Dave Wysochanski 2015-01-27 16:06:49 UTC
This bug is blocking progress on automated analysis and we really need to move this forward if at all possible.

Comment 4 Marek Bryša 2015-08-13 10:06:47 UTC
Is switching of the credentials really necessary?

Retrace-server runs under the non-privileged user "retrace", which cannot change the uid/gid of hooks to be run by itself.
Possible solutions:
a) Create a setuid wrapper binary inside retrace-server, that retrace-server would call. I would read the configuration, change it's uid/gid and finally call the hook.
b) Drop HookUser/HookGroup. The target hook would take care of the credentials change by being a setuid binary with the appropriate uid/gid.

Comment 5 Mateusz Guzik 2015-08-13 15:25:05 UTC
Well that's a longer story. Ideally entire retrace operation would be done without any kind of credential switching (not the case at the moment), filesystems would be mounted nosuid and so on. Current model of retrace operations is extremely fragile and it already changes credentials in various places.

This part boils down to what expectations regarding security are there. I assumed it would make sense to treat hooks as untrusted, but don't feel strongly about it.

Assuming cred switch is to be done for hooks and there is only one blessed uid:gid pair for hooks, it could be done instead with having an appropriate uid:gid as the owner of a suid binary.

Comment 6 Mateusz Guzik 2015-08-13 15:31:38 UTC
Weird, looks like you wrote the same thing in b. Sorry. :)

Still, what I'm trying to say is the entire model of retrace operation (and a lot internal code) would likely want a major overhaul which may or may not affect hooks.

In particular currently retrace is quite monolithic doing plenty of independent steps on its own. Ideally there would be dedicated scripts for each step (unpack a vmcore, get kernel version, find relevant kernel rpm and so on).

Comment 7 Marek Bryša 2015-08-17 10:35:43 UTC
Upstream pull request: https://github.com/abrt/retrace-server/pull/88

Issue for the monolith split: https://github.com/abrt/retrace-server/issues/89

Comment 8 Jakub Filak 2015-12-16 07:00:53 UTC
The upstream pull Marek Brysa referenced in comment #7 has been merged. Can we close this bug?

Comment 9 Dave Wysochanski 2016-04-19 21:20:05 UTC
(In reply to Jakub Filak from comment #8)
> The upstream pull Marek Brysa referenced in comment #7 has been merged. Can
> we close this bug?

Yes I think we can mark this fixed as at least we've got an implementation now and from what I can tell it works fine.  It's not exactly the implementation described https://bugzilla.redhat.com/show_bug.cgi?id=1082376#c0 so we may need further patches to get exactly what we want.  For example there's no "HookUser" or "HookGroup" but we can run as retrace {AuthGroup} for now.  We also probably need the ability to add multiple scripts inside any given hook (for example, multiple scripts should run in the post_retrace hook) but that can be later too.

I tested this in retrace-server-1.15-1.el6.noarch with a simple post_retrace hook which uses the 'caseno' field and creates an index inside /retrace/index/by-caseno.  I had to manually create this directory and of course set proper user and group ownership and permissions but it works fine.

$ cat /etc/retrace-server.conf
...
[hookscripts]
...
# After retracing is done
post_retrace = /retrace/index/by-caseno/index-one-vmcore-task.sh {task_id} {task_dir}

$ cat /retrace/index/by-caseno/index-one-vmcore-task.sh 
#!/bin/bash
#
# Create a simple directory index, by case, for retrace tasks
#
INDEX_DIR=/retrace/index/by-caseno/
TASK_ID=$1
TASK_DIR=$2
if [ ! -f $TASK_DIR/caseno ]; then
   exit 1
fi
CASE=`printf "%09d" $((10#$(cat $TASK_DIR/caseno)))`
echo "Indexing retrace-server task $TASK_ID in $INDEX_DIR"
if [ ! -d $INDEX_DIR/$CASE ]; then
  echo "Creating directory for case $CASE"
  mkdir $INDEX_DIR/$CASE
fi
# Tasks without finished_time are probably incomplete and should be deleted
if [ -e $TASK_DIR/finished_time ]; then
  TIME=$(cat $TASK_DIR/finished_time)
  INDEX=$INDEX_DIR/$CASE/$(date "+%Y-%b-%d-%H%M" --date=@$TIME)-$TASK_ID
else
  INDEX=$INDEX_DIR/$CASE/$TASK_ID
fi
if [ ! -e $INDEX ]; then
  echo "Creating symlink of task $TASK_ID associating with case $CASE"
  ln -s $TASK_DIR $INDEX
fi


Note You need to log in before you can comment on or make changes to this bug.