cobbler-devel November 2011

cobbler-devel@lists.fedorahosted.org

12 participants
26 discussions

Re: [PATCH] support for gPXE and esxi5
by James Cammarata 30 Nov '11

30 Nov '11

On Wed, Nov 30, 2011 at 3:47 PM, John Paget Bourke <john.bourke(a)mobileinternet.com> wrote: > Folks, > > I have four servers with 16Gb RAM for which I had a manual PXE install environment in parallel with cobbler to handle the VMs. They used PXE to install > > I have been trying these patches. After a bunch of configuration ESXi starts to install. Then I get an error > > "fatal error: 10 (out of resources)" > > Does gPXE limit memory in any way ? My only change was to switch from PXE to gPXE. > > Thanks > > John Weird, there is a single google result for that error message: http://communities.vmware.com/thread/329291 I've gpxe'd on a VM with only 1GB, so I'm not sure what you're running into. Maybe a network card issue? Does it fail when loading the s.v00 file like in that forum post?

1 0

Random thoughts on things I'd like to tweak (architecturally, internals, not feature wise)
by Michael DeHaan 30 Nov '11

30 Nov '11

FWIW, random thoughts on things I'd like to pound on: ** cobblerd ** Making it a little easier to debug/work on. For testing, I think we should be able to turn cobblerd off and use the XMLRPC library directly without a socket connection, for testing and also local usage (with cobblerd stopped, probably). This could help out things pretty quickly. So the same API syntax we could use in the tests without spawning up the daemon, and that could work exceptionally nicely. cobblerd has to exist because of background jobs and our persistance layer, which I do not wish to rewrite everything to be databasey -- as much as I'd like to, it's way too much work, and really not a field problem. In many cases, it's actually useful, and it's one of a few things that makes working on Cobbler not feel like working on a webapp, and that's not a feeling I'd want to encourage anyway :) Maybe if I set a environment variable like COBBLERTEST=1 and then run cobbler commands or the test suite, it could work that way (locally) and give local exceptions, etc. This would be totally unsuitable for production use, but could be quite useful for us. ** more testing coverage ** I've gotten alot better at testing... cobbler has lots of side effects and the need to provision to fully test (in some cases) and deal with a lot of ISOs and a lot of storage means things are difficult. More abstraction layers probably need to exist... I don't know, but I'd like to establish a decent test framework that requires less manual testing. The existing test directory is not enough. I think for most things we can require tests for commits and can mock out parts of the app that are side effecty, and also configure it in such a way where we could have a "install root" where the tests build out their filesystem operations in "/tmp", etc. Just having that concept of a configurable FS root could be huge. Not sure what to do about auto-testing import, but there's quite a bit that we can test the heck out of (PXE trees, maybe even minimal yum repos, etc). ** cross distro support ** For my own personal reasons, pretty much for mobile development setups, I'd like to see how much of the server plays nice on a mac, and if we can make it to play *nicer*. ** templates ** I kind of hate Cheetah and would like to provide other simpler options. Ideally have something like the bash shebang to specify a template type. This seems actually pretty safe to do, but it would be nice to port all of things away from Cheetah as well. Should not be difficult. **object system ** Over the years I've had lots of random ideas on cleaning up the item_* system to reduce boilerplate, there's probably more to do here. Not a major priority, requires the test infrastructure first. ** development environment ** "make webtest" is pretty annoying, get cobbler tools to run better out of local checkout with PYTHONPATH. Might be almost free. See also the idea of having a way to configure cobbler's filesystem root. Maybe this only works in local XMLRPC mode as well. ** python versions ** require python2.4 as a minimum in cobbler & koan both, older OS support *gone*, they've had long enough, and it's nice to be able to have decent language capabilities --Michael

3 8

Revised Patch Process
by Michael DeHaan 27 Nov '11

27 Nov '11

