Description of problem: In scout config push is icon, which show if push is need or not. But if machine with probe change IP adress you have to do scout config push (after machine execute rhn-profile-sync). Otherwise scout will still try to probe old IP. But the icon do not show that push is needed. Version-Release number of selected component (if applicable): sat540 How reproducible: always Steps to Reproduce: 1. register machine to spacewalk 2. create Ping probe, push scout config 3. probe is ok 4. change IP of machine, rhn-profile-sync 5. check "Push scout config" page Actual results: It shows icon Fully Updated Expected results: It should show icon Push Required
Mass-moving to space13.
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.
Aligning under space16.
Mirek, what is the proposed fix here? Do we add a trigger on the hardware/network info table to update probes for the given system (which should kick the gears of the scout config push icon)?
Yes, your proposed fix can work.
Which IP address is supposed to change after rhn-profile-sync? The "IP Address" in System > Details > Overview, as well as in Details > Hardware stay the same after IP address was changed on the client and the rhn-profile-sync run, even if the interface listing on the Details > Hardware page shows the new IP address. This is on Spacewalk 1.6 (nightly) and with RHEL 5.7 and 6.2 clients. Isn't the IP address used by the probes the one in the "IP Address" field? Shouldn't that field get changed, besides the change in the interfaces listing?
(In reply to comment #7) > Which IP address is supposed to change after rhn-profile-sync? The "IP Address" > in System > Details > Overview, as well as in Details > Hardware stay the same > after IP address was changed on the client and the rhn-profile-sync run, even > if the interface listing on the Details > Hardware page shows the new IP > address. > > This is on Spacewalk 1.6 (nightly) and with RHEL 5.7 and 6.2 clients. The same behaviour against Spacewalk 1.5, so it's not caused by the latest IPv6-related changed.
The problem is not on the server -- the problem is that changing the IP address of the client machine is *not* enough. The client code does netdict['hostname'] = gethostname() try: list_of_addrs = getaddrinfo(gethostname(), None) ipv4_addrs = filter(lambda x:x[0]==socket.AF_INET, list_of_addrs) # take first ipv4 addr netdict['ipaddr'] = ipv4_addrs[0][4][0] except: netdict['ipaddr'] = "127.0.0.1" so if the hostname on the client machine stayed the same, it will be resolved to the IP address, in spite of the fact that said IP address is no longer the IP address of the client.
Hmm, I would assume correct behavior. I.e. that reverse dns query will match. If users reverse dns does not match, then it's their problem. And if I try to recall #0 (it's one year ago) I think I have changed both ip and reverse dns. And in such case the IP address reported by client change.
Proposal from comment 5 implemented in Spacewalk master, e64df77fe313c6bf8e1b2b161fdf8cc35b22c7c3.
Spacewalk 1.6 has been released.