Bug #3117
closed
Calling "GET /unattended/built" fails
Description
We recently upgraded from Foreman 1.1 to 1.2, and hit a regression in the "GET unattended/built" page. Here's the part of the Kickstart that is failing:
# Inform the build system that we are done. echo "Informing Foreman that we are built" wget -q -O /dev/null --no-check-certificate http://192.168.1.2:3000/unattended/built
Here's what shows up in the logs on the Foreman server:
Started GET "/unattended/built" for 192.168.1.14 at 2013-09-13 10:00:48 -0400 Processing by UnattendedController#built as */* Found -certificate name redacted- Filter chain halted as :allowed_to_install? rendered or redirected Completed 405 Method Not Allowed in 9ms (ActiveRecord: 1.4ms)
This failure causes Foreman to not recognize that the build process is complete, so the host gets stuck in an infinite rebuild loop. As a workaround, you can hit the 'Cancel build' button manually via the web interface.
Updated by Mark Heily over 10 years ago
We are using the Foreman RPMs from the official repository. The installed version is foreman-1.2.2-1.el6
Updated by Dominic Cleal over 10 years ago
You should only get this response if the host is not in build mode. Can you check that this is the case before building?
If the host is in an infinite build cycle, look for the very first request to /unattended/built, as perhaps there was a failure when it first tried to revert build mode and the log entry above is just a consequence of that.
Updated by Zachary Bedell over 10 years ago
I'm encountering the same problem with a fresh install of 1.3-final setup this morning. It looks like /unattended/built is called twice during the preseed run, and the second call fails as the host is indeed no longer in build mode. I'm trying to install Ubuntu 13.04 on x86_64 if that makes any difference.
As far as I can tell, there are no errors during the initial 'built' call. I don't understand the architecture enough to know why it's trying to call it a second time. I've got output from tailing most of the logs in /var/log (tail -F apache2/* dmesg foreman/* foreman-proxy/proxy.log kern.log mail.* puppet/masterhttp.log syslog) here:
https://gist.github.com/anonymous/6992711
I'm tempted to add a "|| true" on the end of the wget call in Preseed Default Finish, but that seems like it might be asking for trouble down the line...
Updated by Greg Sutcliffe over 10 years ago
Zachary, could you gist the preseed and finish templates as rendered for that host? I'd like to check what it thinks it's running :)
Updated by Dominic Cleal over 10 years ago
- Status changed from New to Feedback
- Priority changed from High to Normal
Updated by Zachary Bedell over 10 years ago
Here's the preseed:
https://gist.github.com/anonymous/6996427
And the finish:
https://gist.github.com/anonymous/6996455
I retrieved these by setting the host back to build mode in the Foreman interface, then wget'ing them from the recovery shell on the host itself.
I can also see finish.sh in /target/tmp, so retrieval of that worked. Also the changes it attempts to make to puppet.conf are visible indicating it's run.
Updated by Greg Sutcliffe over 10 years ago
They look entirely normal to me - I can't think of any reason why that would hit /unattended/built twice. I also can't reproduce it, I did Wheezy build yesterday with the standard templates (which I think is what you're using there - certainly very similar :P) and it completed fine with a single call.
Are there any proxies or other network layers between Foreman and the host? I'm guessing here because I'm out of ideas...
Updated by Mark Heily over 10 years ago
After upgrading to Foreman 1.3, I can no longer reproduce this bug.
Updated by Benjamin Papillon about 10 years ago
- Status changed from Feedback to Closed
thanks for the update.
I'm closing this bug as the upgrade to 1.3 did solve your issue.
Regards