See here: https://github.com/cobbler/cobbler/wiki/Patch-process (It could probably use some updating to include a little better guidance for people newer to github, contributions welcome.) Basics -- everyone should get a github.com account, fork the project, and create a new branch for each feature, and use pull requests to ask that their code get merged back in. An upside to this is that it makes it possible to watch features better as everyone works on them. Also, having a lot of forks of cobbler on github is hopefully good for spreading interest, since github is quasi-social. It also allows folks to collaborate together on a large feature before merging it into master -- we might even have officially hosted integration branches should we take on some really big things, who knows. Emailing this list with the pull request + an explanation is still encouraged and is something everyone should do, that way others can see what's going on and talk about it. Though we may ask a few questions on the pull request itself in github before something gets committed as well. Explaining how something has been tested in the pull request is a very good idea too. Also "following" the cobbler project on github probably can't hurt either. --Michael

2 2

[PATCH] support for gPXE and esxi5
by James Cammarata 27 Nov '11

27 Nov '11

Two patches, pushed to my github account: https://github.com/jimi1283/cobbler/commits/esxi-improvements The ESXI5 patch requires the gpxe patch, since the only sane way to add the support for it to cobbler was via the gpxe process documented in the VMware build guide. This allows all of the files to be served via httpd, otherwise you have to copy the entire ISO contents to a TFTP directory (which required some ugly hacking in cobbler). The one caveat about the gpxe process is that you must manually copy the undionly.kpxe file to your tftp directory. Newer distros package the etherboot files, otherwise you'll have to download the files from http://etherboot.org/wiki/download and build the file yourself (it's a fairly painless process). Another TODO is to make the same setup changes for DNSMASQ, right now this only supports ISC DHCPD. There is a new setting called enable_gpxe, which is used currently only when new items are created. There is also a new field for systems and profiles by the same name, which sets it on a per-object basis. This isn't being used for profiles yet, nor will it work on systems without an interface and MAC specified, but when enabled on a system with a MAC it will create an entry in dhcpd.conf that is configured to chain load the undionly.kpxe file. I plan on adding support for generic profiles and systems without a MAC, but it might be a some-what convoluted process and I'm trying to work out the best way to do it (currently it'd involve chain loading gpxe, and then detecting that you don't want to use gpxe and chain loading back into the old pxelinux.0 file). I plan on merging these into master in the near future unless people have major issues during testing. Enjoy!

1 0

buildiso USB ?
by Dan White 22 Nov '11

22 Nov '11

Did anyone ever come up with a reliable recipe for making a bootable USB-stick from a generated.iso ? If so, I could use 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)

2 2

Deleting small legacy things no one uses
by Michael DeHaan 21 Nov '11

21 Nov '11

