On Mon, Jun 28, 2010 at 2:25 PM, Thomas S Hatch <[email protected]> wrote: > hmmmm.. . Right now I am managing snippets, kickstarts etc. with the file > type and have some nasty requires chains, I wonder if a cobbler type that > managed all of those would be a good idea, a type that would manage the > package, and then take lists of snippets kickstarts etc. Then the options > would be greatly compressed and the auto require would get rid of the nasty > require and notify params.
Seems like it could be... there could be a lot of snippets and kickstarts, and you'd have to keep editing Puppet when you edited Cobbler. I generally don't like having to do things in two places when you make changes. (Just adding it to source control could mean you could use the puppet-vcsrepo type though...) http://github.com/reductivelabs/puppet-vcsrepo That might be better than fileserving. > As for the import, I wonder if I can just make an option in distro, an > import => true, then the distro would be created based on the import data, > and then the distro params would verify when rechecked. Perhaps, yes, though keep in mind multiple distribution objects can be created by an import. For instance, a tree could be an entire NFS tree for multiple distributions, or you could have (for older distributions, not so much a problem anymore), "-xen" and not "-xen" kernel variants. I believe that doesn't happen with newer RHEL though, but I haven't been keeping up with the install tree structure lately. --Michael > > On Mon, Jun 28, 2010 at 12:02 PM, Michael DeHaan <[email protected]> > wrote: >> >> On Mon, Jun 28, 2010 at 1:56 PM, Thomas S Hatch <[email protected]> >> wrote: >> > 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 might want to make a rule that makes sure a directory is present >> and rsyncs it if not, and then seperately create the >> distros/profiles/manually. >> Making "import" test logic all replicated in Puppet would be pretty >> tricky. >> >> Another thing you might want to think about is if you're using any >> snippets (likely) or custom triggers (a little less likely?) >> that you'd want to make sure got moved over. I think replicate also does >> this. >> >> In either way, I think it would be like triggering rsyncs before >> running the "cobbler ____ add|edit" commands. >> >> >> > 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]. >> >> >> >>>> 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. >> >> >> > >> > -- >> > 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.
