[et-mgmt-tools] Adding a distribution - where do I put the files?

Michael DeHaan mdehaan at redhat.com
Fri Feb 23 20:02:38 UTC 2007


Msquared wrote:
> On Fri, Feb 23, 2007 at 09:49:25AM -0500, Michael DeHaan wrote:
>
>   
>> And then, you can use the following parameter in your kickstart files 
>> for the "--url"
>>
>> url --url http://servername/cobbler_track/local_mirror/fc6tree/restofpath
>>     
>
> I was just about to ask about cobbler_track, but then I noticed that
> /etc/httpd/conf.d/cobbler.conf takes care of it.  Nice!
>
>   
>> Note that you want to include the full path to the "os" or "tree"
>> directory, and don't want to stop at the root.   That's what I mean by
>> "restofpath".
>>     
>
> So in the case of a Fedora DVD, which of the following should that be:
>
>   .../local_mirror/fc6/repodata
>   .../local_mirror/fc6/Fedora
>   .../local_mirror/fc6/Fedora/base
>   .../local_mirror/fc6/Fedora/RPMS
>
> ?
>
>   
Yeah, since you did the DVD import, paths are shorter here. My fault.

Just fc6, since that directory contains "repodata" and "images".

>> I think you've given an excellent reason to add "how to import a
>> kickstart tree from a DVD" to the manpage.
>>     
>
> I'd like the manpage to clarify that 'cobbler import --path' doesn't
> actually copy any files about.  Of course, in retrospect this makes sense
> to me, since you're importing from a location that is already locally
> accessible.  :-)
>   
That's been added.
> But at the time I was trying to understand all of this, I didn't know what
> to expect, and my brain was trying to fit everything into orthogonal
> little boxes, and assuming that import should unilaterally slurp from
> wherever it was given into its own local store made sense to me.
>
>   
>>>  cobbler import --mirror=root at localhost:/media/cdrom 
>>>  --mirror-name=testimport
>>>       
>>  
>> Actually that will work.   Creative workaround! :)
>>     
>
> I realised that might work from this info here:
>
>   http://cobbler.et.redhat.com/cobbler.html#repository_mirroring_workflow
>
> +1 for the manpage.  :)
>
> There was something I noticed after doing that import, though: the import
> process appeared to use the last component of the path I gave as a
> component in the path inside ks_mirror.
>
> After pondering it momentarily, I realised it's an rsync feature related
> to the trailing slash (or lack thereof, in this case).  Perhaps it's worth
> moentioning that 
>
>   cobbler import --mirror=root at localhost:/media/cdrom --mirror-name=fc6
>
> will copy the files into
>
>   /var/www/cobbler/ks_mirror/fc6/cdrom
>
> whereas
>
>   cobbler import --mirror=root at localhost:/media/cdrom/ --mirror-name=fc6
>
> will copy the files into
>
>   /var/www/cobbler/ks_mirror/fc6
>   

> Most likely, the second one is the one that is desired.  :)
>   

Yes, I can have the code ensure there's a trailing slash. If not, no 
major harm done, cobbler's smart enough to still make
everything work.

> Also, should I import root at localhost:/media/cdrom/ or
> root at localhost:/media/cdrom/restofpath/  (to refer to your --url example
> above) ?
>
>   
>>> However, will this cause me grief in future?  What happens when I
>>> 'cobbler sync'?  Will it try to re-mirror based on whatever is in
>>> /media/cdrom?  Can I stop it from doing that?
>>>       
>>  
>> Cobbler sync won't try to re-mirror that, because cobbler knows
>> kickstart trees really don't change.
>>     
>
> Oh yeah, that made me realise something: After running the import, I
> couldn't find anywhere in /var/lib/cobbler/* that referred to the files
> that were just imported,
>   
Other than the http:// paths in tree, that's true.
> However, after my rsync-slash discovery, I retried the import but with the
> trailing slash, and noticed that there was more information in the
> profile, this time!  Specifically:
>
>     ks_meta:
>         tree: 'http://provisioning//ks_mirror/fc6'
>   
Yes, you're one step ahead of me.
> Previously ks_meta was just {} (which means an empty list?)
>   
An empty dictionary, actually, but yes. The configuration files are YAML.
> I think that answers my question about how the provisioning knows about
> the files that were imported, but shouldn't that be:
>
>         tree: 'http://provisioning/cobbler/ks_mirror/fc6'
>
> ?
>
>   
If the string "cobbler" is missing from your DVD import, that's pretty 
darn weird and needs to be fixed.
>>> Also, should I make the mirror-name something that is related to where
>>> I'm getting the files from (eg: fc6dvd or fc6public), related to what
>>> the files are for (eg: fc6), or related to my provisioning server (eg:
>>> localprovserver; ie: the machine I am running cobbler on)?
>>>       
>>  
>> The mirror name is basically just to pick something you can remember
>> later.  
>>     
>
> I realise that, but if I have an idea of a convention that I could use, it
> may be easier to recall later.  :)  I'm sure those who have experience
> will have their own ideas, but it would be nice to have at least a
> suggestion for newbies.
>
> It's may be worth noting that the name you supply will be used by cobbler
> to build the name of a distro and a profile based on that import.
>
> Mind you, although it's easy to remember later that I called it 'fc6',
> it's a bit harder to remember that cobbler translated that into
> 'var_www_cobbler_ks_mirror_fc6_images_xen', so +1 for your auto-shorten
> idea.  :)
>   
>   
>> Since you've actually imported the profile, you're going to need to go
>> into /var/lib/cobbler/profiles to list the repos you use.  This isn't
>> really as scary as it sounds, but if you're concerned, you can back up
>> the profiles file first.
>>     
>
> Ah, so distros and repos are kind of independent?  By this I mean that
> cobbler doesn't intrinsically know what repo is related to what distro.
> You make that association as part of tweaking the profile, right?
>   
Yes, repos are a profile concept.

If there is a repo called "fancy_webserver_tools" we might only want to 
enable it for webserver profiles, for instance.
>   
>>> I've tried to import from the DVD with these, but none of them work:
>>>
>>>  cobbler import --mirror=root at localhost
>>>       
>> I thought you said you just got that working earlier?   Anyhow, import
>> also requires a "--mirror-name".
>>     
>
> Oops, sorry about that.  Email compose error.  :)  While I was composing
> the email, the very act of expressing the problem would sometimes suggest
> a possible solution, so I'd go ahead and play with it, and often it did
> help.  I was part-way through composing that when I discovered the ssh
> magic that allowed me to import the DVD and have cobbler retrieve a copy
> for itself.  I obviously didn't proof-read enough before I sent the email.
>
>   
>> The easiest way for this to happen is for you to write up something, put
>> it up on the web, and I can link it from the Cobbler webpage.
>>     
>
> Groovy.  I'll try to get some time this weekend to put up the sum total of
> what I have learnt thus far.
>
>   
>> As with the DVD import, folks using cobbler often think of things I
>> don't think of, and it's great to see what the things they want to do
>> with provisioning are.
>>     
>
> In this case, I want to set up a server for experimentation with various
> web CMS and blog technologies.  I decided that Xen would mean the ability
> to experiment endlessly and just rebuild when required, and cobbler/koan
> would even simplify the rebuild process.
>
> So far I have not been able to provision a Xen guest using the
> instructions at http://fedoraproject.org/wiki/FedoraXenQuickstartFC6
> (although part of the problem may be that I have not set up X, and thus
> virt-install is perhaps more fiddly than virt-manager).  I don't want X
> because I want a lean environment.
>
> The example given on that page using cobbler/koan looks like they
> copy/pasted from the cobbler manual, or something.  They didn't even give
> suitable example paths and data.  
They happens to be the author, in this case.

> At the very least I want to provide
> enough docs to make that bit work, but I'm happy to go much further.
>
>   
>> Yeah, repos are a relatively new concept, and are used for attaching
>> things like "fc6updatesi386" to a profile, so that they can
>> automatically install and configure a yum mirror when they provision it,
>> as well as using a yum mirror at install time to install packages.
>>     
>
> If I add an updates mirror to the profile, will updated packages be
> installed instead of the ones from the original DVD tree, where there are
> updates available?
>   
Yes.





More information about the et-mgmt-tools mailing list