Re: [Puppet Users] how to customize hiera lookups per node?

2013-03-19 Thread Darryl Wisneski 
On Thu, Mar 07, 2013 at 12:11:09PM -0800, James Ralston wrote:
 
 At this point, all of the modules we have written use parameterized 
 classes. That way, when we call the module from the host's node.pp file, we 
 can override defaults (if necessary).
 

I lump all nodes into the node default and send all hosts thru one
manifest.  It processes thru a hash of hashes derived from one yaml
file with lookups based on ${hostname} only.  There is no parameterized
classes in use.  $hostname is the only fact in use; we don't trust
the nodes facts.

node default {
include processhosts
}

 
 The main thing we're trying to understand is how each host manifest can 
 declare its own hiera hierarchy for data lookup. We can't do this with the 
 yaml backend, because the yaml backend will apply the same hierarchy to 
 EVERY client, because all Puppet clients use the /etc/puppet/hiera.yaml 
 file on the puppetmaster. Granted, we can customize the hierarchy on the 
 puppetmaster with facter facts, but that doesn't give us enough control.
 

You can use one yaml file for all hosts to accomplish the above.  

$ more hiera.yaml
---
:backends:
 - yaml
:hierarchy:
 - %{hostname}
 - common

I could overlay individual hostname.yaml files but I just keep the
hash of hashes in one yaml file, common.yaml.

$ more hieradata/common.yaml
servers :
  node-a :
sshd_auth: local
ClientAliveInterval: nil
ClientAliveCountMax: nil
server_role: site-server
location: []
smtp-server: nil
  node-b :
sshd_auth: local
ClientAliveInterval: nil
ClientAliveCountMax: nil
server_role: site-server
location: []
smtp-server: nil
  node-c :
sshd_auth: ldap
ClientAliveInterval: nil
ClientAliveCountMax: nil
server_role: linux-site-server
location: []
smtp-server: postfix


$ more modules/processhosts/manifests/init.pp

 class processhosts {

$all_data = hiera_hash('servers')
$node_data = $all_data[$hostname]

$sshd_type = $node_data['sshd_auth']
$server_role = $node_data['server_role']
$ClientAliveInterval = $node_data['ClientAliveInterval']
$ClientAliveCountMax = $node_data['ClientAliveCountMax']
$location = $node_data['location']
$smtp = $node_data['smtp-server']

notice my name is $hostname and I am using hiera from YAML
notice ( setting sshd_type:  $sshd_type )

case $server_role {
site-server: {
notice ${hostname} is a site-server
}
linux-site-server: {
notice ${hostname} is a linux-site-server
}
linux-site-vm: {
notice ${hostname} is a linux-site-vm
include pkg::apt
}
general: {
notice ${hostname} is a general-server
}
fbsdhost: {
notice ${hostname} is a fbsdhost
include admin::snmpd
}
nil: {
notice ${hostname} is a server of undefined type
}
default: {
notice ${hostname} is a server of undefined type and not 
nil
}
}

case $mysudo {
'': {
include admin::sudo
}
}

}

The processhosts module imports other manifests based on the hostname
lookup of the 'servers' hash of hashes in common.yaml.  This has
proven to be sane and flexible.  If the node isn't defined in the
common.yaml, you get a catalog error err: Could not retrieve
catalog from remote server:.  

Regards,
-dkw

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: Hiera, Hashes, and Create_resources

2013-02-06 Thread Darryl Wisneski 
On Mon, Aug 27, 2012 at 08:10:34AM -0700, jcbollinger wrote:
# cat common.yaml 
--- 
searchdomain: 'example.com' 
ssh_auth: ldap 
servers : 
  server-a   : 
sshd_auth: local 
ClientAliveInterval: nil 
ClientAliveCountMax: nil 
  server-b   : 
sshd_auth: local 
ClientAliveInterval: nil 
ClientAliveCountMax: nil 
  server-c   : 
sshd_auth: ldap 
ClientAliveInterval: nil 
ClientAliveCountMax: nil 
  server-d   : 
sshd_auth: ldap 
ClientAliveInterval: 10 
ClientAliveCountMax: 3 


 Furthermore, you may be approaching this altogether the wrong way.  If it 
 is part of the nature of sshd_lookup that no node will ever need to declare 
 more than one instance, then sshd_lookup should probably be a class instead 
 of a definition:

 
 class sshd_lookup { 
 
 $all_data = hiera_hash('servers')
 $node_data = $all_data[$hostname]
 
 $sshd_auth = $node_data['sshd_auth']
 $ClientAliveInterval = $node_data['ClientAliveInterval']
 $ClientAliveCountMax = $node_data['ClientAliveCountMax']
 $server_role = $node_data['server_role']
 $location = $node_data['location']
 $sshd_type = $data[$hostname]['sshd_auth']
 
 # ...
 } 
 

Hi:

I've been in a hole for while now and my puppet setup was working
(albeit, very inefficiently and harder to read) until I upgraded
recently, to puppet 3.0.x, so I came back to this thread.

This approach of getting the entire hash out of the YAML via hiera
from a class (as detailed above) instead of a defined type solved
my problem and is much more elegant.

I am still configuring all my hosts in a single YAML file Hash of
Hashes (HoH).  You questioned the approach and here it is:

1.) All hosts are in the node default 

