Kickstart tracking in 0.3.6

Friendly Neighborhood Cobbler Users,

One of the things I've wanted to do with cobbler for some time was be 
able to keep track of systems as they kickstart, so that higher level 
applications and scripts could, if they wanted, try to detect which 
machines had stalled or otherwise failed to complete.    Some 
rudimentary support for this is going into upstream now, and I'll be 
refining it some more over the next few days.

How does it work?

Well, it only works for kickstart trees that come out of 
/var/www/cobbler -- local content -- so if you're installing off of a 
Fedora mirror, this gives you more reason to let Cobbler mirror that 
distro and serve it locally (plus, it's nicer to the guy running the 
mirror).   This means kickstart tracking will work for any distros that 
have been pulled down via "cobbler import" or any distributions you have 
created yourself in that directory (/var/www/cobbler/localmirror/foo is 
the preferred destination for such content).   If you already have a 
kickstart tree elsewhere, symlinking it should be good enough if you 
configure Apache appropriately.

So, how it works -- this new release installs a mod_python filter 
handler automagically for /var/www/cobbler, and access to certain files 
in that directory are logged with the IP address of the requester, the 
time, and the file requested.    From this, it is possible to tell what 
profiles are being requested, what RPM's they've requested, and when 
they are done (they request a special filename at the bottom of their 
kickstarts when they are done).   This all currently goes into 
/var/log/cobbler/cobbler.log and there is a logrotate script in 

Cobbler on Solaris 9

Although firmly filed under "stupid computer trick", it may amuse
you to know that the .tar.gz of cobbler 0.3.5 will install correctly
on a SPARC Solaris 9 system with the csw python installed.

Predictably it isn't happy about not being able to find httpd, but
the setup of distros, profiles, and systems works correctly, and
from this platform I have installed several flavors of CentOS,
RHEL-3ES and RHEL-4ES to i386-family systems.

(Importing distros (via rsync) has not been tested as I manage my
distros through other methods, but offhand there isn't really any
reason why this wouldn't work.)

Why might this be useful?  Well I already have a set of scripts for
managing my hosts infrastructure (DNS, NIS, DHCP) plus a tftp server
for Solaris Kickstarts already in existance, and this lets me do
everything from one server.

So I can now say:

# cobbler_byname --host tpx18 --profile RHEL-3ES-U6-i386-ws

...and it generates and runs the appropriate cobbler command for
me, instead of me having to dig out the MAC and IP address for
the system manually.

cobbler_byname is a perl script which I can provide if anyone is
interested.

--

-- 

Re: Cobbler on Solaris 9

David Mackintosh wrote:
> Although firmly filed under "stupid computer trick", it may amuse
> you to know that the .tar.gz of cobbler 0.3.5 will install correctly
> on a SPARC Solaris 9 system with the csw python installed.
>
> Predictably it isn't happy about not being able to find httpd, but
> the setup of distros, profiles, and systems works correctly, and
> from this platform I have installed several flavors of CentOS,
> RHEL-3ES and RHEL-4ES to i386-family systems.
>   
Neat.   For things like getting "cobbler check" to behave better, you 
might be able to get away by changing
http_bin and so forth in /var/lib/cobbler/settings.   Things like the 
http restart probably don't work though.
> (Importing distros (via rsync) has not been tested as I manage my
> distros through other methods, but offhand there isn't really any
> reason why this wouldn't work.)
>
> Why might this be useful?  Well I already have a set of scripts for
> managing my hosts infrastructure (DNS, NIS, DHCP) plus a tftp server
> for Solaris Kickstarts already in existance, and this lets me do
> everything from one server.
>
> So I can now say:
>
> # cobbler_byname --host tpx18 --profile RHEL-3ES-U6-i386-ws
>
> ...and it generates and runs the appropriate cobbler command for
> me, instead of me having to dig out the MAC and IP address for
> the system manually.

Re: Kickstart tracking in 0.3.6

Ok, kickstart tracking is implemented and pushed, so if anyone wants to 
play with this, please check out the Mercurial repository.   Just run a 
"cobbler sync" after the upgrade to get Apache configured correctly.   I 
probably won't release this (along with the rest of 0.3.6) until 
mid-next week.   Manpage docs have to be written first :)

In order to see when machines have truly finished, the kickstart files 
need to contain the following somewhere in post:
%post
TEMPLATE::kickstart_done

I have updated the default kickstarts that come with cobbler, so you can 
see what is done there.  

And then, at any time, one can run the following and see following for 
all distros in their system:

[root <at> mdehaan cobbler]# cobbler status
Address              | State           | Started                   | 
Last Request              | Seconds    | File Count
172.16.56.91         | notdone         | Thu Jan  4 16:23:16 2007  | Thu 
Jan  4 17:13:32 2007  | 3016       | 1422 

Individual status of files transferred is stored in 
/var/log/cobbler/kicklog/$IPADDR.   Right now, these files are not 
pruned, though in future versions I might decide to delete them if they 
haven't been modified in 30 days, or something like that.    This really 
shouldn't be a problem as the files won't be huge.

If you're using kickstart trees on another partition, you'll only see a 

Re: Cobbler on Solaris 9

On Thu, Jan 04, 2007 at 10:22:46AM -0500, Michael DeHaan wrote:

> Neat.   For things like getting "cobbler check" to behave better, you 
> might be able to get away by changing
> http_bin and so forth in /var/lib/cobbler/settings.   Things like the 
> http restart probably don't work though.

Service handling would either have to be abstracted in cobbler, or
dummied up on the sun to make it pretend to be more like a RedHat
system, neither of which is probably worth the effort it would take.

> Definitely, I'd like to see it.

Attached to this page:

  http://wiki.xdroop.com/space/RedHat/kickstart/Cobbler/cobbler_byname

--

-- 
 /\oo/\
/ /()\ \ David Mackintosh | 
         dave@...  | http://www.xdroop.com

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

Two other comments

In the process of looking at this, I had two other comments:

1.  It would be nice if there was a quiet mode for cobbler sync.
    Twelve distros generate a lot of noise.

2.  The "name" parameter should be a descriptive (possibly optional)
    field and the MAC address a separate parameter (which might possibly
    be plugged into the "name" field if the "name" field was not explicitly
    provided).

Specifically -- figuring out which "system" is my target when all you
have is a listing of MAC addresses is even more tedious than figuring
out what their MAC addresses were in the first place; ie:

[root <at> router /]$ cobbler list | grep system
system 1        : 00:11:43:cd:81:f8
system 2        : 00:04:23:0A:14:04
system 3        : 00:04:23:a6:a0:86
system 4        : 00:06:5B:B1:7D:7B
system 5        : 00:30:1B:AD:90:9B
system 6        : 00:d0:b7:7a:90:b0

The "name" should probably be a descriptive label and have the MAC
address as a separate parameter as so: 

# cobbler system add --name="tpx18" --mac=00:04:23:a6:a0:86 --profile=[...] --pxe-address=[...]

Of course if "name" was a hostname that was resolvable, that would make
putting in the functionality of cobbler_byname easy... :)

