Wrong IP being update on system

Support
1

I don't know when it started, but a lot of my systems have the wrong
IP associated with them all of a sudden.

Checking the facts on the system, it should be OK …

So in one instance system A has IP 192.168.1.124 but reporting
192.168.1.170

The system actually does have 192.168.1.124 as its IP, and the fact
reports so as well:

system A:~ # facter -p | grep -i ip
ipaddress => 192.168.1.124
ipaddress_eth0 => 192.168.1.124

But in WebUI on host page its reporting under properties the IP of
192.168.1.170

This isn't just visual. I just stumbled on this when trying to
rebuild a system, and reported that IP was already in use. I was able
to fix the IP and build, but then on another system when I tried to
manually fix it said the IP it should be for this system was in use
also!

This is affecting both managed and unmanaged systems.

Is there a way to check when this was updated to this new/bad IP so I
can try and correlate to perhaps some change that could have been
made?

Thanks,
Jake

2

So we recently implemented async_storeconfigs. Seems that the agent
system is having its IP updated to the IP of the puppetmaster filing a
report for it when this is turned on. I guess this is a bug with
puppet or how I have things configured.

Thanks!
Jake

··· On Jan 24, 1:44 pm, jmccann wrote: > I don't know when it started, but a lot of my systems have the wrong > IP associated with them all of a sudden. > > Checking the facts on the system, it should be OK ... > > So in one instance system A has IP 192.168.1.124 but reporting > 192.168.1.170 > > The system actually does have 192.168.1.124 as its IP, and the fact > reports so as well: > > system A:~ # facter -p | grep -i ip > ipaddress => 192.168.1.124 > ipaddress_eth0 => 192.168.1.124 > > But in WebUI on host page its reporting under properties the IP of > 192.168.1.170 > > This isn't just visual. I just stumbled on this when trying to > rebuild a system, and reported that IP was already in use. I was able > to fix the IP and build, but then on another system when I tried to > manually fix it said the IP it should be for this system was in use > also! > > This is affecting both managed and unmanaged systems. > > Is there a way to check when this was updated to this new/bad IP so I > can try and correlate to perhaps some change that could have been > made? > > Thanks, > Jake
3

OK, so this may be a foreman issue after … not sure … let me know.

When I look at fact values, they all have the correct value for the
fact. (host = "system A" and fact ~ ip)

system A ipaddress_eth0 192.168.1.124 about 6 hours ago
system A ipaddress 192.168.1.124 about 6 hours ago

When I try to search system A for a fact with value 170 in it I get
nothing … (host = "system A" and value ~ 170)

So it seems like using async_storeconfigs is causing some value to get
changed to the puppetmaster IP, and that is causing foreman to report
the puppetmaster IP as the system IP instead of the system's IP.

Thanks,
Jake

··· On Jan 24, 1:53 pm, jmccann wrote: > So we recently implemented async_storeconfigs. Seems that the agent > system is having its IP updated to the IP of the puppetmaster filing a > report for it when this is turned on. I guess this is a bug with > puppet or how I have things configured. > > Thanks! > Jake > > On Jan 24, 1:44 pm, jmccann wrote: > > > > > > > > > I don't know when it started, but a lot of my systems have the wrong > > IP associated with them all of a sudden. > > > Checking the facts on the system, it should be OK ... > > > So in one instance system A has IP 192.168.1.124 but reporting > > 192.168.1.170 > > > The system actually does have 192.168.1.124 as its IP, and the fact > > reports so as well: > > > system A:~ # facter -p | grep -i ip > > ipaddress => 192.168.1.124 > > ipaddress_eth0 => 192.168.1.124 > > > But in WebUI on host page its reporting under properties the IP of > > 192.168.1.170 > > > This isn't just visual. I just stumbled on this when trying to > > rebuild a system, and reported that IP was already in use. I was able > > to fix the IP and build, but then on another system when I tried to > > manually fix it said the IP it should be for this system was in use > > also! > > > This is affecting both managed and unmanaged systems. > > > Is there a way to check when this was updated to this new/bad IP so I > > can try and correlate to perhaps some change that could have been > > made? > > > Thanks, > > Jake
4

