Re: [Puppet Users] variable scoping and erb templates

[Lowe Schmidt]

What version of Puppet are you running?

--
Lowe Schmidt | +46 723 867 157

On 15 August 2016 at 20:48, Matt Zagrabelny  wrote:

> Greetings!
>
> I am hitting a curious question and couldn't find an answer.
>
> I can access variables from other classes when using an erb template.
>
> Here is my minimal example:
>
> # puppet apply variable_scope_test.pp
> Notice: Compiled catalog for puppet.example.com in environment
> production in 0.12 seconds
> Notice: A variable from a different class:
> Notice: /Stage[main]/Scope_example::Sub_class/Notify[A variable from a
> different class: ]/message: defined 'message' as 'A variable from a
> different class: '
> Notice: Finished catalog run in 0.11 seconds
>
> # cd /tmp
> # head -n -0 variable_scope_test.pp template.erb template_output
> ==> variable_scope_test.pp <==
> class scope_example {
> $variable = "THIS IS A TEST!"
> include scope_example::sub_class
> }
>
> class scope_example::sub_class {
> file { '/tmp/template_output':
> content => template('/tmp/template.erb'),
> }
> notify { "A variable from a different class: $variable": }
> }
>
> node 'puppet.example.com' {
> include scope_example
> }
>
> ==> template.erb <==
> <%= @variable %>
>
> ==> template_output <==
> THIS IS A TEST!
>
> So why is the template allowed to see variables in other classes?
>
> I would have ad expected to need to use the variable like:
>
> <%= @scope_example::variable %>
>
> But it clearly works without adjusting its namespace.
>
> Thoughts?
>
> Thanks!
>
> -m
>
> --
> 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/CAOLfK3WBY9Hg%3DsaiHA2iAt4SRQjBX6XLsAJVj_
> qLGHJgjuugEg%40mail.gmail.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/CAC-wWcSmcHxSC5h169UOBiqq0HJTRtN7C4WfRbmnW02rHgx_OA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] module design: different module sections manipulating files in single directory

[dkoleary]

Hey

I went with my option #2 for this exercise.  I will definitely be looking into 
the package management as it'll come up.  In fact, it may have already come up 
in a different request.  For this one, though, I have something like 5 scripts 
in the 'all-hosts' list and 3 in the subset so individual file resources were 
easy enough.  It works.  Not pretty by any stretch but that's what process 
improvement's for.

Thanks again for the responses.

Doug O'Leary

-- 
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/a2f99ab3-463d-4e1b-a8cd-e967936ef06f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] how to ensure LVM created before installing postgres

[Alex Samad]

Hi

I would like to setup my LVM first 
PV
VG
PV 
mount that in /var/lib/pgsql/9.2/data and then use

# default
class { 'postgresql::globals':
  manage_package_repo => false,
  version => '9.2',
}->
  class { 'postgresql::server':
  }


now for testing I haven't installed /dev/sdc which is my phys disk for the 
vg..

I would like the install of postgress to fail



# predefined mounts
# not done via lvm - can't do labels !

# setup PG Data directory first
file { '/var/lib/pgsql':
  ensure   => 'directory',
  group=> '26',
  mode => '0700',
  owner=> '26',
}

file { '/var/lib/pgsql/9.2/':
  ensure   => 'directory',
  group=> '26',
  mode => '0700',
  owner=> '26',
}

# incuded as part of the postgres module
#file { '/var/lib/pgsql/9.2/data':
#  ensure   => 'directory',
#  group=> '26',
#  mode => '0700',
#  owner=> '26',
#}

filesystem { '/dev/vg_pgdata/lv_pgdata':
  ensure => 'present',
  fs_type => 'ext4',
  options => '-L ybPGData',
}

mount { '/var/lib/pgsql/9.2/data':
  ensure  => 'mounted',
  device  => 'LABEL=ybPGData',
  dump=> '1',
  fstype  => 'ext4',
  options => 'defaults',
  pass=> '2',
  target  => '/etc/fstab',
}

volume_group { 'vg_pgdata':
  ensure => present,
  physical_volumes => '/dev/sdc1'
}

logical_volume { 'lv_pgdata':
  ensure => present,
  volume_group => 'vg_pgdata',
  size => '20G',
}