Re: Two other comments

David Mackintosh wrote:
> In the process of looking at this, I had two other comments:
>
> 1.  It would be nice if there was a quiet mode for cobbler sync.
>     Twelve distros generate a lot of noise.
>   
Believe it or not, it used to be louder.   Point taken.
> 2.  The "name" parameter should be a descriptive (possibly optional)
>     field and the MAC address a separate parameter (which might possibly
>     be plugged into the "name" field if the "name" field was not explicitly
>     provided).
>
> Specifically -- figuring out which "system" is my target when all you
> have is a listing of MAC addresses is even more tedious than figuring
> out what their MAC addresses were in the first place; ie:
>
> [root <at> router /]$ cobbler list | grep system
> system 1        : 00:11:43:cd:81:f8
> system 2        : 00:04:23:0A:14:04
> system 3        : 00:04:23:a6:a0:86
> system 4        : 00:06:5B:B1:7D:7B
> system 5        : 00:30:1B:AD:90:9B
> system 6        : 00:d0:b7:7a:90:b0
>
> The "name" should probably be a descriptive label and have the MAC
> address as a separate parameter as so: 
>
> # cobbler system add --name="tpx18" --mac=00:04:23:a6:a0:86 --profile=[...] --pxe-address=[...]
>   
Name is already in use in the field and can't change, though I 

RHEL4 Cobbler Setup

How might one import RHEL 4 into cobbler from the installation media.
Such that the installation can be completed over the network. I've got a
functional cobbler install already with several distributions.

Re: RHEL4 Cobbler Setup

Matt S Unix Administrator wrote:
> How might one import RHEL 4 into cobbler from the installation media.
> Such that the installation can be completed over the network. I've got a
> functional cobbler install already with several distributions.
>
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools@...
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>   
All you have to do is copy over the files from each CD into a directory 
somewhere on your cobbler server.  You'll want to preserve the directory 
layout that was on the CD.   

A good place to put this tree is 
/var/lib/cobbler/localmirror/rhel4$type$arch, though if you don't want 
to take up space in /var, you could just create a symlink to that point 
and put the files somewhere else.   (Note:  If not running Cobbler 
0.3.6, this would require manually configuring Apache to follow 
symlinks, 0.3.5 sets this up for you automatically).   The name 
"localmirror" is special, if you name it something else, cobbler will 
probably delete it for you, thinking it's content that shouldn't live in 
/var/lib/cobbler.

These files really don't have to be on the cobbler server, either.   In 
my setup, I just symlink a path to the kickstart trees that Red Hat 
stores on NFS shares, i.e. /mnt/foo/something/RHEL4/AS/tree.    Samba 
would technically work too if you are so inclined.

Re: RHEL4 Cobbler Setup

Michael DeHaan wrote:
> Matt S Unix Administrator wrote:
>> How might one import RHEL 4 into cobbler from the installation media.
>> Such that the installation can be completed over the network. I've got a
>> functional cobbler install already with several distributions.
>>
>>
>> _______________________________________________
>> et-mgmt-tools mailing list
>> et-mgmt-tools@...
>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>>   
> All you have to do is copy over the files from each CD into a 
> directory somewhere on your cobbler server.  You'll want to preserve 
> the directory layout that was on the CD.  
> A good place to put this tree is 
> /var/lib/cobbler/localmirror/rhel4$type$arch, though if you don't want 
> to take up space in /var, you could just create a symlink to that 
> point and put the files somewhere else.   (Note:  If not running 
> Cobbler 0.3.6, this would require manually configuring Apache to 
> follow symlinks, 0.3.5 sets this up for you automatically).   The name 
> "localmirror" is special, if you name it something else, cobbler will 
> probably delete it for you, thinking it's content that shouldn't live 
> in /var/lib/cobbler.
>
> These files really don't have to be on the cobbler server, either.   
> In my setup, I just symlink a path to the kickstart trees that Red Hat 
> stores on NFS shares, i.e. /mnt/foo/something/RHEL4/AS/tree.    Samba 
> would technically work too if you are so inclined.
>