date:20131206

[Puppet Users] help dependency packages

2013-12-06 Thread Rafael Tomelin

Hi,

Which option do I use to force installation of dependencies of a package?

Made as follows, but appears me an error:

CONF
package {"bacula-common":
Ensure => installed,
 force => true,
}


ERROR
puppet agent - test
Info: Retrieving plugin
Info: Loading facts in / var / lib / puppet / lib / facter / facter_dot_d.rb
Info: Loading facts in / var / lib / puppet / lib / facter / pe_version.rb
Info: Loading facts in / var / lib / puppet / lib / facter / root_home.rb
Info: Loading facts in / var / lib / puppet / lib / facter /
puppet_vardir.rb
Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Invalid parameter force at / etc / puppet / modules / bacula-server /
manifests / init.pp: 10 on node srvbkp.teclinux.com
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run




What can be this error?


-- 
Att,
Rafael Tomelin
Tel.: 51-84104084
Skype: rafael.tomelin

LPI ID: LPI000191271

-- 
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/CAGEUqbD8NWgHPipkWv6opZO0jF3WqVSDp9abiONDh9hdG%3DS8Mg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Hiera user account info

2013-12-06 Thread Dan White

OK.  Now that I have had a chance to look at the torrancew/account module, I 
can make some (I hope) helpful suggestions:

My own user-account class implementation (class users) is very similar with the 
following exceptions:

I have a base-user-account defined type that creates users.

I use it two ways: one way for basic users, and a second way for sysadmin users 
(adding group “wheel”)

Each of these are called up like this:

$admin_accounts = hiera_hash ('sysadmin', false)
if $admin_accounts {
create_resources ( users::useraccount, $admin_accounts )
} 

