+1
To manage an RPM not in yum, put it into yum.
> On Mar 2, 2017, at 11:02 AM, Garrett Honeycutt
> 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
We should note that yumrepo is a native type in puppet that you can use to
manage the remote repo information on nodes, and there's a (from memory)
palli/createrepo module to create and maintain the yum repo itself. It's
not that difficult to add createrepo to a role and set up a node as your
inter
For clarity, because I had to reread this twice to get the context: VERSION
CONTROL repositories should never contain binary objects.
Just want to differentiate that from yum repositories.
On Thu, Mar 2, 2017 at 2:11 PM Andrew Grimberg
wrote:
> Repositories should _never_ contain binary objects
This is pretty much exactly what module data is for. Check
out https://docs.puppet.com/puppet/4.9/lookup_quick_module.html for more
details.
On Friday, September 30, 2011 at 2:33:50 PM UTC-4, Jeff Falgout wrote:
>
> We're in the situation of dealing with multiple operating systems (and
> will
I got the same thing. When i ran "service pe-activemq start",i got..
INFO: Loading '/etc/sysconfig/pe-activemq'
INFO: Using java '/opt/puppet/lib/jvm/pe-java/jre/bin/java'
INFO: Starting - inspect logfiles specified in logging.properties and
log4j.properties to get details
INFO: changing to user
There are a number of reasons it's not a great idea to put them in the
module, but one is that if you start sticking binary artifacts into your
Puppet code, the size of the repos(s) will grow a lot and it will be much
slower to clone them. Also it's just not how people expect things to work.
Say y
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
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 pac
Repositories should _never_ contain binary objects. The only exception I
ever allow my developers is graphical assets related to websites.
On 03/02/2017 08:48 AM, warron.french wrote:
> Garrett, thanks.
>
> So, to clarify for myself in terms of a BEST practice are you declaring
> "don't deliver R
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
On 2/24/17 5:30 PM, Nate B wrote:
> // , Is there a better way to deal with this in later versions of Puppet?
>
> I lean toward using different manifests for different operating system
> variations, but like the original poster says, no matter how one
> organizes the logic, it still gets tedious
Awesome, thank you very much for your patience and tutoring me. I really
do appreciate it.
--
Warron French
On Wed, Mar 1, 2017 at 8:33 PM, Rob Nelson wrote:
> Yeah, a 'profile::base' that does nothing or just updates the motd if you
> want a very simple manifest woul
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 f
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
You can adjust the config_version value in puppet.conf (
https://docs.puppet.com/puppet/latest/configuration.html#configversion) to
spit out the git hash. See "Per-environment config_version" at
http://garylarizza.com/blog/2014/08/31/r10k-plus-directory-environments/
for some detail on it and an ex
I can not test the sqlserver module as I don’t have PE with a valid license at
hand right now.
Maybe you want to contact PE support:
https://puppet.com/support-services/customer-support?_ga=1.240191875.1487149708.1460034961
> On 02 Mar 2017, at 13:40, Ryan Vande wrote:
>
> It says to include in
It says to include in your manifest
"sqlserver_instance{ 'MSSQLSERVER':
features=> ['SQL'],
source => 'E:/',
sql_sysadmin_accounts => ['myuser'],
}
which I did , the error I got back was " Evaluation Error: Resource type
not found: Mssql_instance"
There is not type mssql_instance in the module:
https://forge.puppet.com/puppetlabs/sqlserver/types
Did you follow the setup description?
https://forge.puppet.com/puppetlabs/sqlserver/readme#setup
> On 02 Mar 2017, at 12:49, Ryan Vande wrote:
>
> Here is my puppet module list --all
> /etc/puppe
Here is my puppet module list --all
/etc/puppetlabs/code/environments/production/site
├── puppetlabs-ntp (v6.0.0)
├──* puppetlabs-sqlserver (v1.1.5)*
*└── puppetlabs-stdlib (v4.15.0)*
/etc/puppetlabs/code/environments/production/modules (no modules installed)
/etc/puppetlabs/code/modules (no module
Hi
I've recently been using puppet-agent-1.9.2 on an Ubuntu-14.04 machine
and whenever I run puppet agent I receive the following error:
Error: Facter: error while processing
"/opt/puppetlabs/facter/facts.d/packages.json" for external facts: The
document is empty.
The file it refers to is indeed
20 matches
Mail list logo
