[Spacewalk-list] Monitoring problem after 1.1 -> 1.2 update

[Benedetto Vassallo]

Def. Quota Miroslav Suchý <msuchy at redhat.com>:

> On 12/26/2010 05:59 PM, Benedetto Vassallo wrote:
>> Hello list,
>> I have a strange problem after upgrading my spacewalk server from 1.1 to
>> 1.2
>> In the monitoring page I see 2 spacewalk monitoring scouts, both having
>> the same ssh key.
>> One is "Fully Updated" (green triangle) and the other is "Failed" (red
>> triangle).
>>
>> The result is all my monitored systems are "Awaiting updates" (clock icon).
>>
>> I searched in the oracle database for invalid objects (views, packaged
>> or functions) but found nothing.
>>
>> How I can work around this?
>
> Hi,
> first - this should not happened, I will be interested if you can  
> reproduce it.
>
OK, I'll try to reproduce it on another spacewalk 1.1 installation and  
then upgrading it to 1.2.


> Fix has to be done directly in db.
> Look in tables RHN_SAT_CLUSTER and RHN_SAT_NODE. There should be one  
> record per scout, so you have there probably two records instead of  
> one.
I have 2 records in both tables.

in RHN_SAT_CLUSTER the only difference is the 1st record is associated  
to the "spaceadmin" user (the first user created after install), the  
2nd record is associated to "vassallo" (the user I use normally in a  
different organization).

SELECT RECID,TARGET_TYPE,CUSTOMER_ID,DESCRIPTION,LAST_UPDATE_USER,  
physical_location_id, vip, deployed FROM RHN_SAT_CLUSTER;

"RECID" "TARGET_TYPE"   "CUSTOMER_ID"   "DESCRIPTION"    
"LAST_UPDATE_USER"      "PHYSICAL_LOCATION_ID"  "VIP"   "DEPLOYED"
"1"     "cluster"       "1"     "Spacewalk Monitoring Scout"     
"spaceadmin"    "1"     "147.163.2.24"  "1"
"3"     "cluster"       "2"     "Spacewalk Monitoring Scout"     
"vassallo"      "1"     "147.163.2.24"  "1"

SELECT * FROM RHN_SAT_NODE;

"RECID" "SERVER_ID"     "TARGET_TYPE"   "LAST_UPDATE_USER"       
"LAST_UPDATE_DATE"      "MAC_ADDRESS"   "MAX_CONCURRENT_CHECKS"  
"SAT_CLUSTER_ID"        "IP"    "SCHED_LOG_LEVEL"        
"SPUT_LOG_LEVEL"        "DQ_LOG_LEVEL"  "SCOUT_SHARED_KEY"
"2"     ""      "node"  ""      ""      "not set"       "10"    "1"     
  "147.163.2.24"  "1"     "1"     "1"     "332709eb12bf"
"4"     ""      "node"  ""      ""      "not set"       "10"    "3"     
  "147.163.2.24"  "1"     "1"     "1"     "e854a34f7f77"



> Delete one of them and then make sure that probes are asociate with  
> correct scout (in webUI).
>

I deleted the one associated to "vassallo" becouse I see in my  
production server (1.1) there is only the one assciated to the  
"spaceadmin" user but it didn't work (red triangle after push).

Tomorrow I try to reproduce it.
The steps I did are:
1) Install spacewalk 1.1
2) Create the first user (spaceadmin)
3) Enable ldap authentication
4) Enable monitoring and monitoring scout
5) Create a new organization with a new user (vassallo) with satellite  
admin rights

====== from now all operations are done by 'vassallo' user. ======

6) register some systems
7) Create a probe suite with a Linux -> CPU Usage probe and add all  
systems to it
8) Update spacewalk to 1.2

I'll let you know.
Bye for now.
-- 
Benedetto Vassallo
Sistema Informativo di Ateneo
Settore Gestione Reti Hardware e Software
U.O. Sviluppo e manutenzione dei sistemi
Università degli studi di Palermo

Red Hat Certified Engineer Certificate Number: 804007793324656

Phone: +3909123860056
Fax: +390916529124

-------------------------------------------------------------------------
This message was sent using the University of Palermo web mail interface.