hmm… that is very odd, and sounds like puppet is updating the ip
address in the hosts table based on the puppetmaster ip.
this is all done behind the scenes, so foreman is not aware of this
change at all.

Ohad

··· On Tue, Jan 24, 2012 at 10:04 PM, jmccann wrote: > OK, so this may be a foreman issue after ... not sure ... let me know. > > When I look at fact values, they all have the correct value for the > fact. (host = "system A" and fact ~ ip) > > system A ipaddress_eth0 192.168.1.124 about 6 hours ago > system A ipaddress 192.168.1.124 about 6 hours ago > > When I try to search system A for a fact with value 170 in it I get > nothing ... (host = "system A" and value ~ 170) > > So it seems like using async_storeconfigs is causing some value to get > changed to the puppetmaster IP, and that is causing foreman to report > the puppetmaster IP as the system IP instead of the system's IP. > > Thanks, > Jake > > On Jan 24, 1:53 pm, jmccann wrote: >> So we recently implemented async_storeconfigs. Seems that the agent >> system is having its IP updated to the IP of the puppetmaster filing a >> report for it when this is turned on. I guess this is a bug with >> puppet or how I have things configured. >> >> Thanks! >> Jake >> >> On Jan 24, 1:44 pm, jmccann wrote: >> >> >> >> >> >> >> >> > I don't know when it started, but a lot of my systems have the wrong >> > IP associated with them all of a sudden. >> >> > Checking the facts on the system, it should be OK ... >> >> > So in one instance system A has IP 192.168.1.124 but reporting >> > 192.168.1.170 >> >> > The system actually does have 192.168.1.124 as its IP, and the fact >> > reports so as well: >> >> > system A:~ # facter -p | grep -i ip >> > ipaddress => 192.168.1.124 >> > ipaddress_eth0 => 192.168.1.124 >> >> > But in WebUI on host page its reporting under properties the IP of >> > 192.168.1.170 >> >> > This isn't just visual. I just stumbled on this when trying to >> > rebuild a system, and reported that IP was already in use. I was able >> > to fix the IP and build, but then on another system when I tried to >> > manually fix it said the IP it should be for this system was in use >> > also! >> >> > This is affecting both managed and unmanaged systems. >> >> > Is there a way to check when this was updated to this new/bad IP so I >> > can try and correlate to perhaps some change that could have been >> > made? >> >> > Thanks, >> > Jake >
5

Yea, its hosts.ip that is being updated to the wrong value. Since
foreman and puppet share the storeconfig DB I didn't know who was
setting it.

If that is managed by puppet, I will pursue this in their usergroup.

Thanks for the direction!
Jake

··· On Jan 24, 2:24 pm, Ohad Levy wrote: > On Tue, Jan 24, 2012 at 10:04 PM, jmccann wrote: > > OK, so this may be a foreman issue after ... not sure ... let me know. > > > When I look at fact values, they all have the correct value for the > > fact. (host = "system A" and fact ~ ip) > > > system A ipaddress_eth0 192.168.1.124 about 6 hours ago > > system A ipaddress 192.168.1.124 about 6 hours ago > > > When I try to search system A for a fact with value 170 in it I get > > nothing ... (host = "system A" and value ~ 170) > > > So it seems like using async_storeconfigs is causing some value to get > > changed to the puppetmaster IP, and that is causing foreman to report > > the puppetmaster IP as the system IP instead of the system's IP. > > > Thanks, > > Jake > > > On Jan 24, 1:53 pm, jmccann wrote: > >> So we recently implemented async_storeconfigs. Seems that the agent > >> system is having its IP updated to the IP of the puppetmaster filing a > >> report for it when this is turned on. I guess this is a bug with > >> puppet or how I have things configured. > > >> Thanks! > >> Jake > > >> On Jan 24, 1:44 pm, jmccann wrote: > > >> > I don't know when it started, but a lot of my systems have the wrong > >> > IP associated with them all of a sudden. > > >> > Checking the facts on the system, it should be OK ... > > >> > So in one instance system A has IP 192.168.1.124 but reporting > >> > 192.168.1.170 > > >> > The system actually does have 192.168.1.124 as its IP, and the fact > >> > reports so as well: > > >> > system A:~ # facter -p | grep -i ip > >> > ipaddress => 192.168.1.124 > >> > ipaddress_eth0 => 192.168.1.124 > > >> > But in WebUI on host page its reporting under properties the IP of > >> > 192.168.1.170 > > >> > This isn't just visual. I just stumbled on this when trying to > >> > rebuild a system, and reported that IP was already in use. I was able > >> > to fix the IP and build, but then on another system when I tried to > >> > manually fix it said the IP it should be for this system was in use > >> > also! > > >> > This is affecting both managed and unmanaged systems. > > >> > Is there a way to check when this was updated to this new/bad IP so I > >> > can try and correlate to perhaps some change that could have been > >> > made? > > >> > Thanks, > >> > Jake > > hmm.. that is very odd, and sounds like puppet is updating the ip > address in the hosts table based on the puppetmaster ip. > this is all done behind the scenes, so foreman is not aware of this > change at all. > > Ohad
6