2.) The node default calls a single master module which parses the
YAML HoH based on the facter hostname and performs role logic in
puppet DSL and calls every other necessary module/manifest as the
roles dictate.  Every node is fully defined for every variable in
the YAML file.  Only this module should have configuration data in it.
I suppose it could use ruby DSL if we wanted to here also.

node default -- master_module w/ YAML HOH lookup and role logic
-- other modules (dns, ssh, ldap, sudo)

The only other module/manifest I haven't been able to remove
configuration data from is local ssh users, ssh keys etc.  I suppose
I could place users and ssh keys in another YAML file of structured
data.

Thanks,

-dkw

 
 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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Hiera, Hashes, and Create_resources

2012-08-17 Thread Darryl Wisneski 
Howdy:

I need some help please to get hiera configuration data derived
from YAML, thru puppet.  I have studied Internet search results and
puppet documentation on create_resources and custom defines but
need a little help along.  I can print out the YAML from variables,
arrays, and, finally, hashes too from a puppet manifest.

One thing that is stumping me is how to access from the custom
define only the YAML element of server-a which is I believe is an
object of an array of hashes as I have the YAML laid out.  

When I run this on client host server-a against the manifest this prints out in 
the log:

Aug 17 12:59:09 puppet puppet-master[67407]: (Scope(Sshd_lookup[server-a])) 
setting sshd_type:  local
Aug 17 12:59:09 puppet puppet-master[67407]: (Scope(Sshd_lookup[server-b])) 
setting sshd_type:  local
Aug 17 12:59:09 puppet puppet-master[67407]: (Scope(Sshd_lookup[server-c])) 
setting sshd_type:  local
Aug 17 12:59:09 puppet puppet-master[67407]: (Scope(Sshd_lookup[server-d])) 
setting sshd_type:  local

I want it to print out just server-a's value.  How do I do that?
Also, interestingly, it printed out each of the server names (keys?)
in the hash but the value of the server-a's sshd_auth entry.

My YAML, puppet manifest and error follow.

# cat common.yaml 
---
searchdomain: 'example.com'
ssh_auth: ldap
servers :
  server-a   :
sshd_auth: local
ClientAliveInterval: nil
ClientAliveCountMax: nil
  server-b   :
sshd_auth: local
ClientAliveInterval: nil
ClientAliveCountMax: nil
  server-c   :
sshd_auth: ldap
ClientAliveInterval: nil
ClientAliveCountMax: nil
  server-d   :
sshd_auth: ldap
ClientAliveInterval: 10
ClientAliveCountMax: 3


# cat ../hiera.yaml
---
:backends: 
 - yaml

:logger: console

:hierarchy: 
 - %{hostname}
 - common

:yaml:
 :datadir: /usr/local/etc/puppet/hieradata



# cat Inuit.pp
class user {
$sshd_hash = hiera(servers)
create_resources('sshd_lookup', $sshd_hash)

}

   define sshd_lookup ( $sshd_auth, $ClientAliveInterval, $ClientAliveCountMax,
$server_role, $location ) {

$data = hiera_hash('servers')
$sshd_type = $data[$hostname]['sshd_auth']

notice (setting sshd_type:  $sshd_type )

}


Thanks,
Regards,
-dkw

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] hiera questions

2012-07-02 Thread Darryl Wisneski 
On Thu, Jun 28, 2012 at 08:04:09PM +0100, R.I.Pienaar wrote:
 I would make facts on the nodes for these.  Let say $role and $subrole
 and then just use those in your hierarchy with %{role} and %{subrole} 
 thus allowing you to set variable for all those machines there.

Howdy:

I was wondering what is the best way to manage custom facts for a
disparate group of servers that need to report different fact values
for the same fact name?  I am about to embark on hiera-based puppet
architecture and want to archetect it only once.  I have some doubts
about the recommended ways of rolling out facter as it can get messy
burying facter server host configuration logic in disparate modules.

Let's say you want to create only one custom fact script to manage
all your facts based on data center location and functional server
host grouping.  You decide you can manage all your custom facts
from one ruby/facter script if you create a ruby function using a
hash with your facter matching hostnames loaded in the hash as the
key and you can lookup location and function.  Now you have to
choose which module to roll it from, but it's arbitrary.

Would one hash in a single custom facter script be enough configuration
for the all the hosts?  I argue it would as you can add rows and
columns to the hash, so it should be able to support all your facter
needs.  Either using custom facts or loading in all your hosts into
a hiera hash, you still have to know your hostnames.

However, why bury your custom facter script in a module with all
the configuration in there too?  The current architecture and
directed use of facter alongside puppet/hiera seems to go against
the nature of moving your configuration out of manifests as the
direction of puppet/hiera is headed now.

I was thinking of creating a hiera hash or two (I am using YAML so
far.  I could use as many hashes as required but one should be
enough probably, plus any arrays), including the information/configuration,
grouping servers by location and function, minimally.  In my puppet
modules I can use hiera to call up my hash and create ruby/puppet
functions to do the server host location and functional logic based
on the default facter facts of hostname and operatingsystem reported
by the server host themselves.  All the configuration remains in
hiera and the module manifests remain puppet business logic.  

Comments?  

Regards,
-dkw

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] hiera questions

2012-07-02 Thread Darryl Wisneski 
On Mon, Jul 02, 2012 at 10:13:51PM +0200, Jan Ivar Beddari wrote:
 On 02. juli 2012 17:26, Darryl Wisneski wrote:
 
  Regards,
  -dkw
 
 Ouch, sorry Darryl, I hit the wrong button and posted what I thought of 
 as a private very quick reply to you .. right on the list.

Jan:

I too am sorry I stole the thread.  I had best intentions, alas I
got carried away.  I am interested in learning how you structured
your hiera data and dealt with puppet code with the use of no/limited
facts.

The security point is well taken.  At some point though, there has
to be trust (obviously).  General security best-practice considers
mitigating procedures (such as IDS, file integrity monitoring (aide),
and regular patching) your best attempt to avoid placing too much
trust in the management tool.  

Regards,
-dkw

 
 Now at least everyone sees my honest-to-god thoughts on the matter. And 
 the scope of the message becomes a bit more broad. Might even be worth 
 starting a new thread.
 
 To the OP, sorry for being such a thread crasher. As to your question I 
 think the answers you got are OK but hopefully you understand what 
 caveats there might be security-wise.
 
 best,
 Jan Ivar
 
 -- 
 http://www.uib.no/personer/Jan.Ivar.Beddari
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Puppet Users group.
 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to 
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/puppet-users?hl=en.
 

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] augeas-0.10.0_1 in FreeBSD can't see /etc/rc.conf

2012-05-01 Thread Darryl Wisneski 
Howdy:

Since I upgraded some of my FreeBSD boxen to augeas-0.10.0* I can't
get augeas to address /etc/rc.conf.  I was able to modify key/values
in /etc/rc.conf in augeas-0.7.1_2 in my puppet classes and augtool.
I think I recall Dominic saying that the /etc/rc.conf lens was added
by the FreeBSD ports maintainer.  Can you help please?  I just
refreshed my ports tree (portsnap fetch extract) and remade augeas.
The checksums on the lens files has not changes between versions.
I am seeing this behavior in FreeBSD 8.2 and 9.0 RELEASE.

# pwd
/usr/ports/textproc/augeas
# make deinstall reinstall clean

Here is the output of augtool:

broken:

# pkg_info |grep augeas
augeas-0.10.0_1 A configuration editing tool

# find  /usr/local/share/augeas/lenses/ -name *rcconf* -exec sum {} \; 
29678 1 /usr/local/share/augeas/lenses/tests/rcconf.aug
13563 1 /usr/local/share/augeas/lenses/rcconf.aug

# augtool 
augtool print /files/etc/rc.conf
augtool 


works:

# pkg_info |grep augeas
augeas-0.7.1_2  A configuration editing tool

$  find  /usr/local/share/augeas/lenses/ -name *rcconf* -exec sum {} \; 
13563 1 /usr/local/share/augeas/lenses/rcconf.aug
29678 1 /usr/local/share/augeas/lenses/tests/rcconf.aug

# augtool 
augtool print /files/etc/rc.conf
/files/etc/rc.conf
/files/etc/rc.conf/cloned_interfaces = lagg0 vlan502 vlan503 tap0
[snip]
/files/etc/rc.conf/ifconfig_em0 = up
/files/etc/rc.conf/ifconfig_em1 = up
/files/etc/rc.conf/ifconfig_lagg0 = up laggproto failover laggport em0 
laggport em1
/files/etc/rc.conf/openssh_enable = YES
/files/etc/rc.conf/ntpd_enable = YES
/files/etc/rc.conf/ntpd_sync_on_start = YES
/files/etc/rc.conf/nrpe2_enable = YES
/files/etc/rc.conf/sendmail_enable = NONE
/files/etc/rc.conf/tmpmfs = YES
/files/etc/rc.conf/postgresql_enable = YES
/files/etc/rc.conf/puppet_enable = YES
/files/etc/rc.conf/snmpd_enable = YES
/files/etc/rc.conf/pf_enable = YES
/files/etc/rc.conf/jail_enable = YES
[snip]

Thanks,
-dkw

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: augeas-0.10.0_1 in FreeBSD can't see /etc/rc.conf

2012-05-01 Thread Darryl Wisneski 
Hi Steve:

On Tue, May 01, 2012 at 02:15:25PM -0400, Steve Wills wrote:
 Hi,
 
 Thanks for the info. Something is definitely not right, but it doesn't
 seem to work for me even with the older version:
 
 It looks like the problem is that the fix in ticket 255:
 
 https://fedorahosted.org/augeas/ticket/255
 https://fedorahosted.org/augeas/changeset/95515f45adf192ab10e6c6ffbd69b5977a9f78b2/
 

The patch worked but the rc.conf potentially needs double quotes
on the RHS, or value.  No?  It seems this functionality conflicts
with the resolution of ticket 255.

