generic hostnames
by Christopher Johnston
Just going through a feature that I think has some value with cobbler, when
adding an interface to cobbler we may not want every interface to be added
to our dhcp configs. Not only does that create a huge dhcpd.conf with
uncessary entries, but it also adds interfaces that may be blank or missing
--dns-name (they get added as genericXnn). It would be useful to have an
option that says --dhcp (1|2) so only those interfaces are added to the DHCP
configuration. The default could always be "true" which is most likely good
for most environments. This would allow greater flexibility for the type
interfaces that we add. I know there is a --static option, but I dont
believe that works as advertised as even on the latest (1.6 version) of
cobbler I am still seeing entries get added called genericXnn.
-Chris
15 years, 1 month
Koan problem
by Alex Davies
Hi Everyone,
I'm just exploring koan and am struggling to get koan to work properly (is
there a dedicated koan mailing list?):
[root@gcisvxen011xb network-scripts]# koan --server=10.5.10.5 --virt
--profile="xen-guest" --virt-name="test" --virt-ram="4096" --virt-cpus=2
--virt-path="/dev/localxb/testvm" --no-gfx
Usage: koan [options]
koan: error: no such option: --virt-ram
My reading of the man page tells me that this *should work*, no? (if I
remove --virt-ram, I get the same error bout the others e.g. virt-name;
however if I just specify the profile it does work).
In Cobbler, I have the relevant profile setup but i'd like to do the
per-machine stuff through koan if possible.
Any help much appreciated.
Cheers,
Alex
15 years, 1 month
Cobbler 1.6.1 WebUI Search
by Simon Woolsgrove
I just started playing with search in the WebUI and noted that I get these errors. This is a update to cobbler-1.6.1 on RHEL 5 from a previous 1-4.2 (although that may have been a git based rpm). I have not had time to debug yet but thought I would post in case of user error ... or clues on where to go look. Browser is FF on FC9.
Simply submitting search without entering any field gives
Mod_python error: "PythonHandler index"
Traceback (most recent call last):
File "/usr/lib64/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch
result = object(req)
File "/var/www/cobbler/web/index.py", line 130, in handler
content = func( **form )
File "/usr/lib/python2.4/site-packages/cobbler/webui/CobblerWeb.py", line 197, in distro_search_execute
return self.__search_execute("distro",key1,value1,key2,value2,key3,value3,key4,value4,key5,value5)
File "/usr/lib/python2.4/site-packages/cobbler/webui/CobblerWeb.py", line 178, in __search_execute
results = params['distros'] = self.remote.find_distro(criteria,True)
File "/usr/lib64/python2.4/xmlrpclib.py", line 1096, in __call__
return self.__send(self.__name, args)
File "/usr/lib64/python2.4/xmlrpclib.py", line 1383, in __request
verbose=self.__verbose
File "/usr/lib64/python2.4/xmlrpclib.py", line 1147, in request
return self._parse_response(h.getfile(), sock)
File "/usr/lib64/python2.4/xmlrpclib.py", line 1286, in _parse_response
return u.close()
File "/usr/lib64/python2.4/xmlrpclib.py", line 744, in close
raise Fault(**self._stack[0])
Fault:
I would have thought "nothing found" or entire list would return ?
Searching for something that exists gives or using a wildcard gives the following
Mod_python error: "PythonHandler index"
Traceback (most recent call last):
File "/usr/lib64/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch
result = object(req)
File "/var/www/cobbler/web/index.py", line 130, in handler
content = func( **form )
File "/usr/lib/python2.4/site-packages/cobbler/webui/CobblerWeb.py", line 197, in distro_search_execute
return self.__search_execute("distro",key1,value1,key2,value2,key3,value3,key4,value4,key5,value5)
File "/usr/lib/python2.4/site-packages/cobbler/webui/CobblerWeb.py", line 192, in __search_execute
return self.__render( "%s_list.tmpl" % what, params)
File "/usr/lib/python2.4/site-packages/cobbler/webui/CobblerWeb.py", line 102, in __render
return str(tmpl)
File "/usr/lib64/python2.4/site-packages/Cheetah/Template.py", line 982, in __str__
def __str__(self): return getattr(self, mainMethName)()
File "/usr/lib/python2.4/site-packages/cobbler/webui/master.py", line 279, in respond
self.body(trans=trans)
File "_usr_share_cobbler_webui_templates_distro_list_tmpl.py", line 92, in body
File "/usr/lib64/python2.4/site-packages/Cheetah/Template.py", line 1530, in _handleCheetahInclude
self._CHEETAH__cheetahIncludes[_includeID].respond(trans)
File "_usr_share_cobbler_webui_templates_paginate_tmpl.py", line 86, in respond
NotFound: cannot find 'pages'
The above was a Distro search against these distros
# cobbler distro report
distro : rhel-4-u6-i386-as
architecture : i386
breed : redhat
created : Mon Mar 9 09:57:59 2009
comment :
initrd : /var/lib/cobbler/pxeboot/rhel-4-u6-i386-as/initrd.img
kernel : /var/lib/cobbler/pxeboot/rhel-4-u6-i386-as/vmlinuz
kernel options : {}
ks metadata : {'KSrepo': 'http://x.x.x.x/kickstart'}
tree build time : Thu Jan 1 01:00:00 1970
modified : Mon Mar 9 09:57:59 2009
mgmt classes : []
os version : rhel4
owners : ['admin']
post kernel options : {}
redhat mgmt key : <<inherit>>
redhat mgmt server : <<inherit>>
template files : {}
distro : rhel-4-u6-x86_64-as
architecture : x86_64
breed : redhat
created : Mon Mar 9 09:57:56 2009
comment :
initrd : /var/lib/cobbler/pxeboot/rhel-4-u6-x86_64-as/initrd.img
kernel : /var/lib/cobbler/pxeboot/rhel-4-u6-x86_64-as/vmlinuz
kernel options : {}
ks metadata : {'KSrepo': 'http://x.x.x.x/kickstart'}
tree build time : Thu Jan 1 01:00:00 1970
modified : Mon Mar 9 09:57:56 2009
mgmt classes : []
os version : rhel4
owners : ['admin']
post kernel options : {}
redhat mgmt key : <<inherit>>
redhat mgmt server : <<inherit>>
template files : {}
distro : rhel-5-u2-x86_64-as
architecture : x86_64
breed : redhat
created : Mon Mar 9 09:58:02 2009
comment :
initrd : /var/lib/cobbler/pxeboot/rhel-5-u2-x86_64-as/initrd.img
kernel : /var/lib/cobbler/pxeboot/rhel-5-u2-x86_64-as/vmlinuz
kernel options : {}
ks metadata : {'KSrepo': 'http://x.x.x.x/kickstart'}
tree build time : Thu Jan 1 01:00:00 1970
modified : Mon Mar 9 10:14:57 2009
mgmt classes : []
os version : rhel5
owners : ['admin']
post kernel options : {}
redhat mgmt key : <<inherit>>
redhat mgmt server : <<inherit>>
template files : {}
Cheers,
Simon
15 years, 1 month
PXE Server Referral
by Brandon Young
My situation is this: long before I came to our organization, the Windows
administrators built an Altiris deployment server to roll out Windows in our
organization. When I came along many moons ago, the first thing I did was
set up a kickstart system. I then discovered, and have been using, cobbler
since the pre-1.0 days for deploying Linux servers and workstations. Since
Altiris predated my setup, I had to figure out how to shoe-horn cobbler into
the existing PXE configuration on our network (DHCP, DNS, menus, etc). The
solution I devised worked *okay* for a while. It was a bit of a pain,
because every time I updated the cobbler menu, or added a profile, or new
system, I had to manually copy all the related pxe files over to the altiris
server and rebuild the boot menu before the changes could be available to
booting clients. Lately, though, the Altiris management has fallen to very
low priority, and some ill thought out network changes have been made that
resulted in the PXE services proivded by Altiris very unreliable.
Additionally, it has become clear that the Linux group makes much heavier
use of the PXE service than does the Windows group. So, it makes more sense
to figure out how to "shoe-horn" Altiris into a cobbler environment than the
other way around.
What I am attempting to figure out is if there is some simple way to refer a
pxe client (on request) to a different PXE server? What I envision is
something like: a client PXE boots, and is presented with the cobbler menu,
which contains a menu entry (in addition to all my normal entries) titled
"Altiris" that, when selected, redirects the requesting client to Altiris,
where it loads the PXE boot menu managed on the altiris server.
In researching this question, I haven't come up with much. PXE
documentation for Linux tools doesn't seem to address such a scenario.
Other documentation I've found on the web indicates that *some* systems
(namely Windows RIS) have the ability to do such redirection, though it is
unclear whether this redirection is menu driven or not. Altiris
documentation yields no clues for how I might have an Altiris menu option
that simply redirects to my cobbler server, without rebuilding the menu
every time I make a change. Another idea I have come across includes
something manually intensive like maintaining a list of MAC addresses on the
PXE server to which the PXE server will respond (and ignore all others,
causing them to try a different PXE server). I realize it is an option to
relegate the Altiris server to its own subnet, and have cobbler live in
another subnet. Everyone in my organization is agreeable to this solution,
as it would not change the Windows group's workflow, but it would be very
nice if I could somehow redirect clients to Altiris if needed, still. It
would be even better if cobbler could take over as the master PXE server on
all subnets and just redirect to Altiris on demand, though.
Is what I'm seeking even possible? Is there a simple menu entry I can
template in that would redirect a client to a different server? Is this
documented somewhere (and could you point me to it)? By the way, I am using
cobbler 1.4.2 on a CentOS 5.2 server.
Perhaps this could become an enhancement request? Any guidance would be
appreciated.
--
Brandon
15 years, 1 month
Cobblering Cobbler
by JAmes Atwill
Hi,
I'm curious how people bootstrap their initial cobbler instance. My cobbler installation is a VM on a Xen Host which involes configuring a base system, then a VM, then cobbler. Has anyone come up with any other clever ways of automating this?
JAmes
--
James Atwill - Systems Architect
Digital Ocean Marketing
www.digitaloceanmarketing.com
15 years, 1 month
Patch to update lilo conf
by Partha Aji
Basic issue is that /sbin/grubby does not update /etc/lilo.conf unless
you add the --lilo config option .. So if your boot loader was lilo,
koan ---replace-self will not work. The following patch basically adds
the --lilo if the grubby boot probe has "lilo" in it.
One issue I found even after applying this patch was that lilo doesnot
like long "append"s, my append was 223 characters .. I think the max is
200 characters.. This issue went away after I removed the syslog phrase
from the append.. From what I understand the newest koan doesnot add the
'syslog=...' phrase...
Partha
>From a29bf2fcbfac9afe7c3d1268d8330c06679c4840 Mon Sep 17 00:00:00 2001
From: Partha Aji <paji(a)redhat.com>
Date: Fri, 27 Mar 2009 17:46:48 -0400
Subject: [PATCH] Patch to fix the koan rpm not updating the lilo.conf
---
koan/app.py | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/koan/app.py b/koan/app.py
index cf49737..7d69067 100755
--- a/koan/app.py
+++ b/koan/app.py
@@ -689,6 +689,7 @@ class Koan:
print "Kernel loaded; run 'kexec -e' to execute"
return self.net_install(after_download)
+
#---------------------------------------------------
def replace(self):
@@ -707,6 +708,12 @@ class Koan:
except OSError, (err, msg):
if err != errno.EEXIST:
raise
+
+ def get_boot_loader_info():
+ cmd = [ "/sbin/grubby", "--bootloader-probe" ]
+ probe_process = sub_process.Popen(cmd, stdout=sub_process.PIPE)
+ which_loader = probe_process.communicate()[0]
+ return probe_process.returncode, which_loader
def after_download(self, profile_data):
if not os.path.exists("/sbin/grubby"):
@@ -755,6 +762,11 @@ class Koan:
"--args", k_args,
"--copy-default"
]
+ boot_probe_ret_code, probe_output = get_boot_loader_info()
+ if boot_probe_ret_code == 0 \
+ and probe_output.find("lilo") > -1:
+ cmd.append("--lilo")
+
if self.add_reinstall_entry:
cmd.append("--title=Reinstall")
else:
@@ -788,11 +800,8 @@ class Koan:
else:
# if grubby --bootloader-probe returns lilo,
# apply lilo changes
- cmd = [ "/sbin/grubby", "--bootloader-probe" ]
- probe_process = sub_process.Popen(cmd, stdout=sub_process.PIPE)
- which_loader = probe_process.communicate()[0]
- if probe_process.returncode == 0 and \
- which_loader.find("lilo") != -1:
+ if boot_probe_ret_code == 0 and \
+ probe_output.find("lilo") != -1:
print "- applying lilo changes"
cmd = [ "/sbin/lilo" ]
sub_process.Popen(cmd, stdout=sub_process.PIPE).communicate()[0]
--
1.6.0.6
15 years, 1 month
WebGUI: forbidden
by Stephan Huiser
Problem:
after copying server 'mysql01' to 'mysql02' and forgetting to adjust
DNS-name for interface 'eth0' I get an error in the WebGUI and an
exception in /var/log/cobbler/cobblerd.log. All makes sense to me.
I click System List, and I get the following apache response:
Forbidden
You don't have permission to access /cobbler/web/ on this server.
and the following message in /var/log/cobbler/cobblerd.log:
2009-03-28 21:12:43,022 - api - add_system; ['mysql02']
2009-03-28 21:12:43,022 - api - Exception occured: cobbler.cexceptions.CX
2009-03-28 21:12:43,022 - api - Exception value: "Can't save system
mysql02. The dns name (mysql01.dmz.huiser.local) is already used by
system mysql01 (eth0)"
2009-03-28 21:12:43,022 - api - Exception Info:
File "/usr/lib/python2.4/site-packages/cobbler/remote.py", line 1566,
in _dispatch
return method_handle(*params)
File "/usr/lib/python2.4/site-packages/cobbler/remote.py", line 1250,
in save_system
return self.api.add_system(obj,check_for_duplicate_netinfo=True)
File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 388, in
add_system
rc =
self._config.systems().add(ref,check_for_duplicate_names=check_for_duplicate_names,check_for_duplicate_netinfo=check_for_duplicate_netinfo,save=save)
File "/usr/lib/python2.4/site-packages/cobbler/collection.py", line
246, in add
self.__duplication_checks(ref,check_for_duplicate_names,check_for_duplicate_netinfo)
File "/usr/lib/python2.4/site-packages/cobbler/collection.py", line
364, in __duplication_checks
raise CX(_("Can't save system %s. The dns name (%s) is already used
by system %s (%s)") % (ref.name, intf["dns_name"], x.name, name))
2009-03-28 21:13:22,434 - api - login attempt; user(admin)
2009-03-28 21:13:22,434 - api - authenticate; ['admin', True]
2009-03-28 21:13:22,435 - api - login succeeded; user(admin)
2009-03-28 21:13:22,437 - api - Exception occured: exceptions.KeyError
2009-03-28 21:13:22,437 - api - Exception value:
'XnwO3JhECw6dUfM1wiqEwdsTEGIKuMn/kw==\n'
2009-03-28 21:13:22,437 - api - Exception Info:
File "/usr/lib/python2.4/site-packages/cobbler/remote.py", line 1566,
in _dispatch
return method_handle(*params)
File "/usr/lib/python2.4/site-packages/cobbler/remote.py", line 1006,
in check_access
validated = self.__validate_token(token)
File "/usr/lib/python2.4/site-packages/cobbler/remote.py", line 949,
in __validate_token
self.__invalidate_expired_tokens()
File "/usr/lib/python2.4/site-packages/cobbler/remote.py", line 925,
in __invalidate_expired_tokens
del self.object_cache[token]
OS: RHEL 5.3 x86_64
rpm -q cobbler: cobbler-1.6.1-1
What can be wrong?
Do you need more info?
regards, Stephan
15 years, 1 month
Fix for Cobbler 1.6 token cleanup issue
by Michael DeHaan
This bug causes cobblerd to crash approximately 10 minutes after a new
object is created in the Web app / XMLPC:
diff --git a/cobbler/remote.py b/cobbler/remote.py
index 0613e6f..3dd2674 100644
--- a/cobbler/remote.py
+++ b/cobbler/remote.py
@@ -922,7 +922,7 @@ class CobblerXMLRPCInterface:
for oid in self.object_cache.keys():
(tokentime, entry) = self.object_cache[oid]
if (timenow > tokentime + CACHE_TIMEOUT):
- del self.object_cache[token]
+ del self.object_cache[oid]
def __validate_user(self,input_user,input_password):
"""
As you can see, it's a simple typo. I had thought I tested the
timeout, but this slipped through. I'll be testing this more
thoroughly over the next hour or so, and then I'll unpush 1.6.1 and get
a 1.6.2 RPM out.
There will be no other changes to 1.6.1.
If other items come up later, we'll do a 1.6.3 and so forth, but I
wanted to get this out there for all webapp/XMLRPC users.
--Michael
15 years, 1 month
[ANNOUNCE] Cobbler 1.6.1 and koan 1.6.1
by Michael DeHaan
Hello everyone,
It's time for us to release Cobbler 1.6.1 and the accompanying koan 1.6.1.
Release notes are here:
https://fedorahosted.org/cobbler/wiki/WhatsNewInOneSix
This release contains a number of important things, as mentioned above,
the most important being some EXTREMELY awesome performance speedups
that I believe take Cobbler into a whole new level
of enterprise worthiness. We also have a new S390 PXE simulator
feature that I think is unlike anything (free) out there, and allows you
to treat mainframes like physical systems. This is very cool.
There are also a fair amount of bugfixes as well, which are always good
to have.
Please pound on things as much as possible.
I've already built these in the build system and they should be
available on mirrors shortly. If any problems come up, we'll fix them
in a 1.6.1 release.
If you have any questions, need any clarifications, or have any
comments, please share them on this list.
Development continues on the development branch of git, #cobbler-devel
on irc.freenode.net, and
https://fedorahosted.org/mailman/listinfo/cobbler-devel
I know I've said "I couldn't have done this without you" many times
before, though this time I don't need to say it -- it's "We couldn't do
this without Us". As shown on github, Cobbler is now a project where
most of the changes happen outside of me (and in many cases, outside of
Red Hat). This is tremendous, and thanks everyone for contributing --
not just coding -- but everyone, whether you have an interesting idea, a
snippet, helped test this release, helped share cobbler at conferences,
and so on.
Please continue to share things with your friends and colleagues and
we'll continue to absorb everyone's good ideas and code as we go along.
(Also, adding yourself to
https://fedorahosted.org/cobbler/wiki/WhoUsesCobbler if you haven't done
so already can't hurt! It's free press for your organization and
Cobbler alike)
The future of 1.8 looks very bright -- new network objects, increased
cross-distribution support, and better support for virtual images are
all on the line. We'll also probably see some new API ways
of talking to Cobbler (AMQP+QMF) and so on. Look for more RFEs for
Trac to get spun in as well as we continue moving forward. And as
always, I expect to be suprised with a lot of new things
I didn't predict were coming as well -- you all do an outstanding job of
that.
Thank you all for a great release.
(If in fact we ended up screwing this release up horribly, just the
same, let us know... we'll get you fixed up ASAP.)
If you don't want to wait, source RPMs and tarballs are available
here: http://people.fedoraproject.org/~mdehaan/files/cobbler/
--Michael
15 years, 1 month
Cobbler sync timing out on Bond interfaces
by Chris Weaver
You may recall me posting this issue this late last year. I was never
able to resolve this problem and I kept thinking "next release, next
release" but sadly it was not to be. I'm on 1.4.3 now and it's still
here.
Here's the issue again: cobbler sync is timing out when I have bonded
interfaces. I have 9 systems, each has 1 bonded interface with a VLAN
interface on top of it, and then a second bonded interface, and all
but 3 have a third bonded interface. When I do a cobbler sync, after
5 minutes 22 seconds it times out with:
join() is too long for a Python string
File "/usr/lib/python2.3/site-packages/cobbler/cobbler.py", line 83, in main
rc = BootCLI().run(sys.argv)
File "/usr/lib/python2.3/site-packages/cobbler/cobbler.py", line 61, in run
return self.loader.run(args)
File "/usr/lib/python2.3/site-packages/cobbler/commands.py", line 122, in run
return fn.run()
File "/usr/lib/python2.3/site-packages/cobbler/modules/cli_misc.py",
line 186, in run
return self.api.sync(verbose=self.options.verbose)
File "/usr/lib/python2.3/site-packages/cobbler/api.py", line 523, in sync
return sync.run()
File "/usr/lib/python2.3/site-packages/cobbler/action_sync.py", line
128, in run
self.dhcp.write_dhcp_file()
File "/usr/lib/python2.3/site-packages/cobbler/modules/manage_isc.py",
line 262, in write_dhcp_file
self.templar.render(template_data, metadata, settings_file, None)
File "/usr/lib/python2.3/site-packages/cobbler/templar.py", line
134, in render
data_out = data_out.replace("@@%s@@" % str(x), str(search_table[str(x)]))
My workaround has been (and still is) to remove all the bond and VLAN
interfaces before the sync, then re-add them afterward. When I do
this, the sync is pretty quick.
At one point Michael had suggested turning off omapi -- but it is off,
and always has been. FYI I'm on RHEL 4.6.
Anyone have any ideas?
--
... Chris Weaver
15 years, 1 month