$developer_accounts = hiera_hash (‘developers', false)
if $admin_accounts {
create_resources ( users::useraccount, $developer_accounts )
} 

Part of the “magic” of my design is one of the default values for the defined 
type:

define users::useraccount (
$username= $name,
...
$ensure  = absent,
)

Now for the hiera :
Here’s my /etc/puppet/hiera.yaml (simplified a bit):

---
:hierarchy:
  - %{fqdn}/%{module_name}
  - %{module_name}
  - %{fqdn}
  - common
:backends:
  - yaml
:yaml:
  :datadir: '/etc/puppet/hieradata'
:merge_behavior: deeper

# vim: ft=yaml:sts=2:sw=2:et


So it works like this:

In /etc/puppet/hieradata/users.yaml, I define all the users for the entire 
network

——-
#
# set “ensure: present” for sysadmins because they need a login on all systems
#
sysadmin:
  smithj:
uid : 5001  
comment : Smith, Joe, x1234 
groups  :
  - wheel 
ensure  : present 
  jonesf:
uid : 5002  
comment : Jones, Fred, x2345 
groups :
  - wheel 
ensure   : present 

#
# All we need here is name, uid, and comment-info
#
developers:
  smitht:
uid : 6001  
comment : Smith, Tom, x2234 
  jonesc:
uid : 6002  
comment : Jones, Cynthia, x9345 

Now for the “deep” magic: /etc/puppet/hieradata/host1.example.com/users.yaml, I 
specify the non-admin users who need a login:

——-
developers:
  smitht:
ensure   : present 
groups :
  - webdev
 
The neat thing is that you can add host-specifics to the user account - like 
extra groups

Does that help ?

This is about a quarter of the tricks I came up with in my users module.
Other junk includes :
role accounts and restricted ssh logins (“from” and “command” options in the 
${role_account_home}/.ssh/authorized_keys file)
A way to keep the ssh keys out of the hiera-data to keep the files human 
readable

This is my response to the "Unpleasant puppetlabs experience” Thread.  I am 
happy to share what I have tinkered together.

On Dec 6, 2013, at 5:23 PM, Guy Knights  wrote:

> We're working on implementing hiera with our puppet 3 setup, and I'm curious 
> if the following is achievable. Currently, we manage each user account within 
> a class that realises a defined resource that creates the user, groups, etc 
> (for the record, we use the torrancew/account module). We then have classes 
> called groups:: where we pull in all the user classes we want in 
> a specific manifest.
> 
> What I would like to do is move all the user info into hiera, and thus move 
> from 'groups' as we currently define them, to user accounts created according 
> to their position in the hierarchy. Unfortunately, I'm having trouble working 
> out how to do this. I could set up a hash within hiera and then use the 
> account module to create users from this hash, but I don't think it's 
> possible to create a batch of resources with differing attributes (primarily 
> the ssh key, but possibly others) using one resource.
> 
> I don't really want to have to pull all the resource setup out of the account 
> module since it makes things simpler for us, is there any other way to get 
> the result I'm after?
> 
> 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/5121DC45-940E-475A-98CC-4E36B948BD48%40comcast.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: Unable to specify hierarchy for data-in-modules

2013-12-06 Thread R.I.Pienaar

hello,

I will be releasing a module on the forge with this functionality, but need 
some 
early testers as I do not currently have a varied environment to test against.

Those interested please contact me off list or if you're brave just download
the ripienaar/module_data module into your manifests, it auto activates and 
needs
no config.

Though this is 0.0.1 release no doubt will kill your kitten.

- Original Message -
> From: "chengkai liang" 
> To: puppet-users@googlegroups.com
> Sent: Friday, December 6, 2013 6:25:06 PM
> Subject: Re: [Puppet Users] Re: Unable to specify hierarchy for 
> data-in-modules
> 
> It is nice to mention this here.
> 
> Thanks,
> -Chengkai
> 
> 
> On Thu, Dec 5, 2013 at 6:18 PM, Henrik Lindberg <
> henrik.lindb...@cloudsmith.com> wrote:
> 
> > On 2013-06-12 1:30, chengkai liang wrote:
> >
> >> Well, I can execute this with for individual module via *puppet apply
> >> --binder true ...* I haven't been able to do this successfully on my
> >>
> >> vagrant box.  I found out that vagrant use --detailed-exitcode option
> >> with puppet apply, which interfere with *--binder true* option.  I have
> >> to set*binder true* in puppet.conf.  Yet I don't have time to try that
> >> yet.
> >>
> >>
> >>
> >> On Sat, Nov 30, 2013 at 11:03 AM, Steven Jonthen
> >> mailto:coffeejunkeyst...@gmail.com>> wrote:
> >>
> >
> > Please be aware that we decided to not move ahead with the "data in
> > modules" implementation based on the experimental implementation that is
> > turned on with --binder=true option.
> >
> > We found several things - there was way too much complexity being exposed
> > to users, the first implementation missed support for some typical use
> > cases, and the entire domain of "providing data to modules" turned out to
> > be an exchange of one problem for another in several cases.
> >
> > Meanwhile, if you are brave, and want to experiment. You probably want my
> > branches with simplifications and additional support for private data. If
> > for nothing else to gain some experience regarding some of the issues.
> > (Since we decided not to move ahead, these additions & changes will not be
> > merged into the puppet code base, and the behavior now available via
> > --binder will be removed - we have not quite yet figured out what it will
> > be replaced by though).
> >
> > Regards
> > - henrik
> >
> >
> > --
> > You received this message because you are subscribed to a topic in the
> > Google Groups "Puppet Users" group.
> > To unsubscribe from this topic, visit https://groups.google.com/d/
> > topic/puppet-users/Z_6ehvPEm98/unsubscribe.
> > To unsubscribe from this group and all its topics, 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/l7rc5f%24jbs%241%40ger.gmane.org.
> >
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> 
> --
> 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/CANTbHr8NTCAspOEm9gT1xTtYOBBe_k4w_fK92foht1heikhjXA%40mail.gmail.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 

-- 
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/1021960233.953.1386370777066.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Hiera user account info

2013-12-06 Thread Guy Knights

We're working on implementing hiera with our puppet 3 setup, and I'm
curious if the following is achievable. Currently, we manage each user
account within a class that realises a defined resource that creates the
user, groups, etc (for the record, we use the torrancew/account module). We
then have classes called groups:: where we pull in all the user
classes we want in a specific manifest.

What I would like to do is move all the user info into hiera, and thus move
from 'groups' as we currently define them, to user accounts created
according to their position in the hierarchy. Unfortunately, I'm having
trouble working out how to do this. I could set up a hash within hiera and
then use the account module to create users from this hash, but I don't
think it's possible to create a batch of resources with differing
attributes (primarily the ssh key, but possibly others) using one resource.

I don't really want to have to pull all the resource setup out of the
account module since it makes things simpler for us, is there any other way
to get the result I'm after?

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/8e5cfb5e-9146-4c7d-8079-68075f8cbaa1%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

45 matches

Mail list logo