-dkw


 is not included in the current release. That's OK, I can patch it in. See
 attached patch. With this, I get:
 
 % augtool --version
 augtool 0.10.0 http://augeas.net/
 Copyright (C) 2007-2011 David Lutterkort
 License LGPLv2+: GNU LGPL version 2.1 or later
  http://www.gnu.org/licenses/lgpl-2.1.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.
 
 Written by David Lutterkort
 % augtool print /files/etc/rc.conf
 /files/etc/rc.conf
 /files/etc/rc.conf/keymap = \us.pc-ctrl\
 /files/etc/rc.conf/sshd_enable = \YES\
 [snip]
 %
 
 If this works for you, I'll go ahead and commit this.
 
 Thanks,
 Steve
 
  Howdy:
 
  Since I upgraded some of my FreeBSD boxen to augeas-0.10.0* I can't
  get augeas to address /etc/rc.conf.  I was able to modify key/values
  in /etc/rc.conf in augeas-0.7.1_2 in my puppet classes and augtool.
  I think I recall Dominic saying that the /etc/rc.conf lens was added
  by the FreeBSD ports maintainer.  Can you help please?  I just
  refreshed my ports tree (portsnap fetch extract) and remade augeas.
  The checksums on the lens files has not changes between versions.
  I am seeing this behavior in FreeBSD 8.2 and 9.0 RELEASE.
 
  # pwd
  /usr/ports/textproc/augeas
  # make deinstall reinstall clean
 
  Here is the output of augtool:
 
  broken:
 
  # pkg_info |grep augeas
  augeas-0.10.0_1 A configuration editing tool
 
  # find  /usr/local/share/augeas/lenses/ -name *rcconf* -exec sum {} \;
  29678 1 /usr/local/share/augeas/lenses/tests/rcconf.aug
  13563 1 /usr/local/share/augeas/lenses/rcconf.aug
 
  # augtool
  augtool print /files/etc/rc.conf
  augtool
 
 
  works:
 
  # pkg_info |grep augeas
  augeas-0.7.1_2  A configuration editing tool
 
  $  find  /usr/local/share/augeas/lenses/ -name *rcconf* -exec sum {} \;
  13563 1 /usr/local/share/augeas/lenses/rcconf.aug
  29678 1 /usr/local/share/augeas/lenses/tests/rcconf.aug
 
  # augtool
  augtool print /files/etc/rc.conf
  /files/etc/rc.conf
  /files/etc/rc.conf/cloned_interfaces = lagg0 vlan502 vlan503 tap0
  [snip]
  /files/etc/rc.conf/ifconfig_em0 = up
  /files/etc/rc.conf/ifconfig_em1 = up
  /files/etc/rc.conf/ifconfig_lagg0 = up laggproto failover laggport em0
  laggport em1
  /files/etc/rc.conf/openssh_enable = YES
  /files/etc/rc.conf/ntpd_enable = YES
  /files/etc/rc.conf/ntpd_sync_on_start = YES
  /files/etc/rc.conf/nrpe2_enable = YES
  /files/etc/rc.conf/sendmail_enable = NONE
  /files/etc/rc.conf/tmpmfs = YES
  /files/etc/rc.conf/postgresql_enable = YES
  /files/etc/rc.conf/puppet_enable = YES
  /files/etc/rc.conf/snmpd_enable = YES
  /files/etc/rc.conf/pf_enable = YES
  /files/etc/rc.conf/jail_enable = YES
  [snip]
 
  Thanks,
  -dkw
 

 Index: Makefile
 ===
 RCS file: /home/pcvs/ports/textproc/augeas/Makefile,v
 retrieving revision 1.10
 diff -u -r1.10 Makefile
 --- Makefile  25 Apr 2012 01:11:34 -  1.10
 +++ Makefile  1 May 2012 18:09:53 -
 @@ -8,7 +8,7 @@
  
  PORTNAME=augeas
  PORTVERSION= 0.10.0
 -PORTREVISION=1
 +PORTREVISION=2
  CATEGORIES=  textproc
  MASTER_SITES=http://augeas.net/download/
  
 @@ -38,7 +38,6 @@
  
  post-install:
   ${MKDIR} ${LENSESDIR}/tests
 - ${INSTALL_DATA} ${FILESDIR}/rcconf.aug ${LENSESDIR}/rcconf.aug
   ${INSTALL_DATA} ${FILESDIR}/test_rcconf.aug 
 ${LENSESDIR}/tests/rcconf.aug
  
  .include bsd.port.mk
 Index: pkg-plist
 ===
 RCS file: /home/pcvs/ports/textproc/augeas/pkg-plist,v
 retrieving revision 1.2
 diff -u -r1.2 pkg-plist
 --- pkg-plist 12 Feb 2012 13:17:44 -  1.2
 +++ pkg-plist 1 May 2012 18:09:53 -
 @@ -231,7 +231,6 @@
  %%DATADIR%%/lenses/dist/xml.aug
  %%DATADIR%%/lenses/dist/xorg.aug
  %%DATADIR%%/lenses/dist/yum.aug
 -%%DATADIR%%/lenses/rcconf.aug
  %%DATADIR%%/lenses/tests/rcconf.aug
  share/vim/vimfiles/ftdetect/augeas.vim
  share/vim/vimfiles/syntax/augeas.vim
 Index: files/patch-lenses__shellvars.aug
 ===
 RCS file: files/patch-lenses__shellvars.aug
 diff -N files/patch-lenses__shellvars.aug
 --- /dev/null 1 Jan 1970 00:00:00 -
 +++ files/patch-lenses__shellvars.aug 1 May 2012 18:09:53 -
 @@ -0,0 +1,10 @@
 +--- ./lenses/shellvars.aug.orig  2012-05-01

Re: [Puppet Users] augeas-0.10.0_1 in FreeBSD can't see /etc/rc.conf

