Foreman

This doesn't make a lot of sense to me, as this is generated automatically by rails, and there is no difference between spoof or normal requests for unattended files.

in my normal testing it didn't show up, can you provide some more information about your setup?

Thanks

I noticed that when the server was finishing kickstart, there was no output in the foreman saying the server was built. But when the server came up I was able to manually execute the wget command and see the "is built!" comment in the foreman output. So I decided to echo out the foreman_url in the kickstart script and comment out reboot. I also took out the -q option for the wget, and build again.

This is when I noticed that wget was getting a 404, and that foreman_url was outputting http://foreman/unattended... instead of http://foreman:3000/unattended

I'm running Ruby 1.8.5, rack (1.0.0), rails (2.3.4)

Let me know if you want me to do any other testing.

I cant think of a reason why this would happen, additionally, if it happens, its a pure rails bug :(

I've searched the rails bug-list, and it I couldn't find any information about it.

If you are planning to have the report and facts importer running over http, i would strongly recommend against webrick anyway. (depends on your load).

I'm assuming its not a one time problem? and you are able to reproduce it...

btw: did you had to make any modifications to the kickstart template?

Yep i'm planning to run under passenger, I just like to run webbrick for debugging.

Yep reproducible every time. I changed the kickstart template to cat in our own repo, remove the updating from EL repo, and changed the foremal_url to a hardcoded with port 3000. I'll change it back to foreman_url when running under passenger.

Hi,

I'm encountering same issue .....

Moty Lavi wrote:

Hi,

I'm encountering same issue .....

with webrick?

this looks like a rails bug, would you mind repeating the test with passenger?

I have puppet running through passenger , foreman is running through mongrel

Moty Lavi wrote:

I have puppet running through passenger , foreman is running through mongrel

could you try using passenger and let me know if the problem still exists?

I would use passenger to all of my ruby based applications

I've tried it here locally, and I get the correct URL...

not really sure of how to debug this..

Ohad Levy wrote:

I've tried it here locally, and I get the correct URL...

not really sure of how to debug this..

Ohad have you only tested under passenger, can you test under webrick?

Matt Moran wrote:

Ohad Levy wrote:

I've tried it here locally, and I get the correct URL...

not really sure of how to debug this..

Ohad have you only tested under passenger, can you test under webrick?

I did test with webrick, I've installed the latest version and did a wget http://foreman:3000/unattended/kickstart

it provided the URL with port 3000.

I find it very strange that both of you see this error while I cant reproduce it....

I'll test again today.

I ran into this myself, and found the problem by examining tcpdumps. When wget retrieves a URL, it includes the port in the host HTTP header, like so:

GET /unattended/kickstart HTTP/1.0
Host: testpuppet.wpi.edu:8141

When anaconda retrieves the same URL, however, it strips the port off:

GET /unattended/kickstart HTTP/1.0

Host: testpuppet.wpi.edu

The request.port method seems to returns whatever was in the headers, so I don't know of any simple workaround, but I'll post it if I find one.

I just finished an unattended install and looked at my anaconda script (kickstart file) in /root and noticed the wget url looks perfectly fine. The port number (3001 in my case) was appended. However, the build script somehow never phoned homed to finish the build.

I've also hit this bug, and its strange to say the least.

It seems Anaconda is stripping the port value out of this string prior to passing it to wget (or other HTTP client, i've tried a few).

As a workaround, I dont use foreman_url in my kickstart script for this one component, and explicitly define the host,port & url and it seems to work fine.

1. Foreman / Anaconda Bug : http://theforeman.org/issues/27 - Don't use foreman_url here for now.
   /usr/bin/wget -q -O /dev/null http://puppetmaster:3000/unattended/built

Diagnosing further, I looked at the kickstart file presented via spoof and via wgetting it from the client and they are right, the values provided to the client during kickstart is correct, namely foreman_url , however, if I log these values from %post i see the following:

From my provisioning template:

1. Lets print some debugging information also:
   FOREMANSTRING="<%= foreman_url %>"
   echo "The foreman string is: ${FOREMANSTRING}"

From my logfile during kickstart:
+ FOREMANSTRING=http://puppetmaster/unattended/built
+ echo 'The foreman string is: http://puppetmaster/unattended/built'

My environment is:
OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga)
Foreman: 0.4.2 on RHEL5 + Ruby Enterprise 1.8.7 + Passenger

• LOCAL GEMS ***

abstract (1.0.0)
actionmailer (3.1.1, 3.0.10)
actionpack (3.1.1, 3.0.10)
activemodel (3.1.1, 3.0.10)
activerecord (3.0.10)
activeresource (3.1.1, 3.0.10)
activesupport (3.1.1, 3.0.10)
arel (2.2.1, 2.0.10)
builder (3.0.0, 2.1.2)
bundler (1.0.21)
coderay (0.9.8)
daemon_controller (0.2.6)
erubis (2.7.0, 2.6.6)
fastthread (1.0.7)
hike (1.2.1)
i18n (0.6.0, 0.5.0)
json (1.6.1)
mail (2.3.0, 2.2.19)
method_source (0.6.7)
mime-types (1.17.2)
multi_json (1.0.3)
mysql (2.8.1)
net-ldap (0.2.2)
net-ping (1.5.2)
passenger (3.0.9)
polyglot (0.3.3)
pry (0.9.7.4)
pry-doc (0.3.0)
rack (1.3.5, 1.2.4)
rack-cache (1.1)
rack-mount (0.8.3, 0.6.14)
rack-protection (1.1.4)
rack-ssl (1.3.2)
rack-test (0.6.1, 0.5.7)
rails (3.0.10)
railties (3.1.1, 3.0.10)
rake (0.9.2.2)
rdoc (3.11)
rest-client (1.6.7)
ruby-augeas (0.4.1)
ruby-ldap (0.9.11)
ruby-shadow (2.1.2)
ruby_parser (2.3.1)
sexp_processor (3.0.10)
sinatra (1.3.1)
slop (2.1.0)
sprockets (2.0.3)
thor (0.14.6)
tilt (1.3.3)
treetop (1.4.10)
tzinfo (0.3.31)
yard (0.7.4)

I'm happy to work with anyone who knows Anaconda/Python well enough to dig a little deeper and see if we can ditch this long standing issue, just get in touch.

K