Suresh Rajagopal writes:
> version is passed via hiera. params.pp has the logic to decide the
> package name based version. Is it a good practice to have this logic
> in params.pp ?
The philosophy I use in my own modules is that params.pp should provide
the best possible default based on the host
At work, I'm taking over primary administration of a puppet deployment
that had previously been maintained by a contractor. Shortly before he
left, it upgraded from PE 3.X to 2016.2.0, and moved from r10k to Code
Manager.
This has been running well, but "something happened" yesterday where
code d
Rob Nelson writes:
> J.T., is it possible that the shell Git was using a key on disk that
> was removed recently?
That's my working hypothesis. Just haven't escaped from a constant
stream of other interrupts in order to verify.
--jtc
--
You received this message because you are subscribed
Robert writes:
> Now there is just one question mark left*:
> - in some modules, under files, I store some bigger binaries (like
> apache-maven.tgz or a jdk-1.8.tar.gz) for which I'd like to use .
> gitignore files in order to leave these out of the repository, since
> they would consume storage s
I'm one of the admins of a site running PE 2016.4.2. Over the last
year, we've migrated from our own puppet module organization to the
roles and profiles pattern.
Currently, we're setting the parameters for modules that are shared
by more than one role/profile on a per-node basis. This has a draw
I'm running PE 2016.4.3 in my home lab. About 90 days ago, I installed
SSL certificates I generated via Let's Encrypt for my puppet server as
described @ https://docs.puppet.com/pe/2016.4/custom_console_cert.html.
With the cert expiration near, I re-generated my certs, updated the
public-console.c
Over the past year or so, we've completed a transition from locally
developed puppet modules containing node-specific configuration, to
using the roles/profiles pattern with parameterized modules with most
config values coming from hiera.
One exception to this are config files that are too specif
At work, we've written about 120 modules in our puppet code repository.
About two dozen are "interesting", in that they have lots of parameters
and configuration that is specific to our environment. The balance are
"boring", rather they are mostly boilerplate with minimal configuration.
For exampl
Before we started using puppet at work, we didn't have a systematic
process to install packages on our servers. As a result, we had servers
in the same "role" that (unintentionally) had different sets of packages
installed.
A very common case was that the 64 bit version of a library was
installed
Luke Bigum writes:
> In my mind the "purest" way would be to go individual modules for each
> package/service combination. If the only requirement is that you are
> handling the differences between Red Hat and Debian flavours, then a
> module per package/service. These modules would be wholly self
Rob Nelson writes:
> Silly question, but what package manager doesn't let you upgrade those
> two packages independently but also doesn't update the dependent
> packages at the same time?
We have this problem on CentOS machines using the yum provider. The logs
reported something to the effect of
11 matches
Mail list logo
