Warron,
And if my previous email solves #1 & #2, then #3 is an addition of an exec
resource, then adding it at the end of the dependency chain:
[root@localhost myinstallmodule]# cat manifests/init.pp
class myinstallmodule {
exec { 'dothething':
command => 'echo "look it works!"; logger look it works',
path => '/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin',
}
package { 'mesecond':
ensure => present,
}
package { 'mefirst':
ensure => present,
}
Package['mefirst'] -> Package['mesecond'] -> Exec['dothething']
}
[root@localhost myinstallmodule]# puppet apply tests/init.pp --verbose
Notice: Compiled catalog for localhost in environment production in 0.28
seconds
Info: Applying configuration version '1488482217'
Notice: /Stage[main]/Myinstallmodule/Package[mefirst]/ensure: created
Notice: /Stage[main]/Myinstallmodule/Package[mesecond]/ensure: created
Notice: /Stage[main]/Myinstallmodule/Exec[dothething]/returns: executed
successfully
Notice: Finished catalog run in 4.37 seconds
[root@localhost myinstallmodule]# tail /var/log/messages
Mar 2 14:16:59 localhost yum[13827]: Installed: mefirst-1.0.0-1.el7.x86_64
Mar 2 14:17:01 localhost yum[13840]: Installed: mesecond-1.0.0-1.el7.x86_64
Mar 2 14:17:02 localhost vagrant: look it works
I hope this has been fruitful and must bow out as I don't have any more
spare-time to give to this list today, sorry.
Regards,
James
On Thu, Mar 2, 2017 at 2:12 PM, James Pryor <[email protected]> wrote:
> Warron,
> Correct. Garret is right. It is not best to deliver RPMs as part of the
> payload-contents of the Puppet Module, and do not store RPMs in a git repo
> (or whatever version control system you might be using).
>
> Yes, "yum localinstall" exists and but RPMs are best delivered via the
> OS's native packaging tools like yum (or dnf) for the Red Hat family of
> Linux distribution. Even if some independent software vendor creates and
> offers RPMs for their product, those RPMs should be placed in a yum repo
> either by the vendor hosting it, or by the sysadmin locally hosting it.
>
> I have a quick and dirty example of creating a Yum repo from a directory
> of RPMs, and then using yum command to install from that repo:
> https://gist.github.com/jjpryor/67b2a4822069f57e852c3cb71bc778
> e3#create-a-yum-repo-from-directory-of-rpms
>
> What that quick and dirty example does not contain is setting up HTTPS,
> and GPG key management, and GPG signing the RPMs so that authenticity and
> integrity can be guaranteed. Those steps are usually required in following
> RPM & YUM best practices for the greater internet.
>
> So the above should solve #1 from your numbered list in your opening email.
>
> If #1 is solved via a Yum repo, then #2 is solved like so:
> [root@localhost myinstallmodule]# puppet --version
> 3.6.2
> root@localhost myinstallmodule]# tree
> .
> |-- manifests
> | `-- init.pp
> |-- metadata.json
> |-- Rakefile
> |-- README.md
> |-- spec
> | |-- classes
> | | `-- init_spec.rb
> | `-- spec_helper.rb
> `-- tests
> `-- init.pp
>
> 4 directories, 7 files
> [root@localhost myinstallmodule]# cat manifests/init.pp
> class myinstallmodule {
> package { 'mesecond':
> ensure => present,
> }
> package { 'mefirst':
> ensure => present,
> }
> Package['mefirst'] -> Package['mesecond']
> }
> [root@localhost myinstallmodule]# cat tests/init.pp
> include myinstallmodule
> [root@localhost myinstallmodule]# puppet apply tests/init.pp
> Notice: Compiled catalog for localhost in environment production in 0.26
> seconds
> Notice: /Stage[main]/Myinstallmodule/Package[mefirst]/ensure: created
> Notice: /Stage[main]/Myinstallmodule/Package[mesecond]/ensure: created
> Notice: Finished catalog run in 4.76 seconds
>
>
> I hope this helps.
>
> James
>
> On Thu, Mar 2, 2017 at 11:48 AM, warron.french <[email protected]>
> wrote:
>
>> Garrett, thanks.
>>
>> So, to clarify for myself in terms of a BEST practice are you declaring
>> "don't deliver RPMs as part of the payload of the Puppet Module?" *I
>> just got that part working. :-/* I don't mind correction, but I don't
>> want to go down the rabbit hole.
>>
>> Secondly, using an exec resource to implement the RPMs?
>>
>> Perhaps something like this...
>>
>> exec { 'install_cctk_rpms':
>> creates => '/opt/dell/dcc/cctk',
>> command => 'yum localinstall -y A.rpm B.rpm',
>> returns => '0',
>> }
>>
>> I have never written an exec resource declaration before. Can you tell
>> me if the exec syntax is correct, and that it is also what you meant for
>> having to commands; I can combine them into a single *yum localinstall
>> -y *command correct?
>>
>> Thanks Garrett.
>>
>>
>> --------------------------
>> Warron French
>>
>>
>> On Thu, Mar 2, 2017 at 11:02 AM, Garrett Honeycutt <
>> [email protected]> wrote:
>>
>>> On 3/2/17 9:58 AM, warron.french wrote:
>>> > Hello all,
>>> > can someone please advise me on a proper set of syntax (a file to look
>>> > at) for an example to follow to solve the following challenge:
>>> >
>>> > 1. I have 2 deliver 2 *.rpm files that are not in a YUM repository, so
>>> > I dropped them into the files directory of my module path.
>>> > 2. I need to be able to execute each of them either together, or
>>> > _A.rpm before B.rpm_
>>> > 3. __Then execute a shell script that requires the 2 RPMs to be in
>>> > place before that happens.
>>> >
>>> > I am starting to get into slightly more complicated modules, instead of
>>> > simply delivering basic ASCII text files using *content =>
>>> > template('modulename/some.erb')*.
>>> >
>>> > I just need an example that is know to provide proper execution, proper
>>> > syntax, and something I can learn from correctly. I am still building
>>> > the foundation of my understanding, so troubleshooting someone else's
>>> > code isn't going to be too good for my development yet.
>>> >
>>> >
>>> > Thank you in advance,
>>> > --------------------------
>>> > Warron French
>>> >
>>>
>>> Hi Warron,
>>>
>>> What you want to accomplish is a bad idea and you should use a yum repo
>>> and definitely not check in binary data with your modules. You could at
>>> least store the rpm's somewhere and then download them from that
>>> canonical source. Take a look at Artifactory which can help with where
>>> to store things such as your random rpm's.
>>>
>>> Sometimes you have to automate what you have before you build something
>>> better. Suggest writing an exec resource that can handle what you are
>>> trying to do. The key here is to have two commands. One that checks to
>>> see if you are already in the desired state and another to get you to
>>> the desired state. Figure that out without Puppet and once you have
>>> those commands, you can write a manifest.
>>>
>>> Best regards,
>>> -g
>>>
>>> --
>>> Garrett Honeycutt
>>> @learnpuppet
>>> Puppet Training with LearnPuppet.com
>>> Mobile: +1.206.414.8658
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Puppet Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/puppet-users/4fc045bb-3e5f-f9d4-88a6-688ca3e3436b%40garr
>>> etthoneycutt.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/puppet-users/CAJdJdQkCQJ%2BXE2th_OLyu7%2BZyJDROfyht9UC9
>> 06_JXRn%3D0Q7Dg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/puppet-users/CAJdJdQkCQJ%2BXE2th_OLyu7%2BZyJDROfyht9UC906_JXRn%3D0Q7Dg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAOsPUcjNyB3M7cPXgTN2BGxCtUL%3DN2PxPRJQyAECB4dyB%3D37HA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
