Javier Palacios wrote:
Hi,
I've started to work in order to allow debian provisioning with
cobbler. I send attached two patches.
The first on is actually not strictly related to debian, and it's a
reorganization of the archs management,
to simplify it and ease smooth addition of other distros: debian calls
amd64 to x86_64, and the idea is
to keep the RedHat names as canonical ones.
The second one does actually allow to import the content of a debian
CD/DVD and create the corresponding
distro. It also creates the profile breeded as debian, although it
might not be usable yet.
There are a couple of open questions that might affect other parts of
cobbler or where just ideas are required.
- the kickstarts for debian. They are called "preseed", and are by far
much more complex than a standard
kickstart. Although not strictly required, it might be better to
have new names for both ks files and directories,
Cobbler used to have the alias "--answer-file" for "--kickstart"
though
if added it should once again only be an alias, as opposed to having
different field storage for the answer file. Essentially this is what
we do already for --breed=debian (preseed) or --breed=suse (AutoYAST),
both being supported already. For Ubuntu kickseeds, you just use
--breed=redhat and need to be very careful with the contents of the
kickseed.
I have also been told kickseeds have been applied to upstream Debian,
but haven't been able to validate this or know whether they are in fact
a good option. I'll leave that for other people to answer.
The other thing this import should do, that is very important, is to
package a good default preseed so users can get a fully automated setup
out of the box. Just creating the distro is pretty easy, the magic is
in setting up something for a user who doesn't know how to write one
that installs a base package set.
but I think that they can be easyly added to PXE boot options. To
make things worst, ubuntu does allow both
the standard debian preseed and kickstart files.
- the package repositories. Debian follows a quite different approach,
and a single tree can hold many versions
and different architectures. Allowing a cobbler distro to have
multiple architectures might reduce the disk usage
and simplify the repository updating. Due to this fact, a single
debian media can install multiple archs, complexing
a little bit to import the media.
I've heard adding support for "cobbler repo" style objects would be
difficult here. One option is to just not support them and require that
they be managed out of band.
These are the only two points I see on the close horizon, but there
are probably more. It anyone has concerns
or ideas, they are welcome. And if anyone can actually test the
deployment (when it matures a little bit), much better.
Javier Palacios
------------------------------------------------------------------------
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler