[Puppet Users] Re: Arbitrary 3rd party installers
On Wednesday 21 October 2009 09:17:04 Andrew S wrote: > On Oct 21, 6:11 am, Luke Kanies wrote: > > The only real thing I can recommend is either 1) package the software > > yourself (by far the best option) or 2) use a defined type to do a > > wget, install, and rm of the tarball. Really, if you look at the > > Blastwave pkg-get script, that's pretty much what it does, so you'd be > > walking in the footsteps of giants or whatever. > > Right, the main issue with option 1) is that to do it properly it's a > lot of work to extracting out the behaviour of the installer script/ > binary/whatever, and there's no garauntee that I will pick up all the > changes or potential changes - e.g. a case statement that installs a > different library for different OS revisions. This is a lot of work > per package, and it's not garaunteed to be supported by the vendor > (who should have done this work themselves :/). I could just build a > pkg/rpm (we're a Solaris/Redhat shop) wrapper around the installer > itself, but that doesn't fit either of the frameworks correctly - the > package manifest will be the install files, which should be removed > from the system. I have seen one instance where an rpm wrapper is > used and the last thing it does in postinstall is uninstall itself. > Seems kludgy to me. Absolutely agree with that. I'm working on something like that for Progress OpenEdge and their installer will even install different things depending on what license/options you supply it with. A slight variation may be to build a wrapper package similar to the ones used for e.g. adobe flash, etc. That is, one which in itself contains no files, but when installed it downloads the installer and automates it. This still poses a problem in cases like Progress (i.e. different options, different result) but as long as you could work out a certain limited set of variations you could just build multiple packages from one spec file (each providing one set). > > Option 2) is what I was suggesting, but wanted to use a filebucket > rather than wget, but if that's not workable I'll stick with wget. I > was really hoping to be able to avoid having to have external > repositories of software though. You don't see any case for a > provider (exec or package) within puppet to meet this need? Two questions here. By using filebucket do you mean the internal puppet fileserver (with 'puppet://' URLs)? Also, a provider could be a good idea, but do you think it could be generic enough to support 3rd party installers? What's the behaviour of those you're using (e.g. any interactivity, batch mode, command line options, response files, etc.)? -- Michael Gliwinski Henderson Group Information Services 9-11 Hightown Avenue, Newtownabby, BT36 4RT Phone: 028 9034 3319 ** The information in this email is confidential and may be legally privileged. It is intended solely for the addressee and access to the email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients, any opinions or advice contained in this e-mail are subject to the terms and conditions expressed in the governing client engagement leter or contract. If you have received this email in error please notify supp...@henderson-group.com John Henderson (Holdings) Ltd Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT. Registered in Northern Ireland Registration Number NI010588 Vat No.: 814 6399 12 * --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Arbitrary 3rd party installers
Andrew S wrote: > Hi all, > > I've just started deploying a puppet infrastructure, and have run > across what I'm sure is a common problem - third party software that > does not use the systems package manager, instead using their own > script/binary blob/etc. Now my environment doesn't have any NFS at > present (and I'm loath to add it for just this one purpose), and > though I could wget the file and checksum it I'd prefer to manage all > configuration content through puppet and it's filebuckets. My first > cut at doing this was an exec that required a file resource for the > installer, however this means the install package remains on the > system. Is there some method or trick I'm missing here? > > If not, I'm considering writing a provider for package that would > source the installer from a filebucket and run it, and potentially > uninstall if the package has that option - problems with this approach > are of course where you put the installer (and having the space etc), > being sure that the third party provided installer is idempotent, and > checking that the software is installed. Would this be useful, or is > it foolishness? It's probably less foolish than my other plan, which > was to add source to exec. :) > > FWIW the software I'm looking at here is Netbackup, EMC Symcli and the > HP Proliant support pack. And potentially others. :/ > > Thanks, > Andrew. > > > > The Proliant Support Pack is available in RPM versions. Or at least I have it in RPM in my local repository, and I know I got it directly from HP. As to the others... if you have enough machines, it's definitely worth building a package for. Or maybe talk to someone from the vendor and see if you can convince them to provide RPMs... -Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Arbitrary 3rd party installers
On Oct 21, 6:11 am, Luke Kanies wrote: > The only real thing I can recommend is either 1) package the software > yourself (by far the best option) or 2) use a defined type to do a > wget, install, and rm of the tarball. Really, if you look at the > Blastwave pkg-get script, that's pretty much what it does, so you'd be > walking in the footsteps of giants or whatever. Right, the main issue with option 1) is that to do it properly it's a lot of work to extracting out the behaviour of the installer script/ binary/whatever, and there's no garauntee that I will pick up all the changes or potential changes - e.g. a case statement that installs a different library for different OS revisions. This is a lot of work per package, and it's not garaunteed to be supported by the vendor (who should have done this work themselves :/). I could just build a pkg/rpm (we're a Solaris/Redhat shop) wrapper around the installer itself, but that doesn't fit either of the frameworks correctly - the package manifest will be the install files, which should be removed from the system. I have seen one instance where an rpm wrapper is used and the last thing it does in postinstall is uninstall itself. Seems kludgy to me. Option 2) is what I was suggesting, but wanted to use a filebucket rather than wget, but if that's not workable I'll stick with wget. I was really hoping to be able to avoid having to have external repositories of software though. You don't see any case for a provider (exec or package) within puppet to meet this need? Thanks, Andrew Andrew. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Arbitrary 3rd party installers
On Oct 20, 2009, at 3:00 PM, Andrew S wrote: > > Hi all, > > I've just started deploying a puppet infrastructure, and have run > across what I'm sure is a common problem - third party software that > does not use the systems package manager, instead using their own > script/binary blob/etc. Now my environment doesn't have any NFS at > present (and I'm loath to add it for just this one purpose), and > though I could wget the file and checksum it I'd prefer to manage all > configuration content through puppet and it's filebuckets. My first > cut at doing this was an exec that required a file resource for the > installer, however this means the install package remains on the > system. Is there some method or trick I'm missing here? > > If not, I'm considering writing a provider for package that would > source the installer from a filebucket and run it, and potentially > uninstall if the package has that option - problems with this approach > are of course where you put the installer (and having the space etc), > being sure that the third party provided installer is idempotent, and > checking that the software is installed. Would this be useful, or is > it foolishness? It's probably less foolish than my other plan, which > was to add source to exec. :) > > FWIW the software I'm looking at here is Netbackup, EMC Symcli and the > HP Proliant support pack. And potentially others. :/ This is definitely a common problem, but AFAIK there's no real common solution. The only real thing I can recommend is either 1) package the software yourself (by far the best option) or 2) use a defined type to do a wget, install, and rm of the tarball. Really, if you look at the Blastwave pkg-get script, that's pretty much what it does, so you'd be walking in the footsteps of giants or whatever. -- The world tolerates conceit from those who are successful, but not from anybody else. -- John Blake - Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