This should not be too controversial and no, I'm not talking about any Python features. Looking through the codebase there are various things I'd like to either clean up, or delete, to reduce confusion for people working on the app. Before you say, whoa, delete, we still have history in git, and many of these things are pretty old. This is basically about keeping the top level directories organized enough and making sure nothing gets subject to bitrot, so people don't waste time with things that don't work. I kind of view Cobbler as "largely complete", i.e. not radically evolving, and this is mostly about keeping the repo in shape. ** Candidates For Removal ** * contrib/cloner -- I wrote this and have no idea what it does anymore, I can't answer any questions about it * cobbler4j -- this should be it's own repo as we won't be keeping Java code working, plus, plus no updates in a year and a half. 100% Fine if it lives elsewhere (like the spacewalk repo). * contrib/ruby bindings -- Like cobbler4j, lacks contributors, examples, testing, and recent commits. * build_backup -- not needed anymore, I'm pretty sure * shenson's cobbler_sync_master -- replicate should have replaced it completely * diagrams -- I don't actually run dia anymore and graphics are hard to keep up2date, more to text content in the Wiki * obsolete/* -- again, this is what version control is for * pres -- it's better to maintain content on the Wiki, where it might actually be kept up to date :) * rel-eng -- not saying it should go away as it's probably involved in pushing, but needs a README or something explaining how to use it. * fedora_epel_push -- not updated since F-12 various scripts in tests (not apitests) that aren't useful anymore. Would really like to see apitests grow to have greater coverage, but these are not those things. --Michael

3 2

[PATCH] Don't blow up on broken links under /var/www/cobbler/links
by Jeff Schroeder 18 Nov '11

18 Nov '11

Fedora's livecd-tools has this nifty "livecd-to-pxeboot" script for turning a bootable iso into a pxebootable image by putting the iso inside of the initrd. After playing with this for a bit and creating a small pxebootable distribution (using cobbler to manage it naturally), I ran into this bug. Since this is a stateless pxebootable distribution, there isn't a kickstart tree. When replicating from 1 cobbler instance to another, it was blowing up. The traceback was relatively simple and the bug existed in master as well as 2.0.11, so I wrote patches for both. -- Jeff Schroeder Don't drink and derive, alcohol and analysis don't mix. http://www.digitalprognosis.com

2 3

Moving the primary git repository and tagging of 2.2.2
by Scott Henson 16 Nov '11

16 Nov '11

I'd like to announce that the primary cobbler git repository will be moving from fedorahosted to GitHub. It will now be available at https://github.com/cobbler/cobbler. I'd like to thank the Fedora Project for the support over the years and we will continue to make use of the mailing lists and other bits of the Fedora Project infrastructure, but it seems like GitHub is better able to provide for our git based workflow. We will be making use of GitHub issues to track issues in cobbler from here on out. We will attempt to move over the current set of issues. Also, we are going to make use of the GitHub pages feature to host our documentation moving forward. If anyone has any questions or comments, feel free to respond to this email, or if you would like to speak in private, I welcome emails directly to me. Also, I've tagged 2.2.2. I'm still fighting with fedpkg on F16 to get a proper release out, but anyone should be able to retrieve the tag from git. I hope to have fedpkg working by this evening EST and a proper release out then. Also, I'm going to steal someone else's thunder and say that Michael DeHaan is returning to the project (anyone looking closely at the GitHub project is likely to notice this). Another note is my new email address (well not new, this is my personal address). I've accepted a position at Facebook and will be contributing to cobbler under my own name from here forward. Thanks. Scott Henson

3 3

[PATCH] only use a slave interface if it has a MAC address defined
by Parsons, Aron 14 Nov '11

14 Nov '11

This patch alters the pre_install_network_config snippet to only use slave interfaces that have a MAC address defined. Otherwise, if it picks a slave interface without a MAC, /tmp/pre_install_network_config is not generated because the grep statement for the MAC is empty. This then causes Anaconda to error out because the included file is missing. /aron

1 0

problems with cobbler-current
by Jörgen Maas 12 Nov '11

12 Nov '11

Hi, I tried to install cobbler-master (todays sources) on a fresh CentOS6 system and i get: Starting cobbler daemon: Traceback (most recent call last): File "/usr/bin/cobblerd", line 76, in main api = cobbler_api.BootAPI(is_cobblerd=True) File "/usr/lib/python2.6/site-packages/cobbler/api.py", line 127, in __init__ module_loader.load_modules() File "/usr/lib/python2.6/site-packages/cobbler/module_loader.py", line 62, in load_modules blip = __import__("modules.%s" % ( modname), globals(), locals(), [modname]) File "/usr/lib/python2.6/site-packages/cobbler/modules/authn_pam.py", line 53, in <module> from ctypes import CDLL, POINTER, Structure, CFUNCTYPE, cast, pointer, sizeof File "/usr/lib64/python2.6/ctypes/__init__.py", line 546, in <module> CFUNCTYPE(c_int)(lambda: None) MemoryError I did not configure authn_pam but wanted to use authn_testing. Any ideas? -- Grtz, Jörgen Maas

2 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

cobbler-devel November 2011