cobbler bootiso ontimeout option
by Simon Woolsgrove
Have a use case that maybe unique to us as were not unfortunately using
DHCP or all our vlans. We automate on demand VMware guests by using a
workflow engine to; create the guest images, cobbler system record, request
cobbler buildiso, attach iso and boot guest, detach iso. Our issue is
then that on the isolinux timeout the default boot is Local which is fine
for 99% of cases but not this as the guest build fails. Currently we have
another step to mangle the cd athough it occurs the better solution maybe
to add another option say ontimeout so that can be supplied via api/cli
(not sure it makes sense in the webui)?
I thought I remember this being discused on the list once but could not
find any reference. Is the above approach ok as happy to have a crack at it
unless someone has already figured, or is there a better way say selecting
iso template etc.. We can also do this as a site specific its just not so
freindly when updating cobbler.
Cheers,
Simon
12 years, 3 months
Re: cobbler bootiso ontimeout option
by Simon Woolsgrove
On Fri 30/12/11 12:27 PM , Jörgen Maas wrote:On Fri, Dec 30, 2011 at 1:10
PM, wrote:
>
>
> Have a use case that maybe unique to us as were not unfortunately using
DHCP
> or all our vlans. We automate on demand VMware guests by using a
workflow
> engine to; create the guest images, cobbler system record, request
cobbler
> buildiso, attach iso and boot guest, detach iso. Our issue is then
that on
> the isolinux timeout the default boot is Local which is fine for 99% of
> cases but not this as the guest build fails. Currently we have another
step
> to mangle the cd athough it occurs the better solution maybe to add
another
> option say ontimeout so that can be supplied via api/cli (not sure it
makes
> sense in the webui)?
>
Hi Simon, so you want to be able to control the value of the ONTIMEOUT.
So that you can select a system to install without any further
intervention?
--
Grtz,
Jörgen Maas
Hi Jörgen
Yep exactly, in my case there would only ever be one system record on the
CD, was thinking its should be fairly easily to setup with the
buildiso.template ONTIMEOUT $label or some such?
Cheers,
Simon
12 years, 3 months
running from Django "manage.py runserver" & also a Apache port conflict problem
by Michael DeHaan
Trying to get my from-source environment all happy again. Went fine with cobbler, not so fine with cobbler-webui.
CentOS 6.2:
make webtest
yum install python-netaddr python-cheetah PyYAML mod_wsgi python-simplejson Django mod_ssl
setenforce 0
/sbin/service iptables stop
After I log in to the web app, I get an internal server error, but see nothing in the Apache or cobbler logs.
Let's check Django manually, hoping to see the traceback that didn't get logged:
python manage.py runserver
login with testing/testing
404 looking for do_login … HMM… why?
So that doesn't work.
The URL django is actually looking for is "cobbler_web/do_login", per the bottom of the page, when running from there, and is not matching the actual URL. Has anyone been using the webUI from the Django embedded web server for debugging reasons? It would be really nice if we could get this to work.
It's also unfortunate that the error doesn't get logged at all, but httpd errors logs in Django land *should* be routed to the httpd error logs. This may require messing with the Django middleware or settings. I'll pound on this some more, but I'd expect "make webtest" to get a working webUI out of the box.
I should also add, I encountered some problems with restarting apache and it trying to claim 25151 as a port for (I think) mod_wsgi. Anybody ever encounter something like this? It seems
familiar.
--Michael
12 years, 3 months
Need everyone helping out with the bug queue
by Michael DeHaan
Hi folks,
So while I was in the process of making comments on Trac tickets about the github move, I noticed there were a large amount of tickets that have been left open for a rather large amount of time -- several hundred, many open for over a year. This is bad and will ultimately destroy any piece of software. Scott, James, and I can't manage this alone.
While I'm sure not all of these are active bugs, and some are more like ideas or support requests, I don't want to see the queue get in this state again. That's our record of what's broke or not broke -- so it needs to be small at all times. Here's the challenge and ultimatum to you:
(1) We will not release with a bug queue in that state again. Full stop.
(2) Our next release should be about releasing with as low of a bug count as possible.
(3) More people absolutely need to be committing and fixing bugs. This means everyone.
As this list is full of immensely talented sysadmins, I think we can all shoulder the load and make this pretty darn easy. The more work everyone does, the less work everyone does.
That makes sense! So here's your new years resolution, which is also the requirement for success of the project.
(1) new bug queue to bookmark -- http://github.com/cobbler/cobbler/issues -- it's small now, but expect it to grow as people move things over from Trac. Bookmark it.
(2) Learn Python if you don't know it, we'll help on #cobbler and cobbler-devel list as much as possible. If you know it, help others here learn it. There was a "Learn to Hack on
Cobbler Week" once. Let's make that every day and multiply the contributor pool. Like Tribbes. (Did I mention OSS contributions look great on your resume? They do).
Join the development list if you haven't already.
(3) Fix bugs and send in pull requests, and close bug tickets that are user error with explanations of what the users should be doing. Help keep the bug queue extra small and the master branch very high quality. If you're submitting a feature or a bug fix for something that affects you, also try to fix some bugs that don't affect you. If you are submitting a bug, see if you can also accompany that bug report with a fix.
If we all do this, we can release quicker, have a higher quality app, and have more time for amazing new features. For those starting and those that have already been helping alike, thank you very much!
And may everyone enjoy flying their Christmas Sharks.
12 years, 3 months
Debian follow-up -- still need info about development environment usage
by Michael DeHaan
Got some info from the Ubuntu team a few weeks ago.
Per-them, all packaging is done in the upstream Debian package, and didn't get much help beyond that.
In order to make this really easy to test on as a development platform, I think we need
(A) some better Wiki docs about how to do development on that platform, where to check out the packaging for people who are unfamiliar with Debian's workflows, etc
(B) things like the Makefile get patched for that OS to make it easy for someone to go from a git checkout to working on it as a development environment. make install
needs to work on Debian.
For folks that do have things working, I'm still curious about how you set up your development testing environment. Canonical is not really helping me
in this regard, seem to be busy. Truth to be told, I just want some good docs on how someone using Debian can work on the project for the Wiki.
If anyone would like to help, that would be great.
--Michael
12 years, 3 months
Feature Request / Minor Bug Grumble: Web Interface: Profile Edit Page
by Dan White
I would like the Repos list on the profile editing page to be wider or width-adjustable.
The names of most of my repos are wider than the window and I cannot see the whole name to properly select it.
“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)
12 years, 3 months
[PATCH] bug fix for new template stuff
by James Cammarata
Merged the new-template branch into release22 as well (I had only
merged it into master), and also applied this patch:
commit c0d19e0814ea56e7a2a1d932a4485eafb8153a0c
Author: James Cammarata <jimi(a)sngx.net>
Date: Tue Dec 6 19:15:18 2011 -0600
BUGFIX - adding default_template_type to settings.py, caused some
issues with templar when the setting was not specified in the
/etc/cobbler/settings
12 years, 3 months
Re: [cobbler] can't save networking options of a system in cobbler web interface. (#8)
by James Cammarata
On Fri, Dec 2, 2011 at 4:36 AM, harveyzh
<reply+i-2425913-a30f42d840f54cb26b206edd25ffbc4a6b62a94a-26403(a)reply.github.com>
wrote:
> After modifying and saving the networking options of a system in cobbler web interface, i found that the modification was lost.
>
> I am using the cobbler-2.3.1-1 and cobbler-web-2.3.1-1 on centos 6.0, which are built from the git master (the latest commit is 525122d267c3a0ec3a353d52458be9d1612b3388 ). But in cobbler-2.2.2-1, it works fine.
>
> How to reproduce
> -----
> 1. add a new interface
> 2. click the "Generate Random MAC" button
> 3. fill the IP Address
> 4. check the "static" option checked
> 5. fill the Subnet Mask and Virt Bridge
> 6. finanlly save
After lots of git bisects...
18eb1c06779b37d89dfb2962a08236dd1bab24a6 is the first bad commit
commit 18eb1c06779b37d89dfb2962a08236dd1bab24a6
Author: James Cammarata <jimi(a)sngx.net>
Date: Fri Nov 4 02:33:38 2011 -0500
Additional CSRF work. All URLs that modify state are now required
to be POSTs only.
:040000 040000 1398d8f5fe4818f34cdce702b073eb974f368065
47770201913af8bb2a0a97f03fecdc4f4449504e M web
So something about saving interfaces doesn't like CSRF apparently.
Which is odd, because saving any other attribute on the system works
just fine - it's just the interface stuff that doesn't save correctly.
12 years, 3 months