Bug 481286 - Monitoring Notification come from email <rogerthat01@redhat.com>
Monitoring Notification come from email <rogerthat01@redhat.com>
Status: CLOSED NOTABUG
Product: Spacewalk
Classification: Community
Component: Server (Show other bugs)
0.4
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Suchý
Red Hat Satellite QA List
:
Depends On:
Blocks: space06
  Show dependency treegraph
 
Reported: 2009-01-23 07:47 EST by Miroslav Suchý
Modified: 2015-05-20 03:20 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-03 11:35:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Miroslav Suchý 2009-01-23 07:47:06 EST
Description of problem:
If you set up probe and it fail. You will get notification message like this one:

>This is RHN Monitoring Satellite notification 0118z8sv.
>
>Time:      Fri Jan 23, 11:08:52 CET
>State:     UNKNOWN
>Host:      taw-test01-rlx-3-16.rhndev (10.10.76.187)
>Check:     Linux: Interface Traffic
>Message:   The RHN Monitoring Daemon (RHNMD) is not responding: ssh: connect to host 10.10.76.187 port 4545: No route to host. Please make sure the daemon is running and the host is accessible from the monitoring scout. Command was: /usr/bin/ssh -l nocpulse -p 4545 -i /home/nocpulse/.ssh/nocpulse-identity -o StrictHostKeyChecking=no -o BatchMode=yes 10.10.76.187 /bin/sh -s
>
>Run from:  RHN Monitoring Scout

And it will come from email: Monitoring Satellite Notification <rogerthat01@redhat.com>

This is setup as default in table rhn_config_parameter:
/schema/spacewalk/rhnsat/tables/rhn_config_parameter_data.sql:insert into rhn_config_parameter(group_name,name,value,security_type,last_update_user,last_update_date) values ( 'notification', 'frombase', 'rogerthat', 'INTERNAL', 'system',sysdate);

If you set up aliases you should be able to ACK the notification (see perldoc /usr/bin/ack_enqueuer.pl).

The problem it that the default email is red hat internal email, and it is live. And you actually get some answer.

This email should be set to some dummy value or not expanded to @redhat.com

Other problem is that due BZ 457011 you can not change the default value.

Version-Release number of selected component (if applicable):
0.4

How reproducible:
deterministic

Steps to Reproduce:
1. set up probe which will fail
2. wait for notification
3. reply to that email with "ME TOO id-of-that-prob in body" of that email.
4. Wait for answer.
  
Actual results:
You get answer from one of Red Hat machine.

Expected results:
You will get message that such alias do not exist.
Or if set up the alias you will get response from your Spacewalk.
Comment 2 Miroslav Suchý 2009-07-03 11:35:29 EDT
It happend to be problem of RH internal network. We rewrite all non-root account from foo@bar.redhat.com to foo@redhat.com
IT is hesitant to change this.
Comment 3 Miroslav Suchý 2009-09-10 08:00:43 EDT
Spacewalk 0.6 released.

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