Re: [Puppet Users] Re: Remove java from path - Windows
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% via the GUI, Windows will change it from REG_SZ to REG_EXPAND_SZ for you (and back again if you remove all the %variables%). I wonder if the windows_env puppet module should do that? I've done the %variable% in path before without issue and did a quick test before posting, but some further curiosity fueling googling suggests there may be gotchas that I was not previously aware of. To the OP: I'd be interested to hear if you have any such issues. Eric -- 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/46ffe10b-d5f3-4d01-ab1f-86208de831ee%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Remove java from path - Windows
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 7:16:56 AM UTC-5, Jeff Sparrow wrote: We are having an issue with some modules. They are adding the correct path, but they do not remove the old path: C:\Windows\system32path PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\IBM\RationalSDLC\common;;C:\Program Files (x86)\NTP\bin;C:\Program Files (x86)\Puppet Labs\Puppet\bin;C:\Program Files\Java\jdk1.7.0_50\bin;C:\PROGRA~1\apache-maven\bin;C:\Program Files\Java\jdk1.7.0_55\bin You can see that it added the correct path at the end, but the original version jdk1.7_50\bin still exists. How can we make sure that it removes the old version every time it installs a newer version? Edit: More importantly what we need to do is have it search for the JAVA_HOME path variable, compare that against Path variable, delete any java directory that doesnt belong, and copy the JAVA_HOME to Path. Hope that makes sense. -- 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ef140bb1-c61b-41f1-80c4-1f9bf017f838%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Composite namevars for custom Type
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
making changes to types.
Eric
On Saturday, January 25, 2014 10:20:46 PM UTC-6, Len wrote:
John,
Thanks for the link. What I think is happening, is that I am not
overloading the title_patterns function/method correctly. I've followed
some other examples I came across, including the one in the link. But it
does not seem to be picking up the def self.title_patterns from the custom
type. And I'm still learning ruby and the inner workings of puppet.
Len
On Saturday, January 25, 2014 12:08:18 PM UTC-5, Len wrote:
Jan 23
To all,
I am on puppet 2.7.3 and I'm working on a custom RabbitMQ type, that will
use composite namevar. I did not see any work out there already for
managing rabbitMQ bindings so I've started on one and I'm running into
problems with the composite namevar. I have a very basic type ( below ) but
when I run the puppet as an agent I still get the error Error 400 on
SERVER: Could not render to pson: you must specify title patterns when
there are two or more key attributes
Any help or pointers would be appreciated.
#Puppet Manifest:
rabbitmq_binding { 'testing':
source = src,
destination = dest,
}
# Puppet Type
Puppet::Type.newtype(:rabbitmq_binding) do
desc 'rabbitmq_binding creates a puppet type for managing rabbitMQ
binding'
def self.title_patterns
[ [
/^(.*):(.*)$/, # pattern to parse source:destination
[
[:source, lambda{|x| x} ],
[:destination, lambda{|x| x} ]
] ]
]
end
newparam( :source ) do
isnamevar
end
newparam( :destination ) do
isnamevar
end
end
--
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/e2d75037-3b6a-472a-8545-da94ed69a7dd%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: chocolatey, windows, powershell and fault bucket
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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Could not parse for environment production: Cannot assign to variables in other namespaces
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 Thursday, August 22, 2013 6:04:39 AM UTC-5, JeremyCampbell wrote:
We're trying to set a role variable in one of our role classes i.e.
class role::nameserver {
$::role = 'nameserver'
include profile::baseline
}
however we get the following error
Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not parse for environment production: Cannot assign to variables in
other namespaces
We do not get the error if we just use
$role = 'nameserver'
Does anyone understand what is causing this?
--
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 puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Freebsd + Puppet 3.2.2 pkg_add -f ?
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 others things regarding the patch (semi tangential): 1) If you do an install of puppet 3.2.3 from ports with ruby 1.9.3, you get piles of warnings during puppet runs due to some class variable use in the freebsd provider. This is fixed in vanilla puppet 3.2.3, but undone by the patch. 2) If the freebsd provider is broken, seems like it should be going back upstream rather than patching in the port (forgive my ignorance if this is in fact happening and the patch is interim). Eric On Monday, August 12, 2013 3:35:41 PM UTC-5, Russell Jackson wrote: The standard provider doesn't work with packages that have multiple origins (the apache ports for instance) because the package name doesn't match was is recorded in the package database. So, what will happen is that puppet will think the package isn't installed on every run and attempt to install it. The only sane way around that was to use the package origin as a key and duplicated the '-r' functionality in the provider; this is what the patch does. Passing '-f' to pkg_add was questionable, but I remember there being problems without it. -- 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 puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Freebsd + Puppet 3.2.2 pkg_add -f ?
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, apparently for ruby 1.8 compatibility. I got rid of the optpatch-package_origin file and reinstalled the port to get the proper package provider, which does indeed use '-r'. Eric -- 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 puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] serving .exe file via http (provider = windows)
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:/// sources though. Eric On Monday, August 5, 2013 3:42:28 AM UTC-5, cko wrote: Hi, from the official documentation: Additional Notes on Windows Packages - The source parameter is required, and must refer to a local .msi file, a file from a mapped drive, or a UNC path. You can distribute packages as file resources. Puppet URLs are not currently supported for the package type’s source attribute. This is why i want to serve the file via httpd (like i said, it worked with msi files). -- 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 puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: operatingsystemrelease fact on windows
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 -- 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 puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: operatingsystemrelease fact on windows
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 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 puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
