On Monday, August 18, 2014 10:51:35 AM UTC-5, Rob Reynolds wrote:
This works great as long as the registry key is of type REG_EXPAND_SZ[1]
value, but the key for Path[2] is set to REG_SZ.
Interesting; all the systems I looked at were REG_EXPAND_SZ. It looks like
if you insert a %variable%
Hi Jeff,
You can reference other variables directly from within the PATH variable,
like so:
PATH=C:\other\stuff;%JAVA_HOME%;C:\more\other\stuff
That way you can maintain just the JAVA_HOME variable and path will be
updated automatically when it changes.
Eric
On Thursday, August 14, 2014
Len,
I tried out your code, and it looks good (the resource in the puppet
manifest doesn't conform to the title pattern format, which causes a
different error, but the title_patterns method itself is being recognized).
I'd try restarting the puppetmaster. I've found this to be necessary when
I opened a ticket about this a few days ago:
http://projects.puppetlabs.com/issues/22258
(Doing a bit of reading/poking at code, but so far everything I know is on
the ticket)
Eric
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To
Take a look at the last paragraph here:
http://docs.puppetlabs.com/puppet/3/reference/lang_variables.html#assignment
$role = 'nameserver'
assigns a variable within the 'role::nameserver' namespace (allowed), while
$::role = 'nameserver'
assigns a top level variable (not allowed).
Eric
On
I should disclaim that I'm not a huge FreeBSD guy, but do have a couple of
FreeBSD boxes around. I've been content getting all packages with 'pkg_add
-r' (which seems to work fine with the unpatched freebsd provider); no idea
about the interactions with ports you've mentioned.
Couple of
Did you install puppet from ports? I did a 3.2.3 install recently and
noticed that there is a
patchhttp://svnweb.freebsd.org/ports/head/sysutils/puppet/files/optpatch-package_origin?revision=311088view=markupin
that port that reverts back to an older version of the freebsd package
provider,
Installing from a URL is a feature of msiexec rather than the puppet
provider. I think you're stuck using a file resource to download the .exe
and then installing from a local path (or serving directly from a UNC
path). It would be neat if the windows package provider could eat
puppet:///
Luis,
This seems useful. I've never actually used any of the facts that return
the numeric Windows version, but have used the named version (with my own
fact). Since it looks like this piece of information is repeated in 3
facts, changing one to someone else seems like a good move.
Eric
--
Luis,
This seems useful. I've never actually used any of the facts that return
the numeric Windows version, but have used the named version (with my own
fact). Since it looks like the numeric version is repeated in 3 facts,
changing one to something else seems like a good move.
Eric
--
You
10 matches
Mail list logo
