Hi, I''m quite new to Puppet.. I''m wondering if someone could point me in the right direction regarding the best way to manage a temporary requirement within Puppet? The scenario is, every server in our estate of Debian machines requires some monitoring software which is not provided as a Debian package. So we have a Puppet class, monitor::install which we include to distribute the src code and do an unattended configure, make & make install. Obviously this requires the "make" & "gcc" packages. But, as standard, we do not want these packages to be installed any of the machines during normal operation once the install has taken place. How do people generally manage such transient requirements? -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 08/01/2011 06:40 AM, David wrote:> The scenario is, every server in our estate of Debian machines > requires some monitoring software which is not provided as a Debian > package. >You should make your own debian package(s) for the monitoring software instead of installing from source on every machine. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Yup. This is totally the right way to do that. If you don''t want to, I would suggest that you compile once, tar up the content, and just untar it on the machine. If you really, really want to go through installing the compiler, building, then removing it, you can: write your script to use apt to install the packages, build, and then uninstall again. Maybe specify ''package { "gcc": ensure => absent }'' so that puppet enforces. ...but, um, this really doesn''t add that much security to your system. Sending a binary, or a portable language tool, is not that hard for an attacker. daniel On Mon, Aug 1, 2011 at 09:17, vagn scott <vagnscott@gmail.com> wrote:> On 08/01/2011 06:40 AM, David wrote: >> >> The scenario is, every server in our estate of Debian machines >> requires some monitoring software which is not provided as a Debian >> package. >> > > You should make your own debian package(s) for the monitoring software > instead of installing from source on every machine. > > -- > 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+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Take a look at Jordan Sissel''s FPM software if you want a cheap way of making a deb. Ken. On Aug 1, 2011 7:10 PM, "Daniel Pittman" <daniel@puppetlabs.com> wrote:> Yup. This is totally the right way to do that. > > If you don''t want to, I would suggest that you compile once, tar up > the content, and just untar it on the machine. > > If you really, really want to go through installing the compiler, > building, then removing it, you can: write your script to use apt to > install the packages, build, and then uninstall again. Maybe specify > ''package { "gcc": ensure => absent }'' so that puppet enforces. > > ...but, um, this really doesn''t add that much security to your system. > Sending a binary, or a portable language tool, is not that hard for > an attacker. > > daniel > > On Mon, Aug 1, 2011 at 09:17, vagn scott <vagnscott@gmail.com> wrote: >> On 08/01/2011 06:40 AM, David wrote: >>> >>> The scenario is, every server in our estate of Debian machines >>> requires some monitoring software which is not provided as a Debian >>> package. >>> >> >> You should make your own debian package(s) for the monitoring software >> instead of installing from source on every machine. >> >> -- >> 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+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> >> > > > > -- > ⎋ Puppet Labs Developer – http://puppetlabs.com > ♲ Made with 100 percent post-consumer electrons > > -- > 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 topuppet-users+unsubscribe@googlegroups.com.> For more options, visit this group athttp://groups.google.com/group/puppet-users?hl=en.>-- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Thanks for the replies. I did start off down the route of distributing binaries but was having problems getting them to run on the different architectures involved and ended up with multiple packages - and every time I needed to tweak the build config I was having to rebuild multiple times. It was so much easier to build on each machine... I perceived the issue of removing gcc & make afterwards as being an easier problem to solve. I thought there may be a way to do it without having to drop down to scripting - but then again - the whole configure/make process is just a set of scripts so no difference I guess. Thanks again for the replies. On Aug 1, 7:09 pm, Daniel Pittman <dan...@puppetlabs.com> wrote:> Yup. This is totally the right way to do that. > > If you don''t want to, I would suggest that you compile once, tar up > the content, and just untar it on the machine. > > If you really, really want to go through installing the compiler, > building, then removing it, you can: write your script to use apt to > install the packages, build, and then uninstall again. Maybe specify > ''package { "gcc": ensure => absent }'' so that puppet enforces. > > ...but, um, this really doesn''t add that much security to your system. > Sending a binary, or a portable language tool, is not that hard for > an attacker. > > daniel > > > > > > > > > > On Mon, Aug 1, 2011 at 09:17, vagn scott <vagnsc...@gmail.com> wrote: > > On 08/01/2011 06:40 AM, David wrote: > > >> The scenario is, every server in our estate of Debian machines > >> requires some monitoring software which is not provided as a Debian > >> package. > > > You should make your own debian package(s) for the monitoring software > > instead of installing from source on every machine. > > > -- > > 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+unsubscribe@googlegroups.com. > > For more options, visit this group at > >http://groups.google.com/group/puppet-users?hl=en. > > -- > ⎋ Puppet Labs Developer –http://puppetlabs.com > ♲ Made with 100 percent post-consumer electrons-- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Reasonably Related Threads
- Different users within same exec
- err: Could not retrieve catalog from remote server: Could not intern from pson: Could not convert from pson: Could not find relationship target "File[]"
- finding consultants or full time puppet experts?
- Hash Interpolation inside double quotes?
- UX/UI of puppet help when face actions have unmet dependencies