Re: [Puppet Users] Manage /etc/fstab option with Puppet and Augeas
Thanks to both posters, but I decided against using the native mount type.
In part I wanted a bit of practice with Augeas and as Christopher wrote,
remounting is not safe.
Well, I stuck with my module and ended up with something that is not the
prettiest piece of code, but does the trick. No auto-remounts though!
define glusterfs::mount (
$server = ,
$volume = ,
$peers = ,
$mountpoint = /mnt/gluster,
$dump = 0,
$pass = 0,
$description = GlusterFS mount,
)
{
###
# native augeas nodes for fstab + input variables
# spec = $server:/$volume
# file = $mountpoint
# vmfstype = glusterfs
# opt = defaults,transport=tcp,backup-volfile-servers=$peers
# dump = 0
# passno = 0
###
# install augeas package as dependency for everything
package { 'augeas':
ensure = present,
provider = yum
}
# create mountpoint
file { $mountpoint:
ensure = directory,
owner = root,
group = root,
mode= '0755',
}
# fstab
augeas { gluster-fstab-add:
context = /files/etc/fstab,
changes = [
set #comment[last()+1] '$description',
set 01/spec '$server:/$volume',
set 01/file '$mountpoint',
set 01/vfstype 'glusterfs',
set 01/opt[1] 'defaults',
set 01/opt[2] 'transport',
set 01/opt[2]/value 'tcp',
set 01/opt[3] '_netdev',
set 01/opt[4] 'backup-volfile-servers',
set 01/opt[4]/value '$peers',
set 01/dump '$dump',
set 01/passno '$pass',
],
onlyif = [
match *[file = '$mountpoint'] size == 0,
]
}
augeas { gluster-fstab-set-peers:
context = /files/etc/fstab,
changes = [
set *[spec = '$server:/$volume'][file = '$mountpoint'][vfstype =
'glusterfs']/opt[. = 'backup-volfile-servers']/value '$peers',
],
}
augeas { gluster-fstab-add-peers:
context = /files/etc/fstab,
changes = [
ins opt after *[spec = '$server:/$volume'][file = '$mountpoint'][vfstype =
'glusterfs'][count(opt[. = 'backup-volfile-servers']) = 0]/opt[last()],
set *[spec = '$server:/$volume'][file = '$mountpoint'][vfstype =
'glusterfs'][count(opt[. = 'backup-volfile-servers']) = 0]/opt[last()]
backup-volfile-servers,
set *[spec = '$server:/$volume'][file = '$mountpoint'][vfstype =
'glusterfs'][count(opt[. = 'backup-volfile-servers']) =
1]/opt[last()]/value '$peers',
],
onlyif = [
match *[spec = '$server:/$volume'][file = '$mountpoint'][vfstype =
'glusterfs'][opt = 'backup-volfile-servers'] size == 0,
]
}
augeas { gluster-fstab-set-transport:
context = /files/etc/fstab,
changes = [
set *[spec = '$server:/$volume'][file = '$mountpoint'][vfstype =
'glusterfs']/opt[. = 'transport']/value 'tcp',
],
}
augeas { gluster-fstab-add-transport:
context = /files/etc/fstab,
changes = [
ins opt after *[spec = '$server:/$volume'][file = '$mountpoint'][vfstype =
'glusterfs'][count(opt[. = 'transport']) = 0]/opt[last()],
set *[spec = '$server:/$volume'][file = '$mountpoint'][vfstype =
'glusterfs'][count(opt[. = 'transport']) = 0]/opt[last()] transport,
set *[spec = '$server:/$volume'][file = '$mountpoint'][vfstype =
'glusterfs'][count(opt[. = 'transport']) = 1]/opt[last()]/value 'tcp',
],
onlyif = [
match *[spec = '$server:/$volume'][file = '$mountpoint'][vfstype =
'glusterfs'][opt = 'transport'] size == 0,
]
}
}
--
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/04255de6-2dd4-4ac3-9ee8-9b4f46c9879c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Managing multiple files in a directory - permissions issue
On 07 Apr 2015, at 04:55, Dave Hunsinger dhuns...@calliduscloud.com wrote:
Can somebody help me with what I'm doing wrong here? I want to copy all
sshkeys in the file resource of this puppet module to the machine:
class sshkeys {
file { '/etc/ssh/ssh.keys':
ensure = directory,
owner = 'root',
group = 'root',
source = puppet:///sshkeys,
recurse = true,
purge = true,
}
}
You need to change the source:
source = ‘puppet:///modules/sshkeys',
Info: Applying configuration version '1428375139'
Error: /Stage[main]/Sshkeys/File[/etc/ssh/ssh.keys]: Failed to generate
additional resources using 'eval_generate': Error 400 on SERVER: Not
authorized to call search on /file_metadata/development/sshkeys with
{:links=manage, :recurse=true, :checksum_type=md5}
Error: /Stage[main]/Sshkeys/File[/etc/ssh/ssh.keys]: Could not evaluate:
Could not retrieve file metadata for puppet:///development/sshkeys: Error 400
on SERVER: Not authorized to call find on /file_metadata/development/sshkeys
with {:links=manage, :source_permissions=use}
Wrapped exception:
Error 400 on SERVER: Not authorized to call find on
/file_metadata/development/sshkeys with {:links=manage,
:source_permissions=use}
Notice: Finished catalog run in 1.15 seconds
[root@lfmx-lin-stg01 daveh]#
CallidusCloud HQ has moved.
Our new address is:
4140 Dublin Blvd, Suite 400, Dublin, CA 94568
--
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/68fbbb6c-b0a1-4319-94a2-48e47e2247aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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/38B69EAB-3FB9-42CF-888D-2EE141E22606%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] developing module for k5login
On 06 Apr 2015, at 17:35, Dhaval d.josh...@gmail.com wrote: hello, I am trying to develop puppet module for k5login entries .. now my question is, how do i manage entries for multiple hierarchies ? currently when i try it, it picks up from where it finds entry first and completes it, how do i get values so it creates an array from all hierachies and then populates the k5login? i tried deeper merging and hiera_array, still not sure why it's not working. anything special i need to do ? Hi Dhaval, it would be great if you can post the puppet code and your hiera data. Otherwise people have to guess. Best, Martin -- 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/A14F2C7F-6504-4D60-81D8-D93608D82D4F%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] developing module for k5login
Hello, this is what it looks.
init.pp
class k5login(
$principles = hiera_array('k5login::principles', [])
){
validate_array($principles)
file { '.k5login':
ensure = file,
path= '/root/.k5login',
owner = 'root',
group = 'root',
mode= '0644',
content = template('k5login/k5login.erb'),
}
}
Hierarchies:
:hierarchy:
- hosts/%{hostname}
- environments/%{::environment}
- regions/%{datacenter}
- global
global.yaml
k5login::principles:
- user1/r...@example.com
- user2/r...@example.com
environments/development.yaml
k5login::principles:
- us...@example.com
Now when i do puppet run, i get user3 in k5login, what i want is user1,
user2, and user2 all.
Regards,
D
On Tuesday, 7 April 2015 12:46:54 UTC+5:30, Martin Alfke wrote:
On 06 Apr 2015, at 17:35, Dhaval d.jo...@gmail.com javascript: wrote:
hello,
I am trying to develop puppet module for k5login entries .. now my
question is, how do i manage entries for multiple hierarchies ?
currently when i try it, it picks up from where it finds entry first and
completes it, how do i get values so it creates an array from all
hierachies and then populates the k5login?
i tried deeper merging and hiera_array, still not sure why it's not
working. anything special i need to do ?
Hi Dhaval,
it would be great if you can post the puppet code and your hiera data.
Otherwise people have to guess.
Best,
Martin
--
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/518957b5-0b9b-4df5-aff1-436c1a844224%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Hiera with Redis
Hello, how do i add below to redis ? sudo::configs: 'admins': 'content' : %admins ALL=(ALL) NOPASSWD: ALL 'priority' : 10 I tried couple of things but not sure how to add array of hashes. Regards, D -- 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/d24dc113-683c-4de0-82c1-0e0d95817f74%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] collector in class with same name as tag causes all virtual resources of the type to be realized
Hello
I'm upgrading from 3.6 to 3.7 and have it a issue/bug
I'm using users/groups but to keep it short and something others can run
without the mess of users being made I've made up a file example
== modules/filegroups/manifests/matches.pp ===
class filegroups::matches {
include files
Files::Afile | tag == matches |
}
== modules/files/manifests/afile.pp ===
define files::afile {
file { $title: ensure=present, content='hello', }
}
== modules/files/manifests/data.pp ===
class files::data {
@files::afile { '/tmp/meanttobemade': tag=['matches'], }
@files::afile { '/tmp/notmeanttobemade': tag=['doesnotmatch'], }
}
== modules/files/manifests/init.pp ===
class files {
include files::data
}
== site.pp ===
node default {
include filegroups::matches
}
makes both files
Notice:
/Stage[main]/Files::Data/Files::Afile[/tmp/notmeanttobemade]/File[/tmp/notmeanttobemade]/ensure:
created
If I rename modules/filegroups/manifests/matches.pp
to modules/filegroups/manifests/iwantmatches.pp (and change the first line)
or rename the tag I get the desired behaviour
Anyone else seen this? Is this a bug?
There is a matching old question at askpuppetlabs
https://ask.puppetlabs.com/question/14349/upgrade-to-371-causes-resource-collectors-to-realize-everything/
that I've chipped in on the end off
Thanks,
Neil
--
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/CAAohVBe750Dk8Hc207TsGiNFZeU2kTyE1SR5XrO7-bgCJHFiEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Dependency problem for Puppet yum package
On Monday, April 6, 2015 at 12:05:09 PM UTC-5, staceyt...@gmail.com wrote:
Hi all,
I am trying to use puppet to downgrade my gdm package from 64 to 39, but
got package dependency problem:
Here is my class:
class gdmver39 {
yumrepo { 'custom':
baseurl = 'file:/home/admin/REPO/WS6.4',
enabled = 1,
}
package { gdm-libs: ensure = '2.30.4-39.el6', require =
Yumrepo[custom] }
package { gdm-plugin-fingerprint: ensure = '2.30.4-39.el6', require
= Yumrepo[custom] }
package { gdm: ensure = '2.30.4-39.el6', require = Yumrepo[custom]
}
}
I think myabe i should add the parameter below to my 'gdm' line'?
require Package['gdm-libs', 'gdm-plugin-fingerprint']
How to tell puppet to handle the dependency automatically?
Supposing that you have RPM dependencies requiring exact version-release
matches among those packages, it is unlikely that you can perform such a
downgrade via those Package resources alone. Puppet operates by
transitioning one resource at a time from its initial state to its final
state, and none of those packages can be transitioned independently, in
one step, from its current release to an earlier one. Even to do it
manually you would need either to remove some of those packages first, and
then later install the desired version, or else use the yum shell to set up
the whole thing as one transaction.
If there is only one release (i.e. 64) from which you wanted to downgrade,
then it would be easier, but your class naming leads me to think that you
want to downgrade from *any* later release that might be installed. That's
going to require you to determine exactly which version and release is
installed prior to each run. A custom fact would serve that purpose.
Supposing you created such a custom fact as $::gdm_version_release, you
should then be able to do this:
class gdmver39 {
yumrepo { 'custom':
baseurl = 'file:/home/admin/REPO/WS6.4',
enabled = 1,
}
if $::gdm_version_release and (versioncmp($::gdm_version_release,
'2.30.4-39.el6') 0) {
package { gdm-${::gdm_version_release}: ensure = 'purged', before =
Package['gdm-libs'] }
}
package { gdm-libs: ensure = '2.30.4-39.el6', require = Yumrepo[
custom] }
package { gdm: ensure = '2.30.4-39.el6', require = Package['gdm-libs']
}
package { gdm-plugin-fingerprint: ensure = '2.30.4-39.el6', require =
Package['gdm'] }
}
BE WARNED: ensuring a yum package 'purged' will remove not only that
package, but also any others that depend on it. In this case that
intentionally includes gdm-plugin-fingerprint, but if I ran that on one of
my systems it would also remove about three other packages as well. The
gdm and gdm-plugin-fingerprint would later be reinstalled, but nothing I
presented ensures the same for the others.
If you want to avoid the mess surrounding package purging (as most sane
people would), then you could replace it with an Exec that uses 'yum shell'
to perform the downgrade. That's messier in Puppet, but cleaner with
respect to package management. You'll want to work out the details for
yourself to ensure they are right for your environment, but you would
probably want to redirect a series of commands similar to this into yum
shell:
downgrade gdm-2.30.4-39.el6
downgrade gdm-libs-2.30.4-39.el6
downgrade gdm-plugin-fingerprint-2.30.4-39.el6
ts run
In Puppet, such an Exec should be set up to require the appropriate repo.
When it is needed, it may be used either instead of or before the package
resources.
Note also that if you're not actually using fingerprint readers with any of
these systems, and don't anticipate wanting to do so in the foreseeable
future, then you could make this issue a little simpler by ensuring
yum-plugin-fingerprint 'absent'. I know it's installed by default in EL6,
but most sites don't need it. Personally, I avoid ever installing it in
the first place.
John
--
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/b593ffac-14bc-45bc-a009-d5810070056d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Puppet module testing
Is there a definitive guide somewhere that would guide me as to how to write Puppet module tests? In particular I'm interested in learning how to write a tasklist file. I keep seeing mention of such but nothing that helps... -- 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/CAArvnv3ZReYbJFNB29hOhFYhk7fRKP%3DhrY-ViFesBC%3DRAiyy%3DA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Hiera variable interpolation on extra backend
Hi
I have the hiera_yamlgpg backend up and running working like a charm with
the following configuration:
:yamlgpg:
:datadir: /etc/puppet/environments/%{::environment}/hieradata
:key_dir: /etc/puppet/keys # optional, defaults to ~/.gnupg
:fail_on_error: true # optional, defaults to false
By business requirements I have been asked to use one or another private
key depending a custom fact. So my hiera.yaml configuration file looks like
this:
:yamlgpg:
:datadir: /etc/puppet/environments/%{::environment}/hieradata
:key_dir: /etc/puppet/keys/%{::custom_fact} # optional, defaults to
~/.gnupg
:fail_on_error: true # optional, defaults to false
The problem I am facing is that hiera is not interpolating the
%{::custom_fact} on the :key_dir: line. The error I get is:
WARN: Tue Apr 07 15:41:17 +0200 2015: No usable keys found in
/etc/puppet/keys/%{::custom_fact}/. Check :key_dir value in hiera.yaml is
correct
/etc/puppet/environments/production/modules/hiera_yamlgpg/lib/hiera/backend/yamlgpg_backend.rb:102:in
`decrypt_ciphertext': No usable keys found in
/etc/puppet/keys/%{::custom_fact}/. Check :key_dir value in hiera.yaml is
correct (Hiera::Backend::YamlgpgError)
Puppetlabs' documentation [1] says You can also interpolate variables
into other settings, such as :datadir (in the YAML and JSON backends):
which makes sense with the behavior I am getting (Sadly, it doesn't says
anything about other variables :():
* The %{::environment} variable on :datadir: line is interpolated
* But %{::custom_fact} on :key_dir: is not.
Any Idea how to workaround this?
[1] http://docs.puppetlabs.com/hiera/1/variables.html#in-other-settings
Thank you for your time
Best regards
--
Juan Sierra Pons j...@elsotanillo.net
Linux User Registered: #257202
Web: http://www.elsotanillo.net Git: http://www.github.com/juasiepo
GPG key = 0xA110F4FE
Key Fingerprint = DF53 7415 0936 244E 9B00 6E66 E934 3406 A110 F4FE
--
--
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/2f05482d-1452-4f05-aeee-d524d05d7e9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Sort by IP in ERB (related to puppetlabs-haproxy and MODULES-1919)
The puppetlabs-haproxy module has a minor annoyance where by the
bind statements are sorted lexicographically instead of by IP
address. (Full description here:
https://tickets.puppetlabs.com/browse/MODULES-1919)
My attempt to fix this bug was to change the ERB template:
diff --git a/templates/fragments/_bind.erb b/templates/fragments/_bind.erb
index e60983a..a04d021 100644
--- a/templates/fragments/_bind.erb
+++ b/templates/fragments/_bind.erb
@@ -1,6 +1,6 @@
% require 'ipaddr' -%
%- if @bind -%
-%- @bind.sort.map do |address_port, bind_params| -%
+%- @bind.sort_by { |address_port, bind_params|
address_port.split('.').map{ |octet| octet.to_i} }.map do
|address_port, bind_params| -%
bind %= address_port -% %= Array(bind_params).join( ) %
%- end -%
%- else -%
This works. However, the results are slightly different on old
versions of Ruby. If you look at the TravisCI output, you'll see
slightly different results for Ruby 1.8.7. It looks like something
changed in Ruby 1.9.
https://travis-ci.org/puppetlabs/puppetlabs-haproxy/builds/57502529
I don't have a lot of deep Ruby knowledge. Can anyone suggest either a
way to fix the code or the test?
Thanks!
Tom
--
Email: t...@whatexit.orgWork: tlimonce...@stackoverflow.com
Skype: YesThatTom
Blog: http://EverythingSysadmin.com
--
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/CAHVFxgkUrMMV%3DcvSD69Z-%3DVbK%3Dd1pHnu8QK37uLAOpZ%3DJb53_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] developing module for k5login
i changed variable name and it worked now.
On Tuesday, 7 April 2015 15:46:54 UTC+5:45, Dhaval wrote:
Hello, this is what it looks.
init.pp
class k5login(
$principles = hiera_array('k5login::principles', [])
){
validate_array($principles)
file { '.k5login':
ensure = file,
path= '/root/.k5login',
owner = 'root',
group = 'root',
mode= '0644',
content = template('k5login/k5login.erb'),
}
}
Hierarchies:
:hierarchy:
- hosts/%{hostname}
- environments/%{::environment}
- regions/%{datacenter}
- global
global.yaml
k5login::principles:
- user1/r...@example.com
- user2/r...@example.com
environments/development.yaml
k5login::principles:
- us...@example.com
Now when i do puppet run, i get user3 in k5login, what i want is user1,
user2, and user2 all.
Regards,
D
On Tuesday, 7 April 2015 12:46:54 UTC+5:30, Martin Alfke wrote:
On 06 Apr 2015, at 17:35, Dhaval d.jo...@gmail.com wrote:
hello,
I am trying to develop puppet module for k5login entries .. now my
question is, how do i manage entries for multiple hierarchies ?
currently when i try it, it picks up from where it finds entry first
and completes it, how do i get values so it creates an array from all
hierachies and then populates the k5login?
i tried deeper merging and hiera_array, still not sure why it's not
working. anything special i need to do ?
Hi Dhaval,
it would be great if you can post the puppet code and your hiera data.
Otherwise people have to guess.
Best,
Martin
--
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/d3249396-d863-4400-ab59-d58145facba4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Using puppet for the configuration of a custom appliance
Hello Lupin- Thank you for the update! Could you point me for any article, so that i can take a look at how exactly it could be done. Thanks! -varun On Monday, 6 April 2015 20:38:29 UTC-7, lupin...@gmail.com wrote: On Tuesday, April 7, 2015 at 8:09:41 AM UTC+12, varun umesh wrote: I am planning to use puppet for the configuration of a custom network appliance. My main problem is i am unable to install puppet on the appliance, as it is not supported. I have access to the rest api's exposed by the appliance. So can i use puppet to make the rest api calls and try to do the configurations as and when a parameter changes? Could anybody suggest me a good way to handle this problem? Thanks! Hello, You can use a slave node ( which you can install Puppet and attached the module ), your module will do the call to ReST API of your appliance. Cheers Lupin -- 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/923c1b97-5342-4cf3-bcff-32c4446eb947%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Classifying nodes with PE results in 303
Hi, I'm trying to classify a new node using the commandline just as explained here : https://docs.puppetlabs.com/pe/latest/cloudprovisioner_classifying_installing.html#classifying-nodes I've seen the youtube demo that just runs fab, but for some reason my puppet-setup is failing, which is not really nice. root@nodemanager:~# puppet node classify --insecure --node-group=test --enc-auth-user=console --enc-auth-passwd=Welcome001 --enc-server=mypuppet.master.net --enc-port=443 mywebsvr01 Notice: Contacting https://mypuppet.master.net:443/ to classify mywebsvr01 Warning: List nodes ... Failed Warning: Server responded with a 303 status Error: Could not: List nodes, got 303 expected 200 Error: Try 'puppet help node classify' for usage When I check the pe-httpd-log I see the request coming in /nodes.json but I see also the 303 linked to it. The user console is authorized for PE-console but for some reason is not working. How do I get my access-credentials right to make this work? Can anyone give me a hint. I'm pretty new at this, so I'm a bit overwhelmed by all config-stuff. Greetings, Henk-Jan -- 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/12c0c431-d53b-4079-a90c-26bda9cb6f65%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] facter: unordered hashes lead to changes
Sounds like this is set to true (over here I set it to false everywhere to take
advantage of the non-string facts):
https://docs.puppetlabs.com/references/latest/configuration.html#stringifyfacts
On Tue, Apr 07, 2015 at 01:56:43PM -0400, Guy Matz wrote:
Hi! I'm seeing the following at the end of my puppet run:
Notice:
/Stage[main]/Mcollective::Server::Config::Factsource::Yaml/File[/etc/mcollective/facts.yaml]/content:
--- /etc/mcollective/facts.yaml 2015-04-07 15:51:25.243758139 +
+++ /tmp/puppet-file20150407-6557-wl0qx7-0 2015-04-07
17:51:34.770285890 +
@@ -57,15 +57,15 @@
operatingsystem: CentOS
operatingsystemmajrelease: 6
operatingsystemrelease: 6.6
- os: familyRedHatreleasemajor6full6.6minor6nameCentOS
+ os: familyRedHatnameCentOSreleasefull6.6major6minor6
osfamily: RedHat
- partitions:
sda1uuidced0932e-4636-4d8f-9c63-ea32b0dccf89size1024000filesystemext4mount/bootsda2size66082816filesystemLVM2_member
+ partitions:
sda1mount/bootuuidced0932e-4636-4d8f-9c63-ea32b0dccf89size1024000filesystemext4sda2size66082816filesystemLVM2_member
os, partitions and a few others change each run . . . checking a single
fact shows that facter is returning an unordered has which changes on each
invocation:
$ facter os
{name=CentOS, family=RedHat, release={full=6.6,
minor=6, major=6}}
$ facter os
{family=RedHat, name=CentOS, release={full=6.6,
major=6, minor=6}}
I don't remember this ever happening before . . . what's up with that!?
Anyone know, off the top of their head, what might be causing this?
Thanks!
Guy
--
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 [1]puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
[2]https://groups.google.com/d/msgid/puppet-users/CABnTgtXOGN4tM-DNYoVK5zSwGWBgZFLC48Y%3Dw6HjA2KViKm49A%40mail.gmail.com.
For more options, visit [3]https://groups.google.com/d/optout.
References
Visible links
1. mailto:puppet-users+unsubscr...@googlegroups.com
2.
https://groups.google.com/d/msgid/puppet-users/CABnTgtXOGN4tM-DNYoVK5zSwGWBgZFLC48Y%3Dw6HjA2KViKm49A%40mail.gmail.com?utm_medium=emailutm_source=footer
3. https://groups.google.com/d/optout
--
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/20150407180816.GA9555%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] facter: unordered hashes lead to changes
Hi! I'm seeing the following at the end of my puppet run:
Notice:
/Stage[main]/Mcollective::Server::Config::Factsource::Yaml/File[/etc/mcollective/facts.yaml]/content:
--- /etc/mcollective/facts.yaml 2015-04-07 15:51:25.243758139 +
+++ /tmp/puppet-file20150407-6557-wl0qx7-0 2015-04-07
17:51:34.770285890 +
@@ -57,15 +57,15 @@
operatingsystem: CentOS
operatingsystemmajrelease: 6
operatingsystemrelease: 6.6
- os: familyRedHatreleasemajor6full6.6minor6nameCentOS
+ os: familyRedHatnameCentOSreleasefull6.6major6minor6
osfamily: RedHat
- partitions:
sda1uuidced0932e-4636-4d8f-9c63-ea32b0dccf89size1024000filesystemext4mount/bootsda2size66082816filesystemLVM2_member
+ partitions:
sda1mount/bootuuidced0932e-4636-4d8f-9c63-ea32b0dccf89size1024000filesystemext4sda2size66082816filesystemLVM2_member
os, partitions and a few others change each run . . . checking a single
fact shows that facter is returning an unordered has which changes on each
invocation:
$ facter os
{name=CentOS, family=RedHat, release={full=6.6,
minor=6, major=6}}
$ facter os
{family=RedHat, name=CentOS, release={full=6.6,
major=6, minor=6}}
I don't remember this ever happening before . . . what's up with that!?
Anyone know, off the top of their head, what might be causing this?
Thanks!
Guy
--
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/CABnTgtXOGN4tM-DNYoVK5zSwGWBgZFLC48Y%3Dw6HjA2KViKm49A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Best approach to creating wrapper classes
On Thursday, April 2, 2015 at 7:37:31 PM UTC-4, Christopher Wood wrote:
You might be interested in this thread:
https://groups.google.com/forum/#!topic/puppet-users/nmVQQA6G-f8
Thanks!
On Friday, April 3, 2015 at 9:15:00 AM UTC-4, jcbollinger wrote:
On Thursday, April 2, 2015 at 4:02:30 PM UTC-5, Scott Jaffa wrote:
Hi,
I'm working in an environment where certain parameters need to be
enforced per security requirements..
The ways we've identified to do this are:
1) Put the specific settings in the profile:
Advantages: Utilize stock roles and profiles pattern, plenty of
documentation and guides online.
Disadvantage: The settings are part of the profile and thus two groups
need to share ownership of the same module. Reduces flexibility or speed
due to additional enforcement needed by shared ownership.
2) Modify the modules themselves.
Advantages: Configuration is part of the module.
Disadvantages: We are now maintaining all custom modules.
3) Extend roles and profiles to add an additional layer between existing
profiles and the modules.
The workflow would be:
Role (business layer) Profile (technology layer) Security (security
layer) Module.
Advantages: Engineering configuration and security configuration are
seperated, with security configuration enforced.
Disadvantages: Need a way to present most options up to the profiles
layer for parameterization, while enforcing a few options.
We'd prefer to go with option 3. Does this make sense?
I'm having trouble understanding how you propose to factor out security
considerations from the technology to which they apply. Is this just about
ownership of data, or do there need to be *bona fide* security-specific
resources? If the former, then what do you need that you cannot achieve
via a security-specific level in your Hiera hierarchy? If the latter, then
how would making the security classes responsible for declaring
component-level classes (per option 3) achieve the separation of concerns
you claim as an advantage?
If so, some tips on how to go about this would be appreciated. Does it
make sense for the security module to inherit the base module in this case?
It would look something like this (but actually work :) )
class sec_profile::ssh inherits ::ssh {
$server_options = { 'Protocol' = '2', 'Ciphers' =
'aes128-ctr,aes192-ctr,aes256-ctr', 'PermitRootLogin' = 'no',
'ClientAliveInterval' = '900', 'PermitEmptyPasswords' = 'no',
'PasswordAuthentication' = 'no', 'Port' = [22], } }
If you are contemplating class inheritance for the purpose of greater
freedom in applying resource property overrides, then maybe they would be
useful to you. If you have an idea that they would do anything else for
you, then put it out of your mind -- class inheritance doesn't work that
way (whatever way that happens to be). Note, however, that often you can
perform resource overrides without class inheritance, that often it is
better to modify the external data from which modules draw property values
than to override property values after the fact, and that class inheritance
creates a very tight coupling that is probably better avoided if it crosses
module boundaries.
Yes, the goal is strictly to provide flexibility in parameters. I think
this is a case where inheritance can make sense, but, particularly as an
end goal is the public release of these modules, I'd like to make sure they
are designed correctly, or at least today's definition of correctly.
If not, can you suggest a good approach to present the base module
options to the profile? We'd like to to allow parameterization / hiera
lookups at the profile layer, preferrably without having to reimplement
each option in the security layer.
It would help if you presented a representative example of what you're
trying to configure, and explained the challenge you face with respect to
that. What you've presented so far is too abstract for me to offer any
specific advice.
John
Certainly!
The goal here is to build security hardening into the Puppet configuration
stack while still allowing flexibility for environment configuration, as,
for example, it is reasonable to turn off one or more hardening settings.
Ideally, any module released would allow one to select their hardening
standard, whether CIS, STIG, or other.
Conceptually this would extend the roles and profiles pattern. In
particular, profiles exist to define technology stacks. This likely will
result in multiple profiles calling the same module. The idea is to
inject another layer above the modules, which have a 1:1 correlation with
the modules. This wrapper module would provide an expose the specific
configuration options required for security hardening, while allowing the
calling profile to pass through environment parameters, as is done today.
To continue with the SSH example (pardon
[Puppet Users] Generating firewall rules without connection tracking.
The puppetlabs-firewall module has a provider called firewall{} which
builds a rule. I've written a wrapper that either calls it (without
any changes) or, if track = false, generates an equivalent set of
rules that does not use the Linux firewall connection tracking
mechanism. This is useful if you are a high-volume web site and
connection tracking has become a resource hog.
When track = false, four rules are generated instead:
1. the raw table, chain=PREROUTING, same source and destination, jump=NOTRACK.
2. the raw table, chain=OUTPUT, swap the source and destination, jump=NOTRACK.
3. the filter table, chain=INPUT, same source and destination.
4. the filter table, chain=OUTPUT, swap the source and destination.
NOTE: However if this is an OUTPUT rule, swap the chain in 1 and 2,
and 3 and 4. If you are using ipsets, reverse them in rules 2 and 4.
(Easy to remember, right?)
You can generate these 4 rules by hand, but it is error prone...
especially if you are making many such rules.
My employer (Stack Exchange, Inc.) has graciously me permission to
open source it:
https://github.com/StackExchange/stackexchange-superfirewall
Enjoy!
Tom
--
Email: t...@whatexit.orgWork: tlimonce...@stackoverflow.com
Skype: YesThatTom
Blog: http://EverythingSysadmin.com
--
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/CAHVFxg%3D9E_wF0NJ%2BFDO_UBWYxvGiHTH6fgyhoYuKXihE4TVf5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] facter: unordered hashes lead to changes
Ahhh!! The version of facter on my new servers is 2.4 . . old servers
have 1.7 . . .anyone know how to get facter 2.x to stringify facts?
I've tried adding 'stringify_facts = true' to my puppet.conf, but that did
not change behaviour . . .
On Tue, Apr 7, 2015 at 2:08 PM, Christopher Wood christopher_w...@pobox.com
wrote:
Sounds like this is set to true (over here I set it to false everywhere to
take advantage of the non-string facts):
https://docs.puppetlabs.com/references/latest/configuration.html#stringifyfacts
On Tue, Apr 07, 2015 at 01:56:43PM -0400, Guy Matz wrote:
Hi! I'm seeing the following at the end of my puppet run:
Notice:
/Stage[main]/Mcollective::Server::Config::Factsource::Yaml/File[/etc/mcollective/facts.yaml]/content:
--- /etc/mcollective/facts.yaml 2015-04-07 15:51:25.243758139 +
+++ /tmp/puppet-file20150407-6557-wl0qx7-0 2015-04-07
17:51:34.770285890 +
@@ -57,15 +57,15 @@
operatingsystem: CentOS
operatingsystemmajrelease: 6
operatingsystemrelease: 6.6
- os: familyRedHatreleasemajor6full6.6minor6nameCentOS
+ os: familyRedHatnameCentOSreleasefull6.6major6minor6
osfamily: RedHat
- partitions:
sda1uuidced0932e-4636-4d8f-9c63-ea32b0dccf89size1024000filesystemext4mount/bootsda2size66082816filesystemLVM2_member
+ partitions:
sda1mount/bootuuidced0932e-4636-4d8f-9c63-ea32b0dccf89size1024000filesystemext4sda2size66082816filesystemLVM2_member
os, partitions and a few others change each run . . . checking a
single
fact shows that facter is returning an unordered has which changes on
each
invocation:
$ facter os
{name=CentOS, family=RedHat, release={full=6.6,
minor=6, major=6}}
$ facter os
{family=RedHat, name=CentOS, release={full=6.6,
major=6, minor=6}}
I don't remember this ever happening before . . . what's up with
that!?
Anyone know, off the top of their head, what might be causing this?
Thanks!
Guy
--
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 [1]puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
[2]
https://groups.google.com/d/msgid/puppet-users/CABnTgtXOGN4tM-DNYoVK5zSwGWBgZFLC48Y%3Dw6HjA2KViKm49A%40mail.gmail.com
.
For more options, visit [3]https://groups.google.com/d/optout.
References
Visible links
1. mailto:puppet-users+unsubscr...@googlegroups.com
2.
https://groups.google.com/d/msgid/puppet-users/CABnTgtXOGN4tM-DNYoVK5zSwGWBgZFLC48Y%3Dw6HjA2KViKm49A%40mail.gmail.com?utm_medium=emailutm_source=footer
3. https://groups.google.com/d/optout
--
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/20150407180816.GA9555%40iniquitous.heresiarch.ca
.
For more options, visit https://groups.google.com/d/optout.
--
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/CABnTgtXH7u5kEfc9AhaARC0KwBYiY_4n1der6hax7oknxKgymA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: collector in class with same name as tag causes all virtual resources of the type to be realized
Here is a similar example using notify
== site.pp ==
node default {
include noticegroups::matches
}
== modules/noticegroups/manifests/matches.pp ==
class noticegroups::matches {
include notices
Notices::Anotice | tag == matches |
}
== modules/notices/manifests/anotice.pp ==
define notices::anotice {
notify { $title: }
}
== modules/notices/manifests/data.pp ==
class notices::data {
@notices::anotice { 'meant to be made': tag=['matches'], }
@notices::anotice { 'NOT meant to be made': tag=['doesnotmatch'], }
}
== modules/notices/manifests/init.pp ==
class notices {
include notices::data
}
with that I get the behaviour I expect in puppet 3.6 and broken in 3.7
if I change class noticegroups::matches to noticegroups::iwantmatches then
only the resource I want gets realized
this just seems like 3.7 broke something to me
On 7 April 2015 at 11:34, Neil - Puppet List
maillist-pup...@iamafreeman.com wrote:
Hello
I'm upgrading from 3.6 to 3.7 and have it a issue/bug
I'm using users/groups but to keep it short and something others can run
without the mess of users being made I've made up a file example
== modules/filegroups/manifests/matches.pp ===
class filegroups::matches {
include files
Files::Afile | tag == matches |
}
== modules/files/manifests/afile.pp ===
define files::afile {
file { $title: ensure=present, content='hello', }
}
== modules/files/manifests/data.pp ===
class files::data {
@files::afile { '/tmp/meanttobemade': tag=['matches'], }
@files::afile { '/tmp/notmeanttobemade': tag=['doesnotmatch'], }
}
== modules/files/manifests/init.pp ===
class files {
include files::data
}
== site.pp ===
node default {
include filegroups::matches
}
makes both files
Notice:
/Stage[main]/Files::Data/Files::Afile[/tmp/notmeanttobemade]/File[/tmp/notmeanttobemade]/ensure:
created
If I rename modules/filegroups/manifests/matches.pp
to modules/filegroups/manifests/iwantmatches.pp (and change the first line)
or rename the tag I get the desired behaviour
Anyone else seen this? Is this a bug?
There is a matching old question at askpuppetlabs
https://ask.puppetlabs.com/question/14349/upgrade-to-371-causes-resource-collectors-to-realize-everything/
that I've chipped in on the end off
Thanks,
Neil
--
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/CAAohVBd7X0eh-Ed6Pg%3DLC_Peezp5XdFokcNZp-YeXMLWbEAcnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Notice: Puppet Provider for Chocolatey - New Bits, New Location
To help resolve some recent confusion, I am sending out this notice that was also sent out to the chocolatey users list. The Puppet provider for Chocolatey is now at https://forge.puppetlabs.com/chocolatey/chocolatey - This provider supports both the old PowerShell client (0.9.8 and below) and the new compiled choco client (0.9.9+). - The work that was done fixed a range of issues - https://github.com/chocolatey/puppet-chocolatey/pull/49 (note that some of these may still be issues if you are on 0.9.8 and below). - We'll update the old rismoney/chocolatey to point to the new module soon and deprecate it fully. -- Rob Reynolds Developer, Puppet Labs *PuppetConf 2015 http://2015.puppetconf.com/ is coming to Portland, Oregon! Join us October 5-9.* *Register now to take advantage of the Early Adopter discount https://www.eventbrite.com/e/puppetconf-2015-october-5-9-tickets-13115894995?discount=EarlyAdopter * *--**save $349!* -- 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/CAMJiBK7i0Dm0Bc6v9kaLkjPzyVEUrix6-3W_RAEEdo0W5Rb2Dg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Announce: PuppetDB 2.3.3 is now available!
PuppetDB 2.3.3 - April 7, 2015 PuppetDB 2.3.3 Downloads Available in native package format in the release repositories at: http://yum.puppetlabs.com and http://apt.puppetlabs.com For information on how to enable the Puppet Labs repos, see: http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html#open-source-repositories Binary tarball: http://downloads.puppetlabs.com/puppetdb/ Source: http://github.com/puppetlabs/puppetdb Please report feedback via the Puppet Labs tickets site, using an affected PuppetDB version of 2.3.3: https://tickets.puppetlabs.com/browse/PDB Documentation: http://docs.puppetlabs.com/puppetdb/2.3/ Puppet module: http://forge.puppetlabs.com/puppetlabs/puppetdb PuppetDB 2.3.3 Release Notes PuppetDB 2.3.3 is a backwards-compatible bugfix release that adds support for Puppet 4 on Debian and Ubuntu platforms. For more details, consult the release notes here: https://docs.puppetlabs.com/puppetdb/2.3/release_notes.html Contributors Matthaus Owens, Rob Browning Changelog - Matthaus Owens (1): 84ffce5 (PDB-1389) Add puppet-agent option for debian dependencies -- 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/CA%2BP9biPBFLyvLX_dNmauF1f%3DkGW16kzQOT6p0yy-mja-e3292g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
