David,
Thanks for the feedback, a few comments below... I'll look into
incorporating some of this into 0.3.6.
David Mackintosh wrote:
Hi there,
I've just done a moderate sized cobbler installation (currently
twelve distros with more to come, eventually more than a hundred
systems) and have a few comments based on what I have seen so far.
These are probably minor quibbles.
This is installed from the 0.3.4-1.src.rpm
1. Cobbler doesn't appear to understand -v, -V, or --version
...which isn't entirely necessary if it is installed from rpm
(rpm -qa | grep cobbler gets me the info I needed) but it would
still be nice.
That's valid, though I would hope everyone is always installing from
the RPM.
2. Brief output should at least be an option, if not a default.
I want the equivilent of
# cobbler list --profiles | grep profile
...since the vast majority of the time I don't care about the details
of a profile, I only want to see the list of names because I have so
many of them I've forgotten what I called the one I want. Yes this
is mostly my fault for frequently forgetting/changing my "standards"
but it would be nice if the tool could help.
This would be a good add.
3. Semantically, since cobbler uses
# cobbler system add [...]
...cobbler should therefore understand
# cobbler system list
...instead of requiring
# cobbler list --systems
I have nothing against the latter, but the former fits more
semantically into the COMMAND OBJECT ACTION model I like to use.
Perhaps this form of the command would be a good place to put the
brief output.
I find myself typing the same things occasionally and wondering why I
didn't do it that way :)
Perhaps "cobbler system list" and "cobbler system list --full".
Or maybe you want to change the other commands to the form
# cobbler add --system
...but either way it should be more consistant.
4. Sorted output would be nice.
The output of the various lists are not sorted by either order-added
or some kind of alpha-numerical sort; either would be adequate, and
the latter obviously preferred.
This makes good sense and is an easy fix.
One could even argue that since the "index" of a profile/distro/name
which preceeds the name will probably change as other things are
added and removed, and are not used anywhere (ie you can't refer to a
profile as "profile #3" anywhere) it should be dropped entirely from
the output.
True.
5. Unless I misunderstand something, if I define my profiles with
URLs to ks.cfg files instead of file references, there is nothing
served through httpd by cobbler. In this case it would be nice
if cobbler didn't restart my httpd every time I ran cobbler sync.
Yes and no. The restart /is/ unneccessary. As to why the web
directory is there, cobbler's web directory is also used to serve up
configuration files for koan as well as to mirror kickstart trees and
(in 0.3.5) yum repositories. Adding some logic to know when a
restart is required does make sense, though. Basically once cobbler
is used beyond minimal PXE support, the web directory starts to grow
increasingly important.
6. If manage_dhcp is set to 0, cobbler check should not complain
about missing dhcpd pieces.In my case dhcpd is on another system
under another set of script'scontrol, so cobbler needn't be bothered
about those details. Maybe an option to tell it not to warn about
those kinds of things would
be in order (squelch_dhcp_warnings or something).
END COMMENTS
Cobbler check is there for people who really don't know what setting
up a PXE environment entails (i.e. whether or not they set up
next-server or not), and can use those pointers. Those that
understand the warnings should be able to know when they don't
apply. They do apply when manage_dhcp is not set and the user is
running a local DHCP server. This should probably stay as is, though
if the warnings are confusing, they definitely should be amended, and
I could use some suggestions as to how they were confusing and what
you think they ought to say instead.
All that said, these are exceedingly minor quibbles. Cobbler has
already saved me a ton of time and made me look good in front of two
moderately-sized customers (always a plus).
I do have a question about the implementation -- is there anything
that would prevent cobbler from running on, say, a Solaris system? I
ask because I already have a fairly extensive host-management system
set up that runs on Solaris, and it would be reasonably
straight-forward to integrate cobbler into it so that a user could
say
# need_shoes --system="text-name" --profile="profile-name"
(ie need_shoes asks the cobbler for boots, or maybe you'd name it after
a shoe vendor or something... to beat a naming convention to death :)
...and have that script dig the IP address and MAC out of NIS, doctor
dhcpd (if necessary -- I'm already doing much of that, which is why in
my past comments I was resistant to cobbler doing it as well), and
do the final "cobbler sync" automatically, making it a one-stop for
my administrators.
Cobbler's rather RHEL/Fedora/Centos centric at this point, and I
really don't intend on changing that. Namely it knows
the job it needs to do and wants to do that job well.
I _do_ think it is reasonable to be able to provision other forms of
targets, similarly to the steps cobbler already takes to allow PXE
provisioning of IA64
Linux systems (which require different bootloader configuration
files). So if it's just something that involves some minor support
in action_sync.py to build a slightly different bootloader config,
that might be a good patch candidate.
A second question -- while thinking about #5 above, it occured to me
that I don't immediately understand why cobbler copies the vmlinuz
and initrd.img files into the httpd tree. Why do you do that?
It's all about koan. Koan allows for provisioning of remote systems
when a PXE environment is not available.
For instance:
"yum install koan"
"koan --replace-self --server=cobbler.example.com --profile=fc6test"
/sbin/reboot
Koan also does virtual image installs (currently it only supports Xen,
though this will probably expand later):
"yum install koan"
"koan --virt --server=cobbler.example.com --profile=myvirtualwebserver"
Thanks again for cobbler.
You're welcome! Thanks again for the comments!
------------------------------------------------------------------------
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