> Yea, its hosts.ip that is being updated to the wrong value. Since
> foreman and puppet share the storeconfig DB I didn't know who was
> setting it.
>
> If that is managed by puppet, I will pursue this in their usergroup.

looking at the puppet/lib/puppet/rails/host.rb file, this seems like
where it sets the ip address / environment is simply using the wrong
object, maybe at indirector/active_record.rb

Ohad

··· On Tue, Jan 24, 2012 at 10:29 PM, jmccann wrote: > > Thanks for the direction! > Jake > > On Jan 24, 2:24 pm, Ohad Levy wrote: >> On Tue, Jan 24, 2012 at 10:04 PM, jmccann wrote: >> > OK, so this may be a foreman issue after ... not sure ... let me know. >> >> > When I look at fact values, they all have the correct value for the >> > fact. (host = "system A" and fact ~ ip) >> >> > system A ipaddress_eth0 192.168.1.124 about 6 hours ago >> > system A ipaddress 192.168.1.124 about 6 hours ago >> >> > When I try to search system A for a fact with value 170 in it I get >> > nothing ... (host = "system A" and value ~ 170) >> >> > So it seems like using async_storeconfigs is causing some value to get >> > changed to the puppetmaster IP, and that is causing foreman to report >> > the puppetmaster IP as the system IP instead of the system's IP. >> >> > Thanks, >> > Jake >> >> > On Jan 24, 1:53 pm, jmccann wrote: >> >> So we recently implemented async_storeconfigs. Seems that the agent >> >> system is having its IP updated to the IP of the puppetmaster filing a >> >> report for it when this is turned on. I guess this is a bug with >> >> puppet or how I have things configured. >> >> >> Thanks! >> >> Jake >> >> >> On Jan 24, 1:44 pm, jmccann wrote: >> >> >> > I don't know when it started, but a lot of my systems have the wrong >> >> > IP associated with them all of a sudden. >> >> >> > Checking the facts on the system, it should be OK ... >> >> >> > So in one instance system A has IP 192.168.1.124 but reporting >> >> > 192.168.1.170 >> >> >> > The system actually does have 192.168.1.124 as its IP, and the fact >> >> > reports so as well: >> >> >> > system A:~ # facter -p | grep -i ip >> >> > ipaddress => 192.168.1.124 >> >> > ipaddress_eth0 => 192.168.1.124 >> >> >> > But in WebUI on host page its reporting under properties the IP of >> >> > 192.168.1.170 >> >> >> > This isn't just visual. I just stumbled on this when trying to >> >> > rebuild a system, and reported that IP was already in use. I was able >> >> > to fix the IP and build, but then on another system when I tried to >> >> > manually fix it said the IP it should be for this system was in use >> >> > also! >> >> >> > This is affecting both managed and unmanaged systems. >> >> >> > Is there a way to check when this was updated to this new/bad IP so I >> >> > can try and correlate to perhaps some change that could have been >> >> > made? >> >> >> > Thanks, >> >> > Jake >> >> hmm.. that is very odd, and sounds like puppet is updating the ip >> address in the hosts table based on the puppetmaster ip. >> this is all done behind the scenes, so foreman is not aware of this >> change at all. >> >> Ohad > > -- > You received this message because you are subscribed to the Google Groups "Foreman users" group. > To post to this group, send email to foreman-users@googlegroups.com. > To unsubscribe from this group, send email to foreman-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/foreman-users?hl=en. >
7