2012-05-01 Thread Darryl Wisneski 
Hi Dominic:

On Tue, May 01, 2012 at 09:01:16PM +0100, Dominic Cleal wrote:
 Hi Darryl,
 
 On 01/05/12 16:11, Darryl Wisneski wrote:
  Since I upgraded some of my FreeBSD boxen to augeas-0.10.0* I can't
  get augeas to address /etc/rc.conf.  I was able to modify key/values
  in /etc/rc.conf in augeas-0.7.1_2 in my puppet classes and augtool.
  I think I recall Dominic saying that the /etc/rc.conf lens was added
  by the FreeBSD ports maintainer.  Can you help please?  I just
  refreshed my ports tree (portsnap fetch extract) and remade augeas.
  The checksums on the lens files has not changes between versions.
  I am seeing this behavior in FreeBSD 8.2 and 9.0 RELEASE.
 
 There are a few overlapping issues with /etc/rc.conf.  There is indeed a
 lens shipped with the FreeBSD port which you're seeing here.  In Augeas
 0.8.1, rc.conf was added to the Shellvars lens shipped with Augeas
 itself, but then in 0.10.0 it was accidentally removed from the list.
 This has been fixed in git, but is unreleased.
 
 I suspect on 0.7.1 you're using the FreeBSD lens.  On 0.10.0 you would
 have to be using the FreeBSD lens, but it looks like this isn't being
 picked up - so either the rcconf.aug lens is disabled somehow (or isn't
 in the right search path) or it is failing to parse your rc.conf file.
 
  broken:
  
  # pkg_info |grep augeas
  augeas-0.10.0_1 A configuration editing tool
  
  # find  /usr/local/share/augeas/lenses/ -name *rcconf* -exec sum {} \; 
  29678 1 /usr/local/share/augeas/lenses/tests/rcconf.aug
  13563 1 /usr/local/share/augeas/lenses/rcconf.aug
  
  # augtool 
  augtool print /files/etc/rc.conf
  augtool 
 
 Could you try running this in augtool to see if a lens is being used,
 and if there are errors?
 
   print /augeas/files/etc/rc.conf/
 


Just reinstalling the problematic port here: augeas-0.10.0_1

install  -o root -g wheel -m 444 
/usr/ports/textproc/augeas/files/test_rcconf.aug 
/usr/local/share/augeas/lenses/tests/rcconf.aug
===   Compressing manual pages for augeas-0.10.0_1
===   Running ldconfig
/sbin/ldconfig -m /usr/local/lib
===   Registering installation for augeas-0.10.0_1

# augtool --version
augtool 0.10.0 http://augeas.net/
Copyright (C) 2007-2011 David Lutterkort
License LGPLv2+: GNU LGPL version 2.1 or later
 http://www.gnu.org/licenses/lgpl-2.1.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David Lutterkort


# augtool 
augtool print /augeas/files/etc/rc.conf
/augeas/files/etc/rc.conf
/augeas/files/etc/rc.conf/path = /files/etc/rc.conf
/augeas/files/etc/rc.conf/mtime = 1335894110
/augeas/files/etc/rc.conf/lens = @RcConf
/augeas/files/etc/rc.conf/lens/info = 
/usr/local/share/augeas/lenses/rcconf.aug:15.11-.39:

-dkw

 -- 
 Dominic Cleal
 Red Hat Consulting
 m: +44 (0)7817 878113

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet and FreeBSD

2012-04-23 Thread Darryl Wisneski 
Howdy:

