Doing PXE without control over the DHCP server
by Niels Basjes
Hi,
A long time ago I asked and later documented on Stack Overflow how to do
PXE if you do not have control over the central DHCP server.
http://serverfault.com/questions/53116/howto-setup-cobbler-with-pxe-if-yo...
A few months ago I got an email from someone stating he couldn't get the
above to work. He also stated
I sent an email about this issue to the cobbler mailing list and even
Michael Dehaan, the cobbler creator, did not know about this
possibility, so I think your input would be useful to many people.
So that is the purpose of this mail; It may be useful to you guys.
Turns out that I had done some fixing and changing of my own cobbler (long
time ago) that I had forgotten about.
So a few days ago I provided the crucial fix to the mainline
cobbler<https://github.com/cobbler/cobbler/pull/157> which
has now become part of the trunk.
https://github.com/cobbler/cobbler/pull/157
I also created some additional supporting
documentation<http://howto.basjes.nl/linux/doing-pxe-without-dhcp-control>
to
explain in broad terms how to use this.
http://howto.basjes.nl/linux/doing-pxe-without-dhcp-control
The mentioned fix also has another usecase which I have deployed several
times.
I can now define a MAC address, IP address, hostname combination in cobbler
and instruct it to install CentOS with a kickstart file that also installs
puppet.
Because with this fix the client gets a fixed hostname I can use puppet to
cleanly define what software needs to be installed.
In addition I can choose to omit the IP address and has a situation where
the client gets a fixed hostname in an environment where I leave the IP
addresses dynamic.
This last usecase is something I see as a viable scenario for deploying
roaming Linux desktops/laptops and maintaining control over the installed
software using a tool like puppet.
--
Met vriendelijke groeten,
Niels Basjes
11 years, 11 months
New feature branch - dynamicsettings
by James Cammarata
https://github.com/jimi1283/cobbler/tree/dynamicsettings
commit 862e3f583efc6055e5a605a60ee29298a968e53b
Author: James Cammarata <jimi(a)sngx.net>
Date: Sun Apr 1 20:29:51 2012 -0500
Initial support for modifying settings live
Changed settings do not survive a reboot and revert to what's in
/etc/cobbler/settings
TODO:
* report --name show a single setting
* validate settings based on type (string, list, bool, etc.)
* web support for editing
* persisting settings after change
Obviously, a lot still todo, but I think this is something that's been
long overdue. I haven't quite figured out the best way to save
settings without mangling the /etc/cobbler/settings file, but I'm
leaning towards a template to preserve the existing format with all
the comments. Any other suggestions are welcome.
Not sure if this would get done for 2.4, but I would like to target it
for that release.
12 years
[RFC PATCH] ensure DHCP is current via sync
by Nishanth Aravamudan
Hi,
I encountered a rather annoying problem with cobbler for ppc64 systems.
The way these machines netboot is controlled by the SMS configuration,
and if the SMS menu receives a DHCP response, even if it eventually
fails, it will stay in an infinite loop within the netboot code. That
code is not modifiable by me (owned by system firmware). What I
encountered with Cobbler was that after an install succeeded, the DHCP
configuration file was left alone. So the DHCP server would respond on
the network on the next boot and the target server never booted from the
disk.
I worked around this by only generating the DHCP configuration if a
system does have netboot_enabled set and re-generating the DHCP files
via sync() whenever disable_netboot() is called.
Signed-off-by: Nishanth Aravamudan <nacc(a)us.ibm.com>
diff --git a/cobbler/modules/manage_isc.py b/cobbler/modules/manage_isc.py
index b8f857f..8681d94 100644
--- a/cobbler/modules/manage_isc.py
+++ b/cobbler/modules/manage_isc.py
@@ -161,6 +161,9 @@ class IscManager:
interface["owner"] = blended_system["name"]
interface["enable_gpxe"] = blended_system["enable_gpxe"]
+ if not interface["netboot_enabled"]:
+ continue
+
interface["filename"] = "/pxelinux.0"
# can't use pxelinux.0 anymore
if distro is not None:
diff --git a/cobbler/remote.py b/cobbler/remote.py
index 0035e34..28cf180 100644
--- a/cobbler/remote.py
+++ b/cobbler/remote.py
@@ -1166,6 +1166,8 @@ class CobblerXMLRPCInterface:
obj.set_netboot_enabled(0)
# disabling triggers and sync to make this extremely fast.
systems.add(obj,save=True,with_triggers=False,with_sync=False,quick_pxe_update=True)
+ # re-generate dhcp configuration
+ self.api.sync()
return True
def upload_log_data(self, sys_name, file, size, offset, data, token=None,**rest):
--
Nishanth Aravamudan <nacc(a)us.ibm.com>
IBM Linux Technology Center
12 years
2 snippets necessary to install SLES on ppc with cobbler
by Nishanth Aravamudan
Hi all,
So SLES has the annoying habit of changing the system boot order after
installation. This leads to failed automated installs. To work around
this, I have two snippets I use locally (and have only tested on
SLES11-SP2, tbh):
save_boot-device:
cat /proc/device-tree/options/boot-device > /root/boot-device.bak
restore_boot-device:
nvsetenv boot-device "$(cat /root/inst-sys/boot-device.bak)"
This does seem to work for power on the systems I've tested, and they
seem generally useful for SLES installations. But I'm not quite sure the
right way to send them upstream. I think the snippets themselves are
useful enough to be in snippets/. But would it be appropriate to put the
changes in autoyast_sample.xml? Or is this something that should be
managed by the import side, when importing sles on ppc? I'm just not
sure how to document the existence and use of these snippets if they
aren't present in the XML obviously.
Thanks,
Nish
--
Nishanth Aravamudan <nacc(a)us.ibm.com>
IBM Linux Technology Center
12 years