So I've created thread http://groups.google.com/group/puppet-users/browse_thread/thread/ad55d817feef4614
on the puppet users usergroup

I'm a ruby/rails newb. I've tried taking a look at the files you are
pointing to but it doesn't make much sense to me. Would be greatly
appreciated if you posted some comments on the thread I started over
there if you think they would be useful to tracking down this issue.

Thanks,
Jake

··· On Jan 24, 2:32 pm, Ohad Levy wrote: > On Tue, Jan 24, 2012 at 10:29 PM, jmccann wrote: > > Yea, its hosts.ip that is being updated to the wrong value. Since > > foreman and puppet share the storeconfig DB I didn't know who was > > setting it. > > > If that is managed by puppet, I will pursue this in their usergroup. > > looking at the puppet/lib/puppet/rails/host.rb file, this seems like > where it sets the ip address / environment is simply using the wrong > object, maybe at indirector/active_record.rb > > Ohad > > > > > > > > > > > Thanks for the direction! > > Jake > > > On Jan 24, 2:24 pm, Ohad Levy wrote: > >> On Tue, Jan 24, 2012 at 10:04 PM, jmccann wrote: > >> > OK, so this may be a foreman issue after ... not sure ... let me know. > > >> > When I look at fact values, they all have the correct value for the > >> > fact. (host = "system A" and fact ~ ip) > > >> > system A ipaddress_eth0 192.168.1.124 about 6 hours ago > >> > system A ipaddress 192.168.1.124 about 6 hours ago > > >> > When I try to search system A for a fact with value 170 in it I get > >> > nothing ... (host = "system A" and value ~ 170) > > >> > So it seems like using async_storeconfigs is causing some value to get > >> > changed to the puppetmaster IP, and that is causing foreman to report > >> > the puppetmaster IP as the system IP instead of the system's IP. > > >> > Thanks, > >> > Jake > > >> > On Jan 24, 1:53 pm, jmccann wrote: > >> >> So we recently implemented async_storeconfigs. Seems that the agent > >> >> system is having its IP updated to the IP of the puppetmaster filing a > >> >> report for it when this is turned on. I guess this is a bug with > >> >> puppet or how I have things configured. > > >> >> Thanks! > >> >> Jake > > >> >> On Jan 24, 1:44 pm, jmccann wrote: > > >> >> > I don't know when it started, but a lot of my systems have the wrong > >> >> > IP associated with them all of a sudden. > > >> >> > Checking the facts on the system, it should be OK ... > > >> >> > So in one instance system A has IP 192.168.1.124 but reporting > >> >> > 192.168.1.170 > > >> >> > The system actually does have 192.168.1.124 as its IP, and the fact > >> >> > reports so as well: > > >> >> > system A:~ # facter -p | grep -i ip > >> >> > ipaddress => 192.168.1.124 > >> >> > ipaddress_eth0 => 192.168.1.124 > > >> >> > But in WebUI on host page its reporting under properties the IP of > >> >> > 192.168.1.170 > > >> >> > This isn't just visual. I just stumbled on this when trying to > >> >> > rebuild a system, and reported that IP was already in use. I was able > >> >> > to fix the IP and build, but then on another system when I tried to > >> >> > manually fix it said the IP it should be for this system was in use > >> >> > also! > > >> >> > This is affecting both managed and unmanaged systems. > > >> >> > Is there a way to check when this was updated to this new/bad IP so I > >> >> > can try and correlate to perhaps some change that could have been > >> >> > made? > > >> >> > Thanks, > >> >> > Jake > > >> hmm.. that is very odd, and sounds like puppet is updating the ip > >> address in the hosts table based on the puppetmaster ip. > >> this is all done behind the scenes, so foreman is not aware of this > >> change at all. > > >> Ohad > > > -- > > You received this message because you are subscribed to the Google Groups "Foreman users" group. > > To post to this group, send email to foreman-users@googlegroups.com. > > To unsubscribe from this group, send email to foreman-users+unsubscribe@googlegroups.com. > > For more options, visit this group athttp://groups.google.com/group/foreman-users?hl=en.