On Mon, Apr 23, 2012 at 06:29:38AM -0700, Jamie Scott wrote:
 Hello all,
 
 Wondering if any of you could help me. 
 
 We've been using puppet on our CentOS servers for a while now with no 
 problems at all, very much out of the box but we do have some MySQL 
 servers running FreeBSD (for the slightly better memory utilisation). I've 
 taken up the challenge to get these FreeBSD servers talking to our puppet 
 master but I'm having no ends of trouble with trying to get the manifests 
 working. Forgetting the operating system variables and just going for a 
 straight install of a package such as mytop this is what I have tried in 
 our manifest:
 
 This didn't seem to work at all:
 
  package { 'mytop': ensure = installed }
 
 
  Gave me this message on the server: *puppet-agent[3232]: 
 (/Stage[main]/Node[###]/Package[mytop]/ensure) change from absent 
 to present failed: mytop: not in required origin format: 
 .*/port_category/port_name*
 

To get rid of this error you have to build the puppet from ports
on the freebsd client host and uncheck the PACKAGE_ORIGIN option.
I don't pretend to understand why.

cd /usr/ports/sysutils/puppet ; make install

# cat /var/db/ports/puppet/options 
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for puppet-2.7.12
_OPTIONS_READ=puppet-2.7.12
WITHOUT_MONGREL=true
WITHOUT_PACKAGE_ORIGIN=true
WITHOUT_PACKAGE_ROOT=true

The below package stanza looks correct.

-dkw

 
 So instead I tried listing the full port name even with the provider: 
 
 package { '.*/databases/mytop': 
  ensure = installed,
  provider = freebsd,
  }
 
  
 Now it is giving me this message: *puppet-agent[3232]: (/Stage[main]//Node[*
 *###**]/Package[.*/databases/mytop]/ensure) change from absent to 
 present failed: Could not fetch ports INDEX: 500 Illegal PORT range 
 rejected.* 
 
 Even with specifiying a source: 
 ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/  I don't 
 seem to be getting very far!
 
 Here is a print out of the debug log:
 
 debug: Puppet::Type::Package::ProviderFreebsd: Executing 
  '/usr/sbin/pkg_info -aoQ'
  debug: Package: .*/databases/mytop: origin = {:port_name=mytop, 
  :port_category=databases}
  debug: Package: .*/databases/mytop: source = #URI::FTP:0x29869038 
  URL:ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/
  debug: Fetching INDEX: #URI::FTP:0x298684e4 
  URL:ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/INDEX.bz2
  err: 
  /Stage[main]//Node[boomer.sov.m-w.co.uk]/Package[.*/databases/mytop]/ensure:
   
  change from absent to present failed: Could not fetch ports INDEX: 500 
  Illegal PORT range rejected.
 
 
 Some odd behaviour I've noticed as well, when packages are already 
 installed it doesn't seem to register as them being there.
 
 Looking for information about puppet on FreeBSD is like trying to find a 
 needle in a haystack. I hope someone can help, any input would be 
 appreciated!
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Puppet Users group.
 To view this discussion on the web visit 
 https://groups.google.com/d/msg/puppet-users/-/Bzhfr9UMSNEJ.
 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to 
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/puppet-users?hl=en.
 

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet and FreeBSD

2012-04-23 Thread Darryl Wisneski 
On Mon, Apr 23, 2012 at 07:08:48AM -0700, Jamie Scott wrote:
 dkw, that worked!
 
 Now I only need to use: package { 'mytop': ensure = installed } 

How have you been handling the differences between centos/rhel and
fbsd?  If statements?  I am going the other way where I have manifests
written mostly for fbsd and now will add rhel/debian specific stuff.

Augeas has been a great help mangling text files.  The devs on IRC
#augeas are helpful too.

Regards,
-dkw

 
 I can't tell you how happy I am!
 
 Thank you!!!
 Jamie
 
 
 
 On Monday, 23 April 2012 14:54:03 UTC+1, dkw wrote:
 
  Howdy:
 
  On Mon, Apr 23, 2012 at 06:29:38AM -0700, Jamie Scott wrote:
   Hello all,
   
   Wondering if any of you could help me. 
   
   We've been using puppet on our CentOS servers for a while now with no 
   problems at all, very much out of the box but we do have some MySQL 
   servers running FreeBSD (for the slightly better memory utilisation). 
  I've 
   taken up the challenge to get these FreeBSD servers talking to our 
  puppet 
   master but I'm having no ends of trouble with trying to get the 
  manifests 
   working. Forgetting the operating system variables and just going for a 
   straight install of a package such as mytop this is what I have tried in 
   our manifest:
   
   This didn't seem to work at all:
   
package { 'mytop': ensure = installed }
   
   
Gave me this message on the server: *puppet-agent[3232]: 
   (/Stage[main]/Node[###]/Package[mytop]/ensure) change from 
  absent 
   to present failed: mytop: not in required origin format: 
   .*/port_category/port_name*
   
 
  To get rid of this error you have to build the puppet from ports
  on the freebsd client host and uncheck the PACKAGE_ORIGIN option.
  I don't pretend to understand why.
 
  cd /usr/ports/sysutils/puppet ; make install
 
  # cat /var/db/ports/puppet/options 
  # This file is auto-generated by 'make config'.
  # No user-servicable parts inside!
  # Options for puppet-2.7.12
  _OPTIONS_READ=puppet-2.7.12
  WITHOUT_MONGREL=true
  WITHOUT_PACKAGE_ORIGIN=true
  WITHOUT_PACKAGE_ROOT=true
 
  The below package stanza looks correct.
 
  -dkw
 
   
   So instead I tried listing the full port name even with the provider: 
   
   package { '.*/databases/mytop': 
ensure = installed,
provider = freebsd,
}
   

   Now it is giving me this message: *puppet-agent[3232]: 
  (/Stage[main]//Node[*
   *###**]/Package[.*/databases/mytop]/ensure) change from absent 
  to 
   present failed: Could not fetch ports INDEX: 500 Illegal PORT range 
   rejected.* 
   
   Even with specifiying a source: 
   ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/  I 
  don't 
   seem to be getting very far!
   
   Here is a print out of the debug log:
   
   debug: Puppet::Type::Package::ProviderFreebsd: Executing 
'/usr/sbin/pkg_info -aoQ'
debug: Package: .*/databases/mytop: origin = {:port_name=mytop, 
:port_category=databases}
debug: Package: .*/databases/mytop: source = #URI::FTP:0x29869038 
URL:ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/
  
debug: Fetching INDEX: #URI::FTP:0x298684e4 
URL:
  ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/INDEX.bz2
  
err: 
/Stage[main]//Node[boomer.sov.m-w.co.uk]/Package[.*/databases/mytop]/ensure:
 
 
change from absent to present failed: Could not fetch ports INDEX: 500 
Illegal PORT range rejected.
   
   
   Some odd behaviour I've noticed as well, when packages are already 
   installed it doesn't seem to register as them being there.
   
   Looking for information about puppet on FreeBSD is like trying to find a 
   needle in a haystack. I hope someone can help, any input would be 
   appreciated!
   
   -- 
   You received this message because you are subscribed to the Google 
  Groups Puppet Users group.
   To view this discussion on the web visit 
  https://groups.google.com/d/msg/puppet-users/-/Bzhfr9UMSNEJ.
   To post to this group, send email to puppet-users@googlegroups.com.
   To unsubscribe from this group, send email to 
  puppet-users+unsubscr...@googlegroups.com.
   For more options, visit this group at 
  http://groups.google.com/group/puppet-users?hl=en.
   
 
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Puppet Users group.
 To view this discussion on the web visit 
 https://groups.google.com/d/msg/puppet-users/-/IXZpcVO-beAJ.
 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to 
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/puppet-users?hl=en.
 

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this

Re: [Puppet Users] Puppet and FreeBSD

2012-04-23 Thread Darryl Wisneski 
On Mon, Apr 23, 2012 at 10:42:53AM -0400, Christopher Wood wrote:
 Breaking in late... I use some defaults to ensure I get binary packages out 
 of my local mirror. (I'm not terribly fussed about binary-only packages, 
 possibly because I come from a Linux background.)
 
 case $::operatingsystem {
   freebsd: {
 # For this we still have to specify freebsd'ish names. Instead of
 # 'ntp', we have to use 'net/ntp'.
 Package {
   provider = 'freebsd',
   source = 'http://repos/pub/FreeBSD/ports/amd64/packages-9.0-release/',
 }
   }
 }


That repository source statement is pretty powerful stuff and will
help us out extremely here.  Have you tried to get puppet to do
make install?  The outcome is probably too variable anyhow.

That is pretty clear case syntax too.  I have seen that on the
puppetlabs site too.

Here is some background on the freebsd provider giving the error:
not in required origin format: .*/port_category/port_name

http://www.mail-archive.com/puppet-dev@googlegroups.com/msg13765.html

 
 Then as mentioned above:
 
 package { 'net/ntp': }
 
 I found that if I specified other styles of package names with the freebsd 
 package provider they would be reinstalled with every puppet run.
 

I have been OK specifying only the package and not half of the ports
directory tree so far.

 For some modules I use the 'include module::$operatingsystem' syntax, for 
 others I use a case statement. I'm still undecided which is better, but so 
 far it depends how much systems diverge from each other on a per-module basis.
 
 
 On Mon, Apr 23, 2012 at 07:08:48AM -0700, Jamie Scott wrote:
 dkw, that worked!
  
 Now I only need to use: package { 'mytop': ensure = installed }
  
 I can't tell you how happy I am!
  
 Thank you!!!
 Jamie
  
 On Monday, 23 April 2012 14:54:03 UTC+1, dkw wrote:
  
   Howdy:
  
   On Mon, Apr 23, 2012 at 06:29:38AM -0700, Jamie Scott wrote:
Hello all,
   
Wondering if any of you could help me.
   
We've been using puppet on our CentOS servers for a while now with no
problems at all, very much out of the box but we do have some
   MySQL
servers running FreeBSD (for the slightly better memory utilisation).
   I've
taken up the challenge to get these FreeBSD servers talking to our
   puppet
master but I'm having no ends of trouble with trying to get the
   manifests
working. Forgetting the operating system variables and just going for
   a
straight install of a package such as mytop this is what I have tried
   in
our manifest:
   
This didn't seem to work at all:
   
? ? ?package { 'mytop': ensure = installed } ? ?

   
?Gave me this message on the server: *puppet-agent[3232]:
(/Stage[main]/Node[###]/Package[mytop]/ensure) change from
   absent
to present failed: mytop: not in required origin format:
.*/port_category/port_name*
   
  
   To get rid of this error you have to build the puppet from ports
   on the freebsd client host and uncheck the PACKAGE_ORIGIN option.
   I don't pretend to understand why.
  
   cd /usr/ports/sysutils/puppet ; make install
  
   # cat /var/db/ports/puppet/options
   # This file is auto-generated by 'make config'.
   # No user-servicable parts inside!
   # Options for puppet-2.7.12
   _OPTIONS_READ=puppet-2.7.12
   WITHOUT_MONGREL=true
   WITHOUT_PACKAGE_ORIGIN=true
   WITHOUT_PACKAGE_ROOT=true
  
   The below package stanza looks correct.
  
   -dkw
  
   
So instead I tried listing the full port name even with the provider:
   
? ? package { '.*/databases/mytop':
 ? ? ? ? ? ? ensure = installed,
 ? ? ? ? ? ? provider = freebsd,
 ? ? ? ? ? ? } ? ?

?
Now it is giving me this message: *puppet-agent[3232]:
   (/Stage[main]//Node[*
*###**]/Package[.*/databases/mytop]/ensure) change from 
  absent
   to
present failed: Could not fetch ports INDEX: 500 Illegal PORT range
rejected.*
   
Even with specifiying a source:
[1]ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/
   ?I don't
seem to be getting very far!
   
Here is a print out of the debug log:
   
debug: Puppet::Type::Package::ProviderFreebsd: Executing
 '/usr/sbin/pkg_info -aoQ'
 debug: Package: .*/databases/mytop: origin = {:port_name=mytop,
 :port_category=databases}
 debug: Package: .*/databases/mytop: source = #URI::FTP:0x29869038

   
  URL:[2]ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/
 debug: Fetching INDEX: #URI::FTP:0x298684e4

   
  URL:[3]ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0-release/INDEX.bz2

Re: [Puppet Users] FreeBSD Port

2012-04-11 Thread Darryl Wisneski 
Why not this? 

'puppet agent -t' or 'puppet agent --test'

From puppet help..  (ughh, no manpage)

* --test:
  Enable the most common options used for testing. These are 'onetime',
  'verbose', 'ignorecache', 'no-daemonize', 'no-usecacheonfailure',
  'detailed-exit-codes', 'no-splay', and 'show_diff'.

-dkw


On Wed, Apr 11, 2012 at 10:02:10AM -0400, Christopher Wood wrote:
 (I'm just starting with FreeBSD, albeit with some months of puppet 
 experience.)
 
 The puppet agent implies a daemon, but try something like this for a single 
 run in the foreground:
 
 puppet agent --no-daemonize --onetime
 
 On Wed, Apr 11, 2012 at 07:31:14AM -0400, JA wrote:
  I have installed puppet using the FreeBSD port.  However, when I try
  to use the agent, it attempts to start the puppetd daemon.  It seems
  that there is no way to use this installation without running the
  daemon.  Can anyone shed any light on this?
  
  Thank you!
  
  -- 
  You received this message because you are subscribed to the Google Groups 
  Puppet Users group.
  To post to this group, send email to puppet-users@googlegroups.com.
  To unsubscribe from this group, send email to 
  puppet-users+unsubscr...@googlegroups.com.
  For more options, visit this group at 
  http://groups.google.com/group/puppet-users?hl=en.
  
  
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Puppet Users group.
 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to 
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/puppet-users?hl=en.
 

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] FreeBSD Port

2012-04-11 Thread Darryl Wisneski 
Jackie:

Please post your 1.) puppet.conf, OS Relase, and version of puppet.

2.) uname -a 
3.) pkg_info |grep puppet

Can you check the ps output to make sure there wasn't already a
running puppet.  Do you have any jails on the machine that may be
running puppet as well and causing PID confusion?

Thanks,
-dkw

On Wed, Apr 11, 2012 at 10:50:10AM -0400, Christopher Wood wrote:
 I couldn't say, perhaps different versions? Or run with more verbosity and 
 see what both versions are doing.
 
 Puppet 2.6.2 on Debian Stable (6.0.4):
 
 Enable the most common options used for testing. These are +onetime+, 
 +verbose+, +ignorecache, +no-daemonize+, and +no-usecacheonfailure+.
 
 Puppet 2.7.6 on FreeBSD (9.0-RELEASE):
 
 Enable the most common options used for testing. These are 'onetime', 
 'verbose', 'ignorecache', 'no-daemonize', 'no-usecacheonfailure', 
 'detailed-exit-codes', 'no-splay', and 'show_diff'.
 
 I'm not sure it matters as long as you can get a onetime run. Dig into the 
 ruby code if it's really bothering you, of course.
 
 As to Darryl's comment in another branch, I haven't needed more than 
 no-daemonize, verbose, and debug to solve all my problems so far.
 
 On Wed, Apr 11, 2012 at 10:27:19AM -0400, JA wrote:
  Thanks so much!
  
  However, I am a bit stumped and would so appreciate any clarity you can 
  provide.
  
  If I execute 'puppet agent --test' on a RHEL box, it does not start
  the daemon.  But, if I do the same thing using the FreeBSD port, it
  does attempt to start the daemon.
  
  Obviously, I am missing something here...
  
  Thanks!
  Jackie
  
  On Wed, Apr 11, 2012 at 10:02 AM, Christopher Wood
  christopher_w...@pobox.com wrote:
   (I'm just starting with FreeBSD, albeit with some months of puppet 
   experience.)
  
   The puppet agent implies a daemon, but try something like this for a 
   single run in the foreground:
  
   puppet agent --no-daemonize --onetime
  
   On Wed, Apr 11, 2012 at 07:31:14AM -0400, JA wrote:
   I have installed puppet using the FreeBSD port. ?However, when I try
   to use the agent, it attempts to start the puppetd daemon. ?It seems
   that there is no way to use this installation without running the
   daemon. ?Can anyone shed any light on this?
  
   Thank you!
  
   --
   You received this message because you are subscribed to the Google 
   Groups Puppet Users group.
   To post to this group, send email to puppet-users@googlegroups.com.
   To unsubscribe from this group, send email to 
   puppet-users+unsubscr...@googlegroups.com.
   For more options, visit this group at 
   http://groups.google.com/group/puppet-users?hl=en.
  
  
  
   --
   You received this message because you are subscribed to the Google Groups 
   Puppet Users group.
   To post to this group, send email to puppet-users@googlegroups.com.
   To unsubscribe from this group, send email to 
   puppet-users+unsubscr...@googlegroups.com.
   For more options, visit this group at 
   http://groups.google.com/group/puppet-users?hl=en.
  
  
  -- 
  You received this message because you are subscribed to the Google Groups 
  Puppet Users group.
  To post to this group, send email to puppet-users@googlegroups.com.
  To unsubscribe from this group, send email to 
  puppet-users+unsubscr...@googlegroups.com.
  For more options, visit this group at 
  http://groups.google.com/group/puppet-users?hl=en.
  
  
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Puppet Users group.
 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to 
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/puppet-users?hl=en.
 

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.