Not necessarily. Is there any reason we couldn't extend cobbler
to
manage iscsi exports or other methods?
Well, it could do *anything* the question is, what would be the
(cobbler) method, hypotehtical or otherwise,
to configure it to work that way -- and why would you really need to?
It seems like serving everything
httpd for starters *off* of the Cobbler server makes good sense.
The issue here is the supported version of syslinux. Newer versions
of
pxelinux support httpd natively, however RHEL/CentOS 5 (and 4 of
course) may not have access to those versions. This is a stop-gap for
the next 3-5 years in which we will support those distros. At some
point, we could revert back to a pure pxelinux implementation (or not,
if we do end up supporting stuff like iscsi and AoE).
I'd be ok with requiring folks setting up a cobbler to just go get a new one
and hosting it like we did with "cobbler get-loaders", even as ugly as that
was.
Older syslinuxes were a frequent cause of the hangs at the PXE boot menu anyway.
> (I'm also a bit curious why VMware ESX won't boot from pxelinux.0, but
> that's just for my info and unrelated)
It does - the limitation as I noted in the original email is that you
have to copy all of the ISO contents to the tftp directory. The ESXi5
install supports httpd through gpxe only. In order to get that to work
with cobbler sync and the --boot-files option, some ugly hacks had to
be made allowing for globs so that all files would be copied. That
could become a management issue too, since for older distros /tftpboot
is in the root file system and may not have a ton of space available.
So it doesn't really have a notion of an install tree like kickstart does?
Yikes.
You could always hardlink /tftpboot somewhere else if you had to.
Would be nice to document all this here in terms of deploying the ESX
boxes themselves:
https://github.com/cobbler/cobbler/wiki/VMware -- which mostly
pertains to launching guests and I'm sure is somewhat out of date not
marking the difference between workstation/fusion and server.
>>
>>> + ks_mirror_name =
string.join(distro.kernel.split('/')[-2:-1],'')
>>> 862
>>>
>>> FYI -- This seems to imply the distro must be mirrored by Cobbler.
>>> It seems like the code needs to anticipate this this possibility?
>>
>> Yes and no - there's no reason the http server in question has to be
>> cobbler. Covering that case would be a todo, but I didn't give it
>> priority since I believe the number of people who use the
>> --available-as option are relatively small. I'm pretty sure that
>> option doesn't work with esxi4 either (since at least 6 files need to
>> be copied to the tftp directory), so I figured the people who'd use
>> this feature right now for esxi5 wouldn't care about that limitation
Maybe raise a warning then. Sounds like we need a seperate GPXE page
on the Wiki or something. As long as it's documented what works and doesn't
that should be fine.
>
> IIRC, --available-as isan option to import.
>
> I was thinking about the manual "cobbler distro add" case, where you
> might not even have a "tree" parameter at all, and the files might
> live on NFS somewhere.
>
> I'd probably attempt to make sure the path *looked* like a cobbler
> path, and if not, maybe raise an error or something.
>
> Maybe this is just the way I percieved it, but I basically view import
> as a shortcut path around distro add/profile add/etc, not the path you
> always have to go down.
>
> Anyway, some way to yell at you if you're doing it wrong seemed to be
> my point.
>
> if distro.kernel.find("ks_mirror") != -1:
> raise Exception("...")
>
> or something like that
>
>
> --Michael
> _______________________________________________
> cobbler mailing list
> cobbler(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/cobbler
>
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler