Thats Ironic that you would bring up cobbler import. I am of course biased in my perception, I wrote the rules for my personal cobbler needs, my company is deploying in an *very* secure environment with no access to the internet, so I am used to creating distros in cobbler only after manually porting in the repos (It took 4 blu-ray discs for all of f12, f13 and rhel5.5, phew).
The problem is of course a chicken and egg situation as well, I have puppet create a cobbler/puppetmaster vm on one secure deployment and then "carry" the vm to another isolated environment to bootstrap it, along with the Blu-Ray discs. Ironically, I have puppet bootstrap cobbler which can bootstrap puppet.... ahh recursion... For the first node, puppet bootstraps itself, I have a script which gets a basic puppet up and then puppet puppetizes itself. Any suggestions are of course always welcome, I figure I can look into expanding the functionality once I have the main puppet stuff built. On Mon, Jun 28, 2010 at 10:44 AM, Michael DeHaan <[email protected]>wrote: > That's awesome. Let us know when you get them posted. > > Normally I'd think about cobbler bootstrapping puppet, not the other > way around, but what I think is interesting about this, is that it > allows you to rapidly set up cobbler servers from a central puppet > server -- often cobbler servers are geographically seperated to make > for fast local mirrors. While cobbler does have text files for it's > configuration you could rsync and also check in, this way it's easier > to keep them with the configurations of other things you want to put > on those same servers. > > The one catch is things (side-effects) that "cobbler import" would do, > would not be done. That is, you couldn't rely on "cobbler import" > to make trees available, rather you'd want to mount your trees such > that they show up over NFS or http:// ... but other than that, I can > see that working pretty well. > > It's also kind of cool as you can now define the system before it > exists along with the definition of what it looks like after it > exists. > > TMTOWTDI and what all. > > --Michael > > On Mon, Jun 28, 2010 at 12:39 PM, Thomas S Hatch <[email protected]> > wrote: > > Thanks Michael. > > Just to cover my bases, I have fixed up these types and I will have > > the modified ones up soon, just in case anyone wants to use them. I will > > need to completely change my approach on these to speed them up and use > the > > xmlrpc. I am still working on them, it will just take a little while, > they > > are kind of big in scope :) > > -Tom Hatch > > > > On Tue, Jun 22, 2010 at 10:35 PM, Michael DeHaan < > [email protected]> > > wrote: > >> > >> If you have permission on web.ss in var/lib/cobbler you can read that > and > >> use it as the authentication token, that is how the CLI works, so yes, > no > >> Apache required! Read cli.py for details ... I think :) > >> > >> Sent from my iPad > >> On Jun 23, 2010, at 12:00 AM, Thomas S Hatch <[email protected]> > wrote: > >> > >> Yes, using the xmlrpc would be much more elegant, and probably faster. > I > >> cranked these out very quickly and I wanted to make them very simple to > >> start. I also wanted to build an interface that could easily take more > >> options in the future and simply iterate over the possible values, this > >> method has worked very well for my in other cobbler automation tasks, > all of > >> which have used the xmlrpc interface. > >> > >> Thanks for your positive response though, I was a little worried that > you > >> had started on cobbler types for puppet given your new position, > >> congratulations are of course in order! > >> > >> One quick question, the cli interface manages calls through xmlrpc, so > >> they don't seem to need to authenticate, I was wondering how this was > >> possible, I have not looked for it in the cobbler code yet. As I > understand > >> it apache acts as the authentication layer for the python based xmlrpc > >> server and runs proxy to the xmlrpc interface. I assume you can connect > >> directly to the xmlrpc interface from localhost? > >> > >> Thanks Michael, your work on cobbler has been a great benefit to my > work. > >> > >> On Tue, Jun 22, 2010 at 1:16 PM, Michael DeHaan > >> <[email protected]> wrote: > >>> > >>> Sweet! I think you should use the cobbler xmlrpc API ideally though; > but > >>> the CLI uses the same so that is still good. I will take a closer look > >>> later this week! > >>> > >>> -- Michael > >>> > >>> On Jun 22, 2010, at 1:15 PM, Thomas S Hatch <[email protected]> > wrote: > >>> > >>>> Here are my cobbler types, and they are my first puppet types(and my > >>>> ruby is still rather weak), so go easy on me... > >>>> > >>>> They still need better doc strings and descriptions, and there are a > few > >>>> more parameters I need to support. Also they could of course use more > >>>> testing, but what doesn't! > >>>> > >>>> Please tell me what you think. > >>>> > >>>> -Tom Hatch > >>>> -- > >>>> You received this message because you are subscribed to the Google > >>>> Groups "Puppet Developers" group. > >>>> To post to this group, send email to [email protected]. > >>>> To unsubscribe from this group, send email to > >>>> [email protected]<puppet-dev%[email protected]> > . > >>>> For more options, visit this group at > >>>> http://groups.google.com/group/puppet-dev?hl=en. > >>>> <cobbler_distro.rb> > >>>> <cobbler_nic.rb> > >>>> <cobbler_profile.rb> > >>>> <cobbler_repo.rb> > >>>> <cobbler_system.rb> > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "Puppet Developers" group. > >>> To post to this group, send email to [email protected]. > >>> To unsubscribe from this group, send email to > >>> [email protected]<puppet-dev%[email protected]> > . > >>> For more options, visit this group at > >>> http://groups.google.com/group/puppet-dev?hl=en. > >>> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Puppet Developers" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]<puppet-dev%[email protected]> > . > >> For more options, visit this group at > >> http://groups.google.com/group/puppet-dev?hl=en. > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Puppet Developers" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]<puppet-dev%[email protected]> > . > >> For more options, visit this group at > >> http://groups.google.com/group/puppet-dev?hl=en. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Developers" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<puppet-dev%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/puppet-dev?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<puppet-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