#
# latest postgres rpm
#
package { 'pgdg-centos92-repo':
  name => 'pgdg-centos92',
  ensure => 'installed',
  provider => 'rpm',
  source => 
'https://download.postgresql.org/pub/repos/yum/9.2/redhat/rhel-6-x86_64/pgdg-centos92-9.2-7.noarch.rpm',
  install_options => [
'--httpproxy',
'proxyyb',
'--httpport',
'3128',
  ]
}

# have to overwrite the repo file
file { 're_pgdg-centos92':
  ensure => present,
  path => '/etc/yum.repos.d/pgdg-92-centos.repo',
  content => file('profile/ybpostgresql92/pgdg-92-centos.repo'),
  owner => 'root',
  group => 'root',
  mode => 'u=rw,g=r,o=r',
}


# default
class { 'postgresql::globals':
  manage_package_repo => false,
  version => '9.2',
}->
  class { 'postgresql::server':
  }


-- 
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/1a228b97-3b47-43a7-95e0-ff1d5cf0f6fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] module design: different module sections manipulating files in single directory

[Dan Mahoney]

On Mon, 15 Aug 2016, dkoleary wrote:


Hey;
Thanks for the responses.  I hadn't thought of packages.  I will start
exploring that option


What would work, as a short term option:

* A class that just owns /root/bin

* Separate classes that create things in directories under /root/bin (say 
/root/bin/webserver), and requires the above class.  Similar to how a core 
class may own /etc/apache/conf.d, but others may own things under.


* If you absolutely need them, symlinks, either via individual file 
resources, or a script that basically goes through and updates them, as a 
notify exec.


What you haven't said, is how many files are involved in your recurse, so 
it's hard to say how well this would work for you.


Also an ugly hack, but may be more easily available than learning to 
package overnight.


-Dan



Thanks again.

Doug O'Leary

On Monday, August 15, 2016 at 3:42:20 PM UTC-5, Rob Nelson wrote:
  Doubt,

  I agree with Dan, packaging is the answer. And before you say it
  - yes, packaging sounds scary at first, but it doesn't have to
  be. Check out FPM - https://github.com/jordansissel/fpm/wiki -
  to generate a package in the correct format. You can very easily
  package static files that way, and use file resources with
  `source => template(...)` for any dynamic files required.

