On Mon, Jun 28, 2010 at 1:21 PM, Thomas S Hatch <[email protected]> wrote: > 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).
Cobbler import is used to running against local ISOs, so not sure where the security parts come in. It doesn't need the internet. (cobbler reposync can, however, mirror external repos -- which you might want to do). Though it's probably not a problem in the long run, "cobbler import" was written as an automation around rsync, "cobbler distro add", and "cobbler profile add", with some intelligence thrown in to know where to find the distros and how to name things. It's completely optional, but is the first place I told new users to go as it helps not having to explain install tree structure to them (as it's generally confusing). It sounds like your environment is definitely not one that needs "import", so you should be good to go. Generally the solution I invented for this, though is "cobbler replicate" in which you set up one cobbler master server and then replicate it out to other servers. It knows when to run the right rsync commands. What ends up working best is going to vary a lot, but that is generally pretty simple to set up too. > 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. My brain hurts now :) > Any suggestions are of course always welcome, I figure I can look into > expanding the functionality once I have the main puppet stuff built. I'd be a bit curious as to whether replicate would work better, or not. The idea of manipulating Cobbler via another API/system is not new, and I like the prospect of being able to "see" the configuration in version control as opposed to a text file, so I like this. In the very early days of Cobbler, I didn't discourage folks from editing things via Cobbler's own internal state for that kind of reason. Doing it the way you are doing is interesting because then you still get the validation magic that happens in the API to run, so it's an interesting merger of concepts. It allows you to have things in version control, and edit them with text editors (which is clearer than the command line in some ways), but also gets the validation and side effects. Cool! > 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]. >> >>>> 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]. >> >>> 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. >> >> >> >> -- >> >> 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. >> > >> > -- >> > 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. >> > >> >> -- >> 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. >> > > -- > 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. > -- 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.
