DHCPv6
by Dan Rao
Hi all,
Over the weekend I made some hacks to Cobbler that could be useful to
other people, so if there is interest I'll clean it up a bit and submit
a patch. Below is a description of the issue and what I did (apologies
in advance, it's long).
Scenario:
We have several thousand machines spread over 3-4 locations. We use
Cobbler to provision these machines, and manage DHCP and DNS (all sites
share a single domain name). We use Puppet for config management.
We're moving towards IPv6 for various reasons. In the near term we'll be
running dual-stack, so any IPv6 configuration that needs to happen can
be tacked on via Puppet.
Again for various reasons, we're not going to do IPv6 autoconfiguration
(DNS is difficult with this, for one). So that leaves DHCPv6.
As far as I can tell, the IPv6 fields in Cobbler don't really do
anything at the moment. (We run 2.2.1 from EPEL, but I didn't see
anything to indicate this is changed for a newer version - though I may
be wrong!).
Complicating factors:
>From reading various docs it looks like the current ISC DHCPd doesn't
support both IPv6 and IPv4 at the same time. Therefore it's necessary to
create a separate config file (dhcpd6.conf) and run a second instance of
the daemon with this config.
A second issue is that DHCPv6 implies the use of a unique client
identifier (DUID). The DUID is generated by the client, and in the case
of DUID-LLT which includes the time of generation, does not persist
between reinstalls. DHCPv6 does support DUID-LL (just the MAC address),
but DUIDs are unique per machine, not per interface, so that can cause
problems in some situations unless care is taken.
The terrible hack:
ISC DHCPd lets you use the MAC address (or anything you want, really)
instead of the DUID to identify v6 clients. Since we depend on having
the MAC address available for v4 DHCP, I don't see too much harm in
using this for IPv6 address allocation as well. Proxied DHCP will break
of course, but DHCPv6 addresses that via some other mechanism anyway.
So what I did was essentially add a module to generate dhcpd6.conf
(using MAC addresses and IPv6 addresses configured in Cobbler) in
parallel with dhcpd.conf, and manage the dhcpd6 service. I added a
parameter to the settings file "manage_dhcp6" to enable/disable this
behavior.
I realize this isn't the "IPv6 way", but in the short term it suits our
needs pretty well. I imagine the standards and what not will get
straightened out once there is wider adoption...bit of a catch-22 if you
ask me.
Thoughts, comments, flames etc welcome.
Best,
Dan
12 years, 1 month
Certificate-based RHN registration snippet
by Jim Nachlin
Hi List,
Red Hat is moving to a new, "certificate-based" registration system.
They are doing away with rhn_register and moving to
subscription-manager.
Here is a trivial but possibly useful snippet which we have saved as
/var/lib/cobbler/snippets/install-puppet:
# Subscribe (register) the system
subscription-manager register --autosubscribe --username=XXXXXXX
--password=XXXXXXXXXX
# Add what used to be called channels
yum -y install yum-utils
yum-config-manager --enable rhel-6-server-optional-rpms
yum-config-manager --enable rhel-6-server-supplementary
I don't know the process for adding it to the cobbler github project,
and I'd want to make the username and password into settings rather
than having them hard coded, but I am open to doing that work and
adding it if it is wanted.
Regards,
Jim
12 years, 1 month
fetching kernel/initrd from a distro
by Uwe Gansert
Hi,
I want to get your opinion about a little patch. I'm looking at this
code in koan/app.py:
def get_distro_files(self,profile_data, download_root):
"""
Using distro data (fetched from bootconf tree), determine
what kernel and initrd to download, and save them locally.
"""
os.chdir(download_root)
distro = self.safe_load(profile_data,'distro')
kernel = self.safe_load(profile_data,'kernel')
initrd = self.safe_load(profile_data,'initrd')
kernel_short = os.path.basename(kernel)
initrd_short = os.path.basename(initrd)
kernel_save = "%s/%s" % (download_root, kernel_short)
initrd_save = "%s/%s" % (download_root, initrd_short)
you can see, when the kernel+initrd is fetched, it's stored locally with
the os.path.basename(kernel) and os.path.basename(initrd)
At least on a SUSE system, that leads to "linux" and "initrd".
So if you want to trigger a reinstall of a machine with koan, it'll
store the kernel at:
/boot/linux
and the initrd at:
/boot/initrd
that will overwrite the existing initrd of the SUSE system which is
already stored in /boot/initrd
That means, there is no way back. If you now decide to abort the
reinstallation, you lost you old initrd. If you choose to boot the
system, it'll load the old kernel but the initrd of the inst-sys now.
What do you guys think about something like this?
kernel_save = "%s/%s%s" % (download_root, kernel_short, "_koan")
initrd_save = "%s/%s%s" % (download_root, initrd_short, "_koan")
that will keep the installed kernel/initrd intact.
Do you see any bad sideeffect?
--
ciao, Uwe Gansert
SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net
12 years, 1 month
Re: [cobbler-devel] [PATCH 0/5] Port koan from virtinst to virt-install command
by Michael DeHaan
On Monday, February 6, 2012 at 2:55 PM, Cole Robinson wrote:
> On 02/06/2012 12:34 PM, Michael DeHaan wrote:
> >
> > On Monday, February 6, 2012 at 11:37 AM, Cole Robinson wrote:
> >
> > > On 02/06/2012 10:58 AM, Michael DeHaan wrote:
> > > > Cole --
> > > >
> > > > What's the workaround to auto-start Xen PV's? (or is there not a way?)
> > > >
> > > > Seems like we could just implement this however needed (if xenpv… do this
> > > > instead…), if virtinstall won't do it for us.
> > > >
> > >
> > >
> > > The autostarting code could just be conditionally enabled if virt-install is
> > > new enough (just a grep of the help output) so that's not the issue.
> > >
> > > The issue is that current koan code manually passed a kernel + initrd for the
> > > PV guest to boot. That's the only install scenario for PV guests AFAICT. And
> > > this is only available via the virt-install in a version newer than what's in
> > > RHEL5.
> > >
> >
> >
> > That's also how the virt installs work for everything else in koan, including
> > qemu/KVM.
> >
> > (Maybe I'm misunderstanding something?)
> >
> >
>
>
> This is my understanding of the current code.
>
> Xen FV: always does a PXE boot (so guest is actually talking to PXE server):
> https://github.com/cobbler/cobbler/blob/master/koan/xencreate.py#L80
>
> Xen PV: Libvirt tells the guest to boot directly off the kernel/initrd pair
> specified in profile_data["kernel_local"] and profile_data["initrd_local"]:
> https://github.com/cobbler/cobbler/blob/master/koan/xencreate.py#L88
>
> (are those kernel_local + initrd_local values filled in by cobbler or does the
> user need to manually specify them?)
>
> QEMU/KVM has two install options:
>
> if profile_data["file"] is present, boot off it like a cdrom:
> https://github.com/cobbler/cobbler/blob/master/koan/qcreate.py#L101
>
>
Don't think I care about this one, meaning I think we could get rid of it.
>
> if profile_data["install_tree"] is present, pass the URL off to virtinst and
> have it use it's tree probing to fetch kernel + initrd:
> https://github.com/cobbler/cobbler/blob/master/koan/qcreate.py#L121
>
Ugh yes, I believe that was required as it didn't support the other at the time or something.
It has been a while. I had to work around a lot of inconsistencies and seem to recall thinking
it was easier than it was :)
>
>
>
>
> My implementation preserves this behavior, but in reality Xen FV and Qemu can
>
>
> all boot from tree/kernel, cdrom, and pxe. Xen pv can only boot from
> tree/kernel (which is the same thing basically).
>
>
Requiring PXE is disadvantageous to those that don't have DHCP, so yeah, I don't think that should
be the default way.
>
> My suggestion was to adapt xen pv to behave as qemu does with "install_tree".
>
Sounds reasonable.
>
> > >
> > > The workaround could be to make PV installs work like qcreate install_location
> > > installs, which is basically the same as direct kernel/initrd boot but you
> > > rely on virt-install to pull the kernel/initrd from the install tree.
> > >
> >
> >
> > Just trying to make sure this wouldn't break anyone.
> >
> > The install tree location isn't actually required in Cobbler, it's only a
> > parameter to the kickstart … Are you saying we'd have to use the install
> > tree method *only* for Xen PV? If so, that might be an acceptable
> > limitation… if Xen FV or qemu/KVM requires the tree to find the
> > kernel/initrd that seems bad to me, because we deal with a lot of arbitrary
> > distros that express install tree locations in different ways.
> >
>
>
> > ks_meta["tree"] gives you this if someone had ran "Cobbler import" previously.
> >
> > If we can avoid using that when we don't have to, that would be good…
> >
> > > Since
> > > cobbler tracks this info it would probably 'just work' with a tiny patch but
> > > someone would need to test. And this has been supported on virt-install
> > > command line since probably rhel5.1
> > >
> >
> >
> > "it" == making autostart work for Xen PV, right?
> >
> >
>
>
> No, autostart is not the issue here. The issue is getting guests to actually
> install. The autostart piece is just recent functionality to cobbler that
> currently brok all installs on RHEL5 host. Fixing this would be a fairly
> trivial patch on top of current koan or my code.
>
> The more interesting piece is making xen PV installs actually work on RHEL5
> where virt-install is not new enough to provide the cli option needed to have
> parity with current xen PV installation, which requires passing a local kernel
> + initrd path to boot from.
>
> Sorry if that isn't clear.
nod, ok, all sounds reasonable -- send me a pull request or whatever with what you think sounds reasonable -- ideally after trying it out live, and we'll merge it in.
Thanks for the explanations.
>
> Thanks,
> Cole
>
>
12 years, 1 month
Some questions regarding extension of cobbler suse snippets/templates
by Christian Horn
Hi cobbler-devel,
there are some suse sles related things that could make sense to
be included directly in cobbler.
These pieces are currently here:
https//fluxcoil.net/doku.php/cobbler/sles .
Uwe, I think the existing suse pieces are from you, so you
might be able to point out some things I am missing.
Here are my questions, please comment if things make sense
to get included and in which way:
- Currently cobbler comes with autoyast_sample.xml, I think of additionally
shipping a autoyast_complex.xml, with these things included:
- snippet which sets up kdump
- a construct which allows sles-rootpw to be set if specified
as ksmeta $rootpw
- code which allows selection of one of 3 package selections
which are selected via a ksmeta, minimal/tiny/big
- post snippet: disabling of some services
- post snippet: this deploys a snippet with pure shellcode
(which works also for rhel and cleans up /etc/grub.conf),
and a wrappersnippet. The wrappersnippet makes it possible
reuse snippets written for rhel (containing shellcode) also for
sles (in wrapping it in the xml code that autoyast expects).
Which of these look useful for inclusion? Should documentation happen
inline as comments or in wiki?
- While the above works here for sles11, with some functions dropped I have this
also here for sles9 and 10. These are separate template files, and separate
interface snippets for these other distros. Is this of interest to be included?
- currently, when the networking.xml snippet is included and the hostname
does not contain a hostname it bails out with an error message.
In the code here this is checked for using
#if re.match('.*\..*', $hostname)
- the current networking.xml is not adapted to use $network instead
of $subnet .
The scripts here cope with both now, when changing this in git then
only the $netmask has to be used I guess?
- current cobbler git head uses the SuSE subdirectory, I am currently only
testing with cobbler 2.2 in fedora updates-testing.
- currently, autoyast.xml is not directly usable as cobbler template.
It is xml valid, but the <!-- comments --> at the beginning seems to be the
problem. So users have to remove this bevore using.
I would suggest this file no longer be xml valid, instead using here
## these
## comments
which are filtered out by cobbler later.
Opinions on the points above welcome.
cheers, Christian
12 years, 1 month