Hosting the files is pretty easy if you're using yum, as yumrepos are
built in. You can host them on a node with 
profile::yumrepo(https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/m
anifests/yumrepo.pp 
andhttps://github.com/puppetinabox/controlrepo/blob/production/hiera/puppet_ro
le/yumrepo.yaml), throw the rpms in /var/www/html/puppetrepo/el7, and
then ensure your base profile distributes that 
repo(https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/m
anifests/base.pp#L29-L38). That code is dated and needs a little
improvement (stop using `create_resources()`!) but should get you
started quickly. I'm sure there's an equivalent for Apt.


Rob Nelson
rnel...@gmail.com

On Mon, Aug 15, 2016 at 4:19 PM, Dan Mahoney  wrote:
  On Mon, 15 Aug 2016, dkoleary wrote:

Hey;
I suspected this was going to be a problem
and, sure enough, it is.  

Here's the scenario:  puppet server 4.5:  I
have ~ 1200 hosts on which I
want specific files in /root/bin on all
hosts.  A reasonably large subset of
those should have additional files in
/root/bin as part of an home-grown
application management process.  To be clear,
none of the files from the
'all-host' group overlap with any of the files
from the 'some-hosts' group.

The all-host group is easy enough::

  file { '/root/bin':
    ensure  => 'directory',
    owner   => 'root',
    group   => 'root',
    mode    => '0700',
    recurse => true,
    source  =>
'puppet:///modules/myroot/rootbin',
    require => File['/root'],
  }

So, that's worked for weeks now.  In my
company's slow migration to puppet
management, I'm finally to the point of adding
some custom application
related files to /root/bin.  On the surface,
the some-hosts group is pretty
easy too::

    file { 'webconfbin':
      ensure  => 'directory',
      path    => '/root/bin',
      owner   => 'root',
      group   => 'root',
      mode    => '0700',
      recurse => true,
      source  =>
'puppet:///modules/myroot/webconf',
    }

As I suspected, that resulted in the bright
red error message about
'resource /root/bin already declared'.  The
two options that I can think of
aren't particularly appetizing:

1.  Add the files from some-hosts to all-hosts
resulting in the app
management files being everywhere.  These
files, themselves, don't represent
a security issue, but it's not a very clean
approach.

2.  Use individual file resources.  I could
get away with that approach on
this one; but, when I run into a similar issue
with dozens or 100s of files,
I'd hate to be specifying all those file
resources.

Realizing I probably took a wrong turn in my
initial design and figuring
someone else has to have had run into this
problem before, I'm asking the
experts.  What's the right way to have a set
of files on all hosts and a
different set of files on a subset of all
hosts in t

Re: [Puppet Users] module design: different module sections manipulating files in single directory

[dkoleary]

Hey;

Thanks for the responses.  I hadn't thought of packages.  I will start 
exploring that option

Thanks again.

Doug O'Leary

On Monday, August 15, 2016 at 3:42:20 PM UTC-5, Rob Nelson wrote:
>
> Doubt,
>
> I agree with Dan, packaging is the answer. And before you say it - yes, 
> packaging sounds scary at first, but it doesn't have to be. Check out FPM - 
> https://github.com/jordansissel/fpm/wiki - to generate a package in the 
> correct format. You can very easily package static files that way, and use 
> file resources with `source => template(...)` for any dynamic files 
> required.
>
> Hosting the files is pretty easy if you're using yum, as yumrepos are 
> built in. You can host them on a node with profile::yumrepo (
> https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/manifests/yumrepo.pp
>  
> and 
> https://github.com/puppetinabox/controlrepo/blob/production/hiera/puppet_role/yumrepo.yaml),
>  
> throw the rpms in /var/www/html/puppetrepo/el7, and then ensure your base 
> profile distributes that repo (
> https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/manifests/base.pp#L29-L38).
>  
> That code is dated and needs a little improvement (stop using 
> `create_resources()`!) but should get you started quickly. I'm sure there's 
> an equivalent for Apt.
>
>
> Rob Nelson
> rnel...@gmail.com 
>
> On Mon, Aug 15, 2016 at 4:19 PM, Dan Mahoney  > wrote:
>
>> On Mon, 15 Aug 2016, dkoleary wrote:
>>
>> Hey;
>>> I suspected this was going to be a problem and, sure enough, it is.  
>>>
>>> Here's the scenario:  puppet server 4.5:  I have ~ 1200 hosts on which I
>>> want specific files in /root/bin on all hosts.  A reasonably large 
>>> subset of
>>> those should have additional files in /root/bin as part of an home-grown
>>> application management process.  To be clear, none of the files from the
>>> 'all-host' group overlap with any of the files from the 'some-hosts' 
>>> group.
>>>
>>> The all-host group is easy enough::
>>>
>>>   file { '/root/bin':
>>> ensure  => 'directory',
>>> owner   => 'root',
>>> group   => 'root',
>>> mode=> '0700',
>>> recurse => true,
>>> source  => 'puppet:///modules/myroot/rootbin',
>>> require => File['/root'],
>>>   }
>>>
>>> So, that's worked for weeks now.  In my company's slow migration to 
>>> puppet
>>> management, I'm finally to the point of adding some custom application
>>> related files to /root/bin.  On the surface, the some-hosts group is 
>>> pretty
>>> easy too::
>>>
>>> file { 'webconfbin':
>>>   ensure  => 'directory',
>>>   path=> '/root/bin',
>>>   owner   => 'root',
>>>   group   => 'root',
>>>   mode=> '0700',
>>>   recurse => true,
>>>   source  => 'puppet:///modules/myroot/webconf',
>>> }
>>>
>>> As I suspected, that resulted in the bright red error message about
>>> 'resource /root/bin already declared'.  The two options that I can think 
>>> of
>>> aren't particularly appetizing:
>>>
>>> 1.  Add the files from some-hosts to all-hosts resulting in the app
>>> management files being everywhere.  These files, themselves, don't 
>>> represent
>>> a security issue, but it's not a very clean approach.
>>>
>>> 2.  Use individual file resources.  I could get away with that approach 
>>> on
>>> this one; but, when I run into a similar issue with dozens or 100s of 
>>> files,
>>> I'd hate to be specifying all those file resources.
>>>
>>> Realizing I probably took a wrong turn in my initial design and figuring
>>> someone else has to have had run into this problem before, I'm asking the
>>> experts.  What's the right way to have a set of files on all hosts and a
>>> different set of files on a subset of all hosts in the same directory?
>>>
>>
>> I don't often comment on the puppet stuff, but yours made me need to 
>> chime in and say this:
>>
>> Recurse is an ugly, awful, terrible hack and should be deprecated.
>>
>> I don't say that with any knowledge of the way it evolved or what its 
>> future support status is, but if you look at it -- it's effectively an 
>> expansion macro that turns into dozens or hundreds of File[] resources (and 
>> interally -- can and MUST grow your manifest internally in-memory to that 
>> size).
>>
>> Judging by the fact that you're using a /bin directory to distribute 
>> things, which I assume are binaries, or scripts, the thing that makes sense 
>> here (especially with 1200 hosts) is to look in to using your OS's package 
>> manager to accomplish this task -- where you could, possibly, break out the 
>> installables by host-class.  (i.e. the files in yoursite-db.rpm would 
>> require the files in yoursite-common.rpm)
>>
>> You could, then, use puppet to manage a local installable of that 
>> distributable, with a notify action that ran the installer -- or you could 
>> use the builtin package resource type with a local repo, and use require => 
>> latest to upgrade that, if you have a high change delta.
>

Re: [Puppet Users] module design: different module sections manipulating files in single directory

[Rob Nelson]

Doubt,

I agree with Dan, packaging is the answer. And before you say it - yes,
packaging sounds scary at first, but it doesn't have to be. Check out FPM -
https://github.com/jordansissel/fpm/wiki - to generate a package in the
correct format. You can very easily package static files that way, and use
file resources with `source => template(...)` for any dynamic files
required.

Hosting the files is pretty easy if you're using yum, as yumrepos are built
in. You can host them on a node with profile::yumrepo (
https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/manifests/yumrepo.pp
and
https://github.com/puppetinabox/controlrepo/blob/production/hiera/puppet_role/yumrepo.yaml),
throw the rpms in /var/www/html/puppetrepo/el7, and then ensure your base
profile distributes that repo (
https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/manifests/base.pp#L29-L38).
That code is dated and needs a little improvement (stop using
`create_resources()`!) but should get you started quickly. I'm sure there's
an equivalent for Apt.


Rob Nelson
rnels...@gmail.com

On Mon, Aug 15, 2016 at 4:19 PM, Dan Mahoney  wrote:

> On Mon, 15 Aug 2016, dkoleary wrote:
>
> Hey;
>> I suspected this was going to be a problem and, sure enough, it is.
>>
>> Here's the scenario:  puppet server 4.5:  I have ~ 1200 hosts on which I
>> want specific files in /root/bin on all hosts.  A reasonably large subset
>> of
>> those should have additional files in /root/bin as part of an home-grown
>> application management process.  To be clear, none of the files from the
>> 'all-host' group overlap with any of the files from the 'some-hosts'
>> group.
>>
>> The all-host group is easy enough::
>>
>>   file { '/root/bin':
>> ensure  => 'directory',
>> owner   => 'root',
>> group   => 'root',
>> mode=> '0700',
>> recurse => true,
>> source  => 'puppet:///modules/myroot/rootbin',
>> require => File['/root'],
>>   }
>>
>> So, that's worked for weeks now.  In my company's slow migration to puppet
>> management, I'm finally to the point of adding some custom application
>> related files to /root/bin.  On the surface, the some-hosts group is
>> pretty
>> easy too::
>>
>> file { 'webconfbin':
>>   ensure  => 'directory',
>>   path=> '/root/bin',
>>   owner   => 'root',
>>   group   => 'root',
>>   mode=> '0700',
>>   recurse => true,
>>   source  => 'puppet:///modules/myroot/webconf',
>> }
>>
>> As I suspected, that resulted in the bright red error message about
>> 'resource /root/bin already declared'.  The two options that I can think
>> of
>> aren't particularly appetizing:
>>
>> 1.  Add the files from some-hosts to all-hosts resulting in the app
>> management files being everywhere.  These files, themselves, don't
>> represent
>> a security issue, but it's not a very clean approach.
>>
>> 2.  Use individual file resources.  I could get away with that approach on
>> this one; but, when I run into a similar issue with dozens or 100s of
>> files,
>> I'd hate to be specifying all those file resources.
>>
>> Realizing I probably took a wrong turn in my initial design and figuring
>> someone else has to have had run into this problem before, I'm asking the
>> experts.  What's the right way to have a set of files on all hosts and a
>> different set of files on a subset of all hosts in the same directory?
>>
>
> I don't often comment on the puppet stuff, but yours made me need to chime
> in and say this:
>
> Recurse is an ugly, awful, terrible hack and should be deprecated.
>
> I don't say that with any knowledge of the way it evolved or what its
> future support status is, but if you look at it -- it's effectively an
> expansion macro that turns into dozens or hundreds of File[] resources (and
> interally -- can and MUST grow your manifest internally in-memory to that
> size).
>
> Judging by the fact that you're using a /bin directory to distribute
> things, which I assume are binaries, or scripts, the thing that makes sense
> here (especially with 1200 hosts) is to look in to using your OS's package
> manager to accomplish this task -- where you could, possibly, break out the
> installables by host-class.  (i.e. the files in yoursite-db.rpm would
> require the files in yoursite-common.rpm)
>
> You could, then, use puppet to manage a local installable of that
> distributable, with a notify action that ran the installer -- or you could
> use the builtin package resource type with a local repo, and use require =>
> latest to upgrade that, if you have a high change delta.
>
> (Where I say RPM, subsitute OS package manager of choice, obviously).
>
> Yes, this steps outside of puppet, but on its face, puppet is *config*
> management, and what you seem to be trying to do, is not.
>
> --

-- 
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, se

Re: [Puppet Users] module design: different module sections manipulating files in single directory

[Dan Mahoney]

On Mon, 15 Aug 2016, dkoleary wrote:


Hey;
I suspected this was going to be a problem and, sure enough, it is.  

Here's the scenario:  puppet server 4.5:  I have ~ 1200 hosts on which I
want specific files in /root/bin on all hosts.  A reasonably large subset of
those should have additional files in /root/bin as part of an home-grown
application management process.  To be clear, none of the files from the
'all-host' group overlap with any of the files from the 'some-hosts' group.

The all-host group is easy enough::

  file { '/root/bin':
    ensure  => 'directory',
    owner   => 'root',
    group   => 'root',
    mode    => '0700',
    recurse => true,
    source  => 'puppet:///modules/myroot/rootbin',
    require => File['/root'],
  }

So, that's worked for weeks now.  In my company's slow migration to puppet
management, I'm finally to the point of adding some custom application
related files to /root/bin.  On the surface, the some-hosts group is pretty
easy too::

    file { 'webconfbin':
      ensure  => 'directory',
      path    => '/root/bin',
      owner   => 'root',
      group   => 'root',
      mode    => '0700',
      recurse => true,
      source  => 'puppet:///modules/myroot/webconf',
    }

As I suspected, that resulted in the bright red error message about
'resource /root/bin already declared'.  The two options that I can think of
aren't particularly appetizing:

1.  Add the files from some-hosts to all-hosts resulting in the app
management files being everywhere.  These files, themselves, don't represent
a security issue, but it's not a very clean approach.

2.  Use individual file resources.  I could get away with that approach on
this one; but, when I run into a similar issue with dozens or 100s of files,
I'd hate to be specifying all those file resources.

Realizing I probably took a wrong turn in my initial design and figuring
someone else has to have had run into this problem before, I'm asking the
experts.  What's the right way to have a set of files on all hosts and a
different set of files on a subset of all hosts in the same directory?


I don't often comment on the puppet stuff, but yours made me need to chime 
in and say this:


Recurse is an ugly, awful, terrible hack and should be deprecated.

I don't say that with any knowledge of the way it evolved or what its 
future support status is, but if you look at it -- it's effectively an 
expansion macro that turns into dozens or hundreds of File[] resources 
(and interally -- can and MUST grow your manifest internally in-memory to 
that size).


Judging by the fact that you're using a /bin directory to distribute 
things, which I assume are binaries, or scripts, the thing that makes 
sense here (especially with 1200 hosts) is to look in to using your OS's 
package manager to accomplish this task -- where you could, possibly, 
break out the installables by host-class.  (i.e. the files in 
yoursite-db.rpm would require the files in yoursite-common.rpm)


You could, then, use puppet to manage a local installable of that 
distributable, with a notify action that ran the installer -- or you could 
use the builtin package resource type with a local repo, and use require 
=> latest to upgrade that, if you have a high change delta.


(Where I say RPM, subsitute OS package manager of choice, obviously).

Yes, this steps outside of puppet, but on its face, puppet is *config* 
management, and what you seem to be trying to do, is not.


--

[Puppet Users] module design: different module sections manipulating files in single directory

[dkoleary]

Hey;

I suspected this was going to be a problem and, sure enough, it is.  

Here's the scenario:  puppet server 4.5:  I have ~ 1200 hosts on which I 
want specific files in /root/bin on all hosts.  A reasonably large subset 
of those should have additional files in /root/bin as part of an home-grown 
application management process.  To be clear, none of the files from the 
'all-host' group overlap with any of the files from the 'some-hosts' group.

The all-host group is easy enough::

  file { '/root/bin':
ensure  => 'directory',
owner   => 'root',
group   => 'root',
mode=> '0700',
recurse => true,
source  => 'puppet:///modules/myroot/rootbin',
require => File['/root'],
  }

So, that's worked for weeks now.  In my company's slow migration to puppet 
management, I'm finally to the point of adding some custom application 
related files to /root/bin.  On the surface, the some-hosts group is pretty 
easy too::

file { 'webconfbin':
  ensure  => 'directory',
  path=> '/root/bin',
  owner   => 'root',
  group   => 'root',
  mode=> '0700',
  recurse => true,
  source  => 'puppet:///modules/myroot/webconf',
}

As I suspected, that resulted in the bright red error message about 
'resource /root/bin already declared'.  The two options that I can think of 
aren't particularly appetizing:

1.  Add the files from some-hosts to all-hosts resulting in the app 
management files being everywhere.  These files, themselves, don't 
represent a security issue, but it's not a very clean approach.

2.  Use individual file resources.  I could get away with that approach on 
this one; but, when I run into a similar issue with dozens or 100s of 
files, I'd hate to be specifying all those file resources.

Realizing I probably took a wrong turn in my initial design and figuring 
someone else has to have had run into this problem before, I'm asking the 
experts.  What's the right way to have a set of files on all hosts and a 
different set of files on a subset of all hosts in the same directory?

Thanks for any hints/tips/suggestions.

Doug O'Leary

-- 
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/aa0bd31a-139e-4d8c-a845-8f292fa65054%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] variable scoping and erb templates

[Matt Zagrabelny]

Greetings!

I am hitting a curious question and couldn't find an answer.

I can access variables from other classes when using an erb template.

Here is my minimal example:

# puppet apply variable_scope_test.pp
Notice: Compiled catalog for puppet.example.com in environment
production in 0.12 seconds
Notice: A variable from a different class:
Notice: /Stage[main]/Scope_example::Sub_class/Notify[A variable from a
different class: ]/message: defined 'message' as 'A variable from a
different class: '
Notice: Finished catalog run in 0.11 seconds

# cd /tmp
# head -n -0 variable_scope_test.pp template.erb template_output
==> variable_scope_test.pp <==
class scope_example {
$variable = "THIS IS A TEST!"
include scope_example::sub_class
}

class scope_example::sub_class {
file { '/tmp/template_output':
content => template('/tmp/template.erb'),
}
notify { "A variable from a different class: $variable": }
}

node 'puppet.example.com' {
include scope_example
}

==> template.erb <==
<%= @variable %>

==> template_output <==
THIS IS A TEST!

So why is the template allowed to see variables in other classes?

I would have ad expected to need to use the variable like:

<%= @scope_example::variable %>

But it clearly works without adjusting its namespace.

Thoughts?

Thanks!

-m

-- 
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/CAOLfK3WBY9Hg%3DsaiHA2iAt4SRQjBX6XLsAJVj_qLGHJgjuugEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet Without Agent

[Craig Dunn]

I agree with Lowe Schmidt.

Wrong tool for the job.  "connect on some servers through SSH and run some
command lines" sounds like command orchestration, not configuration
management - Rundeck, ansible...etc as said.



On Mon, Aug 15, 2016 at 3:57 PM, Lowe Schmidt  wrote:

> Hey,
>
> no, sorry. Puppet cant connect over ssh and run commands for you.
> You can run the puppet agent without a puppet master, but then you need to
> transfer the manifest to the machine you want to run on first.
>
> There are other tools that lets you run commands or scripts over ssh like
> fabric or ansible.
>
> --
> Lowe Schmidt | +46 723 867 157
>
> On 15 August 2016 at 13:39,  wrote:
>
>> Hi guys,
>>
>> I wonder if I can use the Puppet without agent. I only need the Puppet
>> connect on some servers through SSH and run some command lines.
>>
>> Do you know if Puppet do this?
>>
>> Thanks a lot.
>>
>> Silvestri
>>
>> --
>> 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/ms
>> gid/puppet-users/9c2c3a0d-045b-49a3-93bc-d4d13605d68e%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/CAC-wWcTdKo4a%3Dq0X-Wi2WGt_yAYuCWre07j%2B_tWf%
> 2BmOh6cRRrA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Enviatics |  Automation and Configuration Management
Puppet Labs Service Delivery Partner & Certified Consultant
http://www.enviatics.com | @Enviatics | cr...@enviatics.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/CACxdKhEYNPW4V_V3CPtjS39ije61ua7e_-LsWNz%2BhS%3DzN7VpWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet Without Agent

[Lowe Schmidt]

Hey,

no, sorry. Puppet cant connect over ssh and run commands for you.
You can run the puppet agent without a puppet master, but then you need to
transfer the manifest to the machine you want to run on first.

There are other tools that lets you run commands or scripts over ssh like
fabric or ansible.

--
Lowe Schmidt | +46 723 867 157

On 15 August 2016 at 13:39,  wrote:

> Hi guys,
>
> I wonder if I can use the Puppet without agent. I only need the Puppet
> connect on some servers through SSH and run some command lines.
>
> Do you know if Puppet do this?
>
> Thanks a lot.
>
> Silvestri
>
> --
> 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/9c2c3a0d-045b-49a3-93bc-d4d13605d68e%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/CAC-wWcTdKo4a%3Dq0X-Wi2WGt_yAYuCWre07j%2B_tWf%2BmOh6cRRrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet Without Agent

[guilherme . silvestri]

Hi guys,

I wonder if I can use the Puppet without agent. I only need the Puppet 
connect on some servers through SSH and run some command lines.

Do you know if Puppet do this?

Thanks a lot.

Silvestri

-- 
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/9c2c3a0d-045b-49a3-93bc-d4d13605d68e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: automatically generate puppet manifests for legacy servers

[Dennis McCarthy]

Hi Corey,

I cloned this as ran it on my Centos6 vm. It was easy to setup and use and 
it does collect literally everything! I can see why this is useful to a lot 
of people.

Mine is puppet specific but allows for a lot more control along with role 
setup (directory environments) for use on a puppet master.

Thanks for making me aware of this!

Regards

Dennis


On Friday, 12 August 2016 18:01:18 UTC+1, Corey Osman wrote:
>
> You may want to check out https://github.com/devstructure/blueprint
>
>
>
> On Thursday, August 11, 2016 at 6:40:29 AM UTC-7, Dennis McCarthy wrote:
>>
>> Hi puppet-users,
>>
>> I've worked with puppet for a while now but was stuck on how best to 
>> manage legacy servers quickly without having to create specific manifests 
>> for each server. I basically wrote this script to do the whole thing for me 
>> and wondered if anyone else might find it useful.
>>
>> I've put it on github and would like some feedback from other users if 
>> you have time to take a look. It's targeted specifically at managing legacy 
>> servers or with people who don't know how to write their own manifests but 
>> want to learn by generating their own code. It covers files, services, 
>> packages, users, templates, file_line, etc. It generates a puppet apply 
>> script to manage your server locally but I also added in a role so it can 
>> be used with directory environments.
>>
>> If you want to contribute you're more then welcome to create a pull 
>> request.
>>
>> Here's my code. 
>> https://github.com/dmccuk/puppetmanifestgenerator.git
>>
>> Thanks.
>>
>>

-- 
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/2aa10b38-ad3e-4994-b5da-8fe08a71d4d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.