Re: [PATCH] support for gPXE and esxi5
by James Cammarata
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?
12 years, 4 months
Random thoughts on things I'd like to tweak (architecturally, internals, not feature wise)
by Michael DeHaan
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
12 years, 4 months
Revised Patch Process
by Michael DeHaan
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
12 years, 5 months
[PATCH] support for gPXE and esxi5
by James Cammarata
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!
12 years, 5 months
buildiso USB ?
by Dan White
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)
12 years, 5 months
Deleting small legacy things no one uses
by Michael DeHaan
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
12 years, 5 months
[PATCH] Don't blow up on broken links under /var/www/cobbler/links
by Jeff Schroeder
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
12 years, 5 months
Moving the primary git repository and tagging of 2.2.2
by Scott Henson
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
12 years, 5 months
[PATCH] only use a slave interface if it has a MAC address defined
by Parsons, Aron
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
12 years, 5 months
problems with cobbler-current
by Jörgen Maas
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
12 years, 5 months