Re: [Puppet Users] Resource ordering syntax
Thanks Martin! That makes sense.
Is it not possible to refer to the entire resource, then, when the title is
used as the declaration?
Andrew
On Sunday, 18 January 2015 13:50:05 UTC, Martin Alfke wrote:
>
> When using an array on a resource title Puppet will internally create
> multiple resource declarations.
>
> e.g.
> when declaring like this:
> package { [‘foo’, ‘bar’, ‘bas’]: ensure => present }
>
> You can build references on each of the array elements:
>
> require => Package[‘bas’]
>
> see:
> https://docs.puppetlabs.com/puppet/latest/reference/lang_resources.html#array-of-titles
>
>
> On 17 Jan 2015, at 15:13, Andrew Langhorn <
> andrew@digital.cabinet-office.gov.uk > wrote:
>
> > Hi,
> >
> > I have a syntax query, I hope that the group can help with.
> >
> > When using resource ordering parameters, such as 'before' or 'require',
> I can specify the resource on which to act the ordering around. For
> instance:
> >
> > exec { 'wget-docker-key':
> > command => '/usr/bin/wget -qO- https://get.docker.io/gpg |
> /usr/bin/apt-key add -',
> > before => Exec['echo-docker-deb-apt-sources'],
> > }
> >
> > exec { 'echo-docker-deb-apt-sources':
> > command => '/bin/echo deb http://get.docker.io/ubuntu docker main >
> /etc/apt/sources.list.d/docker.list',
> > creates => '/etc/apt/sources.list.d/docker.list',
> > }
> >
> > This will ensure that the Docker key is installed on the machine before
> create a list of Docker sources for Apt.
> >
> > In situations where I'm using an array as the resource title, such as
> this:
> >
> > package { [
> > "linux-image-extra-${::kernelrelease}",
> > 'lxc',
> > 'lxc-docker-1.0.0',
> > ]:
> > ensure => present,
> > }
> >
> > How do I reference the resource when using resource ordering? Do I just
> use
> Package['linux-image-extra-${::kernelrelease}",'lxc','lxc-docker-1.0.0']?
> >
> > Thanks in advance!
> >
> > --
> > Andrew Langhorn
> > Web Operations
> > Government Digital Service
> >
> > e: andrew@digital.cabinet-office.gov.uk
> > a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH
> >
> > --
> > 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...@googlegroups.com .
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CANCa_WZ2Mp7A8PrAEvkK3DuuCks_3ptp1rCByhxxs1r%3DZ31iqQ%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/7830cb03-f6fd-4371-aa35-74071cdffd3a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: camptocamp/grundics accounts module
Mickaël,
Thanks for the reply!! Is there an updated version of the module that you
recommend I use?
One other thing . . . where do you put the class block that pulls in the
hiera data?
Thanks a lot!
Guy
On Sun, Jan 18, 2015 at 1:23 AM, Mickaël Canévet
wrote:
> If you still want to use *ssh_authorized_key_title*, you have some
> examples in unit tests.
>
> Le vendredi 16 janvier 2015 18:40:06 UTC+1, guymatz a écrit :
>>
>> Is anyone using camptocamp or grundic's accounts module? I can't it
>> working and am at my wit's end!
>>
>> my problem is with the ssh_authorized_key_title . . . I'm getting the
>> error:
>> Error 400 on SERVER: stack level too deep at /etc/puppet/modules/accounts/
>> manifests/authorized_key.pp:35
>>
>> But I think I have everything set up correctly:
>> In my modules/profiles/manifests/base.pp I have:
>> class { 'accounts':
>> groups => hiera_hash('accounts::groups', {}),
>> ssh_keys => hiera_hash('accounts::ssh_keys', {}),
>> users=> hiera_hash('accounts::users', {}),
>> usergroups => hiera_hash('accounts::usergroups', {}),
>> accounts => hiera_hash('accounts::accounts', {}),
>> *ssh_authorized_key_title =>
>> '%{ssh_keys[\'%{ssh_key}\'][\'comment\'] on %{user}',*
>> dotfiles => hiera_hash('accounts::dotfiles', {}),
>> }
>>
>> So that should put all of that info into my run, yes? Is there a better
>> place to put that?
>>
>> Then in hiera I have:
>> $ more hieradata/common_users.eyaml
>> accounts::ssh_keys:
>> iambot:
>> comment: iambot@somewhere
>> type: ssh-dss
>> public: public_key
>>
>> accounts::users:
>> iambot:
>> uid: 10079
>> gid: 10022
>> comment: I am a Bot
>>
>> accounts::groups:
>> Staff:
>> gid: 10022
>>
>> It seems that with camptocamp's implementation you then need to call
>> accounts::account like this to get the user created:
>> accounts::account { 'iambot': }
>>
>> But with Grundic's it seems you have to add an accounts::account block to
>> the yaml above:
>> accounts::account:
>> iambot:
>> groups:
>> - Staff
>> authorized_keys:
>> - iambot
>>
>> Is that right?
>>
>> Anyway, I can get around the stack level error by replacing the contents
>> of the *ssh_authorized_key_title* with something "static", but would
>> prefer to have it as is.
>>
>> Any ideas? ;-/
>>
>> Thanks a lot,
>> 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/47654e48-2065-4788-a4eb-213711c2fdb4%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/CABnTgtVk7nbi7TTMrB5un-eu%2Bz%3DVHcLAjRsUquvH3EqTZkB-Yg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: camptocamp/grundics accounts module
Guy,
It looks like grundics's accounts is just a fork of camptocamp's one. So
unless you need grundics's features I recommend you to use camptocamp's
version.
We are actually including the declaration of the accounts class in a base
profile class included in all ours roles.
Regards,
Mickaël
Le lundi 19 janvier 2015 16:27:20 UTC+1, Guy Matz a écrit :
>
> Mickaël,
> Thanks for the reply!! Is there an updated version of the module that you
> recommend I use?
>
> One other thing . . . where do you put the class block that pulls in the
> hiera data?
>
> Thanks a lot!
> Guy
>
> On Sun, Jan 18, 2015 at 1:23 AM, Mickaël Canévet > wrote:
>
>> If you still want to use *ssh_authorized_key_title*, you have some
>> examples in unit tests.
>>
>> Le vendredi 16 janvier 2015 18:40:06 UTC+1, guymatz a écrit :
>>>
>>> Is anyone using camptocamp or grundic's accounts module? I can't it
>>> working and am at my wit's end!
>>>
>>> my problem is with the ssh_authorized_key_title . . . I'm getting the
>>> error:
>>> Error 400 on SERVER: stack level too deep at
>>> /etc/puppet/modules/accounts/manifests/authorized_key.pp:35
>>>
>>> But I think I have everything set up correctly:
>>> In my modules/profiles/manifests/base.pp I have:
>>> class { 'accounts':
>>> groups => hiera_hash('accounts::groups', {}),
>>> ssh_keys => hiera_hash('accounts::ssh_keys', {}),
>>> users=> hiera_hash('accounts::users', {}),
>>> usergroups => hiera_hash('accounts::usergroups', {}),
>>> accounts => hiera_hash('accounts::accounts', {}),
>>> *ssh_authorized_key_title =>
>>> '%{ssh_keys[\'%{ssh_key}\'][\'comment\'] on %{user}',*
>>> dotfiles => hiera_hash('accounts::dotfiles', {}),
>>> }
>>>
>>> So that should put all of that info into my run, yes? Is there a better
>>> place to put that?
>>>
>>> Then in hiera I have:
>>> $ more hieradata/common_users.eyaml
>>> accounts::ssh_keys:
>>> iambot:
>>> comment: iambot@somewhere
>>> type: ssh-dss
>>> public: public_key
>>>
>>> accounts::users:
>>> iambot:
>>> uid: 10079
>>> gid: 10022
>>> comment: I am a Bot
>>>
>>> accounts::groups:
>>> Staff:
>>> gid: 10022
>>>
>>> It seems that with camptocamp's implementation you then need to call
>>> accounts::account like this to get the user created:
>>> accounts::account { 'iambot': }
>>>
>>> But with Grundic's it seems you have to add an accounts::account block
>>> to the yaml above:
>>> accounts::account:
>>> iambot:
>>> groups:
>>> - Staff
>>> authorized_keys:
>>> - iambot
>>>
>>> Is that right?
>>>
>>> Anyway, I can get around the stack level error by replacing the contents
>>> of the *ssh_authorized_key_title* with something "static", but would
>>> prefer to have it as is.
>>>
>>> Any ideas? ;-/
>>>
>>> Thanks a lot,
>>> 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...@googlegroups.com .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/47654e48-2065-4788-a4eb-213711c2fdb4%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/5a346b3e-53bd-40a0-8ae3-28a9a7491cac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] concurrent r10k runs?
Hello, Wondering if anyone knows if r10k handles concurrent runs of r10k gracefully? Sort of the way running puppet agent from the command line will detect if a run has already been kicked off via the daemon? The use case I'm thinking of is: dynamic r10k run after git branch is updated as is popular, plus a periodic r10k run via cron to discourage people from getting too comfortable making changes directly in the environments directory (since they know that their changes will be regularly 'lost' that way, as opposed to lost at some unknown, possibly relatively distant future time from the change, after another change goes through proper channels... and likely gets the blame for whatever timebomb was left by the improper change...) This opens up the potential for a cron run and a git push to execute r10k concurrently, and I was wondering if anyone knows what can be expected in this case? [ I know the better way is probably more tightly controlled access to the environments directory, but for belt-and-suspenders, does anyone deploy with r10k and cron on a schedule? ] Thanks, W. -- 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/011e02bf-0727-4d15-aca5-e8b8583c9f5e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Announce: Puppet Server 1.0.2 available!
Hi everybody, does somebody already use the puppet server at all? Can you share your experiences? Best Regards Oli -- 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/20150119154355.181e2b73%40dickeberta.automatic-server.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
Re: [Puppet Users] Override facts from facter
On 01/12/2015 03:55 PM, Felix Frank wrote: > I think the issue is that facter/util is not supposed to be pluggable > this way. Custom facts live in lib/facter/*.rb and that's the extent of > it. I may be mistaken, but it seems consistent to me that this will not > work. Hi, I just found that this is most likely a false assumption of mine. https://github.com/puppetlabs/puppetlabs-stdlib/tree/master/lib/facter/util So, yeah, that should work. Although I'm still not sure what Ruby will do if you sync a file to util/ that is also present in the system wide facter/util/ tree. It's likely safer to give unique names to your fact code files, except when you are overriding existing facts (not their utility functions, mind). Best, Felix -- 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/54BD2D92.90408%40alumni.tu-berlin.de. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Override facts from facter
Mmmh it still doesn't work for me :( As a workaround, I created another fact which just executes the "partitions" fact and then add the labels to the appropriate partions. My PR was accepted :) so I've just to wait a new upstream version to remove the workaround. Anyway if you (or anybody) find some way to properly override a complex fact, keep me informed! Thanks for your time On Mon, Jan 19, 2015 at 5:15 PM, Felix Frank wrote: > On 01/12/2015 03:55 PM, Felix Frank wrote: >> I think the issue is that facter/util is not supposed to be pluggable >> this way. Custom facts live in lib/facter/*.rb and that's the extent of >> it. I may be mistaken, but it seems consistent to me that this will not >> work. > > Hi, > > I just found that this is most likely a false assumption of mine. > > https://github.com/puppetlabs/puppetlabs-stdlib/tree/master/lib/facter/util > > So, yeah, that should work. Although I'm still not sure what Ruby will > do if you sync a file to util/ that is also present in the system wide > facter/util/ tree. It's likely safer to give unique names to your fact > code files, except when you are overriding existing facts (not their > utility functions, mind). > > Best, > Felix > > -- > 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/54BD2D92.90408%40alumni.tu-berlin.de. > 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/CAKsfaEbU6TkdaUGbCmSme26SMyCP0LtEzQPzJSjZ6Buo6K8-aA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Austin Puppet Users Group - looking for speakers - 2nd Tuesday of each month
We're looking for people who would like to show up to the ATXPUG meetup and share some of their puppet stories - integration, installations, tips, tweaks, lessons learned or anything related to configuration management & puppet. Our next meetup is February 10th and we would love to schedule in anyone who would like to share with the community. Food & Drinks are provided at meetup and speakers will get a little extra something. If you will be in town for the weekend or live in Austin and would like to join the register with us at Meetup.com and drop a note on the forum - http://www.meetup.com/Austin-Puppet-User-Group/messages/boards/thread/48650150 Thanks all! http://www.atxpug.org -- 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/8e267a1b-a1e7-471a-aa72-c4de72db00fc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] concurrent r10k runs?
- Original Message - | Hello, | Wondering if anyone knows if r10k handles concurrent runs of r10k gracefully? | Sort of the way running puppet agent from the command line will detect if a | run has already been kicked off via the daemon? | The use case I'm thinking of is: dynamic r10k run after git branch is updated | as is popular, plus a periodic r10k run via cron to discourage people from | getting too comfortable making changes directly in the environments | directory (since they know that their changes will be regularly 'lost' that | way, as opposed to lost at some unknown, possibly relatively distant future | time from the change, after another change goes through proper channels... | and likely gets the blame for whatever timebomb was left by the improper | change...) | This opens up the potential for a cron run and a git push to execute r10k | concurrently, and I was wondering if anyone knows what can be expected in | this case? | [ I know the better way is probably more tightly controlled access to the | environments directory, but for belt-and-suspenders, does anyone deploy with | r10k and cron on a schedule? ] | Thanks, | W. | -- | 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/011e02bf-0727-4d15-aca5-e8b8583c9f5e%40googlegroups.com | . | For more options, visit https://groups.google.com/d/optout . We use a lock file to ensure that only one R10K run can operate at a time. R10K does not work in a concurrent manner in our testing. -- James A. Peltier IT Services - Research Computing Group Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpelt...@sfu.ca Website : http://www.sfu.ca/itservices Twitter : @sfu_rcg Powering Engagement Through Technology "Build upon strengths and weaknesses will generally take care of themselves" - Joyce C. Lock -- 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/974438063.35588977.1421694391587.JavaMail.zimbra%40sfu.ca. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Partial management of /etc/hosts.allow / Augeas and Arrays
Thank you very much for your suggestion, Ian! I honestly didn't know that was possible, so I will give that a whirl when I get back to the office, and happily let you know if this has resulted in the desired end result! Thanks again for your insight, Ian! -- 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/5051b415-d6e8-447c-a4ab-c489f6257961%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
