That was exactly what was confusing me. I had figured this out
shortly after sending the email...but I'm glad I didn't reply as I got
your structured facts answer which is good information to know.
Thanks...James
On Mon, May 11, 2015 at 10:01 AM, jcbollinger wrote:
>
>
> On Friday, May 8, 2015
I created a custom fact file to generate home_$user entries for all
users on the system containing their respective home directories:
require 'etc'
while pwEnt = Etc.getpwent do
name = pwEnt.name
home = pwEnt.dir
var = "home_#{name}"
Facter.add(var) do
OK, I understand now. Yeah, I'm in a place where I feel caution is
warranted all around. Ideal solution is to get the remi module
stating sane version requirements. I created that issue so maybe the
maintainer will respond. I would fix it for them if I could. If we
had our own local puppe
Yes but I told it to ignore the dependencies and install a certain
version. I would expect it would do just that. Have to agree to
disagree here.
I already figured out a work around.
As it happens the module really doesn't require that exact version,
but sadly its project URL links to the de
I am using puppet version 3.7.5. I tried to run the following command:
[root@dvcm puppetmaster]# puppet module install
--ignore-dependencies stahnma-epel --version 1.0.2
Notice: Preparing to install into /etc/puppet/modules ...
Notice: Downloading from https://forgeapi.puppetlabs.com ..
> It appears[1] that systemd should work without modification on FC19.
> James, what version of facter do you have? Most importantly does it have
> a fact for operatingsystemmajrelease?
It does:
[root@jefe ~]# facter | grep operatingsystemmajrelease
operatingsystemmajrelease => 19
Best..
; }
>
> This sets a resource default if the node in question uses the specified
> operating system.
>
> HTH,
> Felix
>
> On 03/13/2015 03:05 PM, James Olin Oden wrote:
>> I am on Fedora Core 19 using Puppet version 3.7.4.
>>
>> When I was trying ensure a s
I am on Fedora Core 19 using Puppet version 3.7.4.
When I was trying ensure a service was configured to start I would do
something like:
service { 'someservice':
ensure => 'running',
enable => true,
}
But when I would run puppet apply I would get the following error:
Erro
Never, mind I was looking in the wrong place. It's in the YAML spec
(or it's a YAML thing). Tilde represents NULL (or is equivalent
too):
http://www.yaml.org/spec/1.2/spec.html#id2805071
Thanks...James
On Wed, Feb 11, 2015 at 11:01 AM, James Olin Oden wrote:
> Hey Cl
Hey Clayton is this documented somewhere (i.e. the us of ~ like this,
or the use of ~ as a value in hiera file?). Thanks...James
On Wed, Feb 11, 2015 at 10:53 AM, Clayton O'Neill
wrote:
> In my experience using tilde as the value will pass through the equivalent
> of undef. That said, I agree
On Thu, Feb 5, 2015 at 9:52 AM, jcbollinger wrote:
>>
>> In particular I don't see where it is getting that Exec[re-read apache
>> config] requires Class[App::Apache] (which itself contains
>> Exec[re-read apache config]).
>
>
>
> That dependency arises from the Exec resource being declared by
>
I am getting a dependency loop when trying to apply my puppet
manifests, however the loop makes little sense to me as one the
dependencies seems to come from no where.
The cycle is this:
Augeas[Change production to development in virtual hosts] =>
Exec[re-read apache config] =>
Class[App
I think that is the answer. Probably when we go to Fedora 21
(because I'm lazy and don't want to rebuild or go past what is in the
Fedora repos) we probably see this feature come in. For now I've
hard coded the data, and left a note to fix it.
So ultimately this isn't a bug to be reported, it'
Cool I will look into. Concerning support, I got the idea to use it
from the hiera documentation:
https://docs.puppetlabs.com/hiera/1/variables.html#using-lookup-functions
And as I said with the hiera command line it worked:
$ hiera resolvconf::nameserver -c puppet.yaml ::site=corp
::ro
14 matches
Mail list logo
