Yes, I looked at cobbler replicate, but often I will checkout an alternative puppet branch on the master to provision for an alternative deployment. And I guess, now that I recall, I went with declaring the distros directly because it was easier to automate, or at least I felt that it was.
I think I can make a cobbler_import puppet rule that would translate into enforcing the created resources, I think that would be pretty cool...... You are great for ideas about cobbler, I wonder why ;) As for security, I used to teach the RHCE track classes for Red Hat and I would rail on my students about security, then I got the job I have now, and security has taken on a whole new meaning I could never imagine, heck, I see systems without network access of any kind with the SELinux strict policy. Thanks Again Michael, good stuff to chew on, I will be back with some fresh puppet types in a few weeks! On Mon, Jun 28, 2010 at 11:31 AM, Michael DeHaan <[email protected]>wrote: > 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]<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]<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.
