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.
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. 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]<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]<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.
