[Puppet Users] Re: Puppet Automatic Resource State changing...
No-one doing anything similar? Cheers Gav On Friday, 15 February 2013 12:08:37 UTC, Gavin Williams wrote: Morning all, Firstly, apologies for the length of this post, however I thought it probably most useful to fully outline the challenge and the desired result... Ok, so we're in the process of Puppetizing our Oracle/NetApp platform for Live/DR running. The current manual process, upon setting up a new database, a set of volumes are created to contain the various Oracle DB elements, and these are then SnapMirror'd to the DR site. This SnapMirror process requires a period of time to copy the base data over... This time period is directly relational to the amount of data required... I.e. a copy of 20Gb may take an hour, 200Gb may take 10 hours... During this period, the SnapMirror resource is in an 'initializing' state. Once the data copy is complete, then the resource will change to an 'initialized' state. The next step in the process is then to break the relationship so that the DR end can be used in a R/W mode... Now, in order to Puppetize this, I need to be able to replicate the above behaviour... I've got Puppet to create and initialize the relationship, and that works as expected. However Puppet doesn't currently care about the relationship state. Now that's easy enough to add in as a new property against the type/provider. However what I'm struggling to understand is how, or if it's even possible, to automate the switch from 'Initialized' state to a 'Broken' state upon completion of the initialization stage??? Now these databases definitions are currently driven from a YAML backend which maintains information such as database name, volume information, primary netapp controller, replication netapp controller, etc... Currently, this YAML file is just a file on the puppet master... However there are ambitions to move this into a more dynamic backend, such as CouchDB or similar... So that opens the possibility to automatically update the YAML resource state.. However Puppet still needs to be able to support updating that backend based on the information it gets from the actual resource... So to flow it out: 1. Create a new database in backend - 2. Puppet creates volumes on primary - 3. Data is added to volumes - 4. Backend updated to indicate replication is required - 5. Puppet creates volumes on Secondary and adds Snapmirror relationship - 6. Snapmirror initializes in background - 7. Puppet periodically runs against network device and checks resource state - 8. Backend resource state is updated following each run? - 9. Snapmirror initialization completes - 10. Puppet runs, detects new resource state and then triggers break? 11. Backend resource state updated to 'broken'? Now 1 to 7 above are fine, but 8 to 11 are where I get a bit unsure... So, that's the challenge... Am I barking up the wrong tree, or is this something that Puppet could manage? Cheers in advance for any responses. Regards Gavin -- 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] Re: Inheritance of classes in Ruby DSL
The Puppet Ruby DSL in its current form is deprecated: Issue: https://projects.puppetlabs.com/issues/18876 Discussion: https://groups.google.com/forum/?fromgroups=#!topic/puppet-dev/UsDaDGAneEE On Sunday, February 17, 2013 12:42:05 AM UTC+1, Ryan Bowlby wrote: ...Bueller Anyone have an answer for this? This seems like a pretty pertinent feature for anyone looking to take advantage of the ruby DSL. I for one would be eternally grateful. -Ryan On Wednesday, June 13, 2012 8:08:07 AM UTC-7, Ingo Fischer wrote: I have the same question (see https://groups.google.com/forum/?fromgroups#!searchin/puppet-users/inheritance$20ruby$20dsl/puppet-users/RtMbu8yFZCc/Zet8ackZgnYJ) and need this behavior for my project. Is inheritance possible at all with the Ruby DSL? If not, should we create an issue for that? Am Dienstag, 15. Mai 2012 10:16:22 UTC+2 schrieb alxrem: Hello. Is it possible to describe inheritance of classes in Ruby DSL? -- 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] Apparent bug in 'import' when directory name matches module name
I've found an apparent bug in the puppet parser.
If you are using 'import' to include the contents of a subdirectory, like this:
import 'foo/*.pp'
and then you create a new module 'foo', suddenly the import statement silently
stops working. This means that any node definitions in the manifests that
should have been included are not present, and those nodes fall back to the
default node. The 'foo' module can be completely minimal, just a 'class foo {
}' in the init.pp is enough to break the import.
Now, in our case, our default node closes the firewall. When we productionised
a new module called 'oracle', all of the node definitions imported from
oracle/*.pp suddenly stopped working, and so all the production oracle servers
fell back to the default node definition, and closed their firewalls... Insert
the sound of the brown stuff hitting the fan...
I have successfully duplicated this, and logged it as a bug on the Puppet bug
tracker. A workaround seems to be to add a './' prefix to the imported
directory name:
import './foo/*.pp'
which has the same effect, but is not broken by having a 'foo' module present.
I've tried to delve through the parser code to track this one down, but my Ruby
skills are not as good as my Perl skills, and I've not managed to identify the
reason. Possibly the parser creates a new class for the imported directory?
I'd be interested in hearing if anyone else has experienced this, or if this
clears up odd behaviour you're experiencing on your system. Also, if you also
have the problem, please go to the bug tracker and give this a +1 to help it
get higher priority on the fix list...
Steve
Steve Shipway
University of Auckland ITS
UNIX Systems Design Lead
s.ship...@auckland.ac.nzmailto:s.ship...@auckland.ac.nz
Ph: +64 9 373 7599 ext 86487
--
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] Re: Can we write many classes in a single manifest
Hi There,
You can, however once a class is defined you must then apply it to the node
using 'include'
Example:
[ Keiran ~]$ cat /tmp/example.pp
class class1 {
exec { exec1 :
command = /bin/touch /tmp/${title},
}
}
class class2 {
exec { exec2 :
command = /bin/touch /tmp/${title},
}
}
include class1
include class2
[ Keiran ~]$ puppet apply /tmp/example.pp
notice: /Stage[main]/Class2/Exec[exec2]/returns: executed successfully
notice: /Stage[main]/Class1/Exec[exec1]/returns: executed successfully
notice: Finished catalog run in 0.17 seconds
[ Keiran ~]$ ls -al /tmp/ |grep -i class
-rw-r--r-- 1 Keiran Keiran 0 Feb 18 10:27 class1
-rw-r--r-- 1 Keiran Keiran 0 Feb 18 10:27 class2
[ Keiran ~]$
Defining multiple classes in a single manifest for non-testing/learning may
not always be deemed as best practice, It might be worth having a read of
the following documentation:
- http://docs.puppetlabs.com/puppet/2.7/reference/lang_classes.html
- http://docs.puppetlabs.com/guides/style_guide.html
Hope this helps,
K
On Monday, February 18, 2013 7:07:39 AM UTC, yarlagadda ramya wrote:
Hi all,
Can we write many classes in a single manifest and apply that manifest??
For example i have created manifest, file1.pp and it includes the
following:
class one{
exec{--
command = ,
cwd =,
}
}
class two{
exec{--
command = ,
cwd =,
}
}
now can i write a manifest like this and apply it?
Can any one pls help me with it?
--
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] Stomp connector deprecated ?
On Monday, February 18, 2013 12:21:11 AM UTC-6, John Warburton wrote: Is this mcollective version 3.x or 2.3.x? Deprecation warning occurs in 2.3. Complete removal will occur in the 3.x production branch. So you should be good to continue using it for a few months to come, but when the next production series comes around it will really be gone. It's an early headsup. Hmm - I'm 3/4 way through my proof of concept and rolling out into lab over the coming 6-8 weeks. Production should be in 2-3 months. Should I continue with mcollective 2.2.x / stomp 1.2.2 / Active MQ 5.5 or wait a bit longer? You are absolutely fine to continue with your roll out. However, you should work the specific ActiveMQ or RabbitMQ connector into that rollout if you want to be fully forward-compatible. Ellison posted the link to the docs previously. Thanks 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.
Re: [Puppet Users] Stomp connector deprecated ?
- Original Message - From: Drew Blessing drew.bless...@mac.com To: puppet-users@googlegroups.com Sent: Monday, February 18, 2013 11:47:53 AM Subject: Re: [Puppet Users] Stomp connector deprecated ? On Monday, February 18, 2013 12:21:11 AM UTC-6, John Warburton wrote: Is this mcollective version 3.x or 2.3.x? Deprecation warning occurs in 2.3. Complete removal will occur in the 3.x production branch. 2.2.x is the production branch that tends to stay around 6 months to a year 2.3.x is the early adopter/dev series deprecation log lines is in 2.2.3, removed in 2.3.1 and there will be several more 2.3.x releases before 2.2.x moves on. We do it this way so that we can identify any issues with the removal in the more risky branch. For example we now know that debian's package system and this removal will cause hassles, we know this cos the dev series feels that pain and it means by the time 3.0 or 2.4 comes around we can properly warn production users. No eta for when the 2.2.x branch will move forward, no eta for when this adapter will be removed from production code, no need to panic. But if you're starting out now you should look to using one of the new connectors I posted links to. The ActiveMQ and RabbitMQ connectors are just specialised versions of the Stomp ones, they were introduced to the production branches 2012/04/30 and 2012/09/13 so they've had a good bit of time to be tested before we are now finally warning that we will at some point in the future move to them as standard. I'll update the docs with this information hopefully this week So you should be good to continue using it for a few months to come, but when the next production series comes around it will really be gone. It's an early headsup. Hmm - I'm 3/4 way through my proof of concept and rolling out into lab over the coming 6-8 weeks. Production should be in 2-3 months. Should I continue with mcollective 2.2.x / stomp 1.2.2 / Active MQ 5.5 or wait a bit longer? You are absolutely fine to continue with your roll out. However, you should work the specific ActiveMQ or RabbitMQ connector into that rollout if you want to be fully forward-compatible. Ellison posted the link to the docs previously. Thanks 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. -- 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: Security considerations for basing decisions on facts
On 22.1.2013 23:04, jcbollinger wrote: You are correct that that only the identity of the client node is authenticated by Puppet, and even that only insomuch as the client can be relied upon to protect its SSL certificate. The $hostname fact cannot be relied upon to convey that information, as it doesn't in any sense need to be the same thing; you're looking for $certname. It is, however, $certname (not $hostname) by which a node block is selected and/or an ENC queried, so Puppet's architectural foundation is secure in that regard. You are also right that a compromised client can, in principle, falsify the fact values presented to the master in an attempt to make it divulge secret information. Whether the master might actually divulge anything is a function of the manifests with which site administration has configured it. In other words, that's a question of how Puppet is used, not of the fundamental security of Puppet itself. To the extent that you want to record server-side node data, I think hiera is the way to go. I prefer that to encoding data in an ENC or in your manifests, but those are some of the other options. All of those are secure to the extent that the master itself is secure, though I wouldn't say that any of them were designed specifically as a secure alternative to node facts. Hello, Yes, I agree it is a problem of the usage, rather than puppet itself. Thanks for the confirmation! Best regards, Boyan signature.asc Description: OpenPGP digital signature
[Puppet Users] Re: .erb templates are not properly parsed.
Dear John,
I tryed as you suggested, and didn't work.
I Found where is the problem that produces the failure in both cases. The
problem basically is that on all the nodes I'm using inherits definition
like:
node basenode {
include shorewall
include othermodules
}
node examplenode1 inherits basenode {
include apache
include bind
include ssh
}
So I tryed debugging and on the template I added following lines:
% classes.each do |k| -%
%= k %
% end -%
Then I find that it only prints classes inside basenode:
shorewall
other modules
If I declare host without inherits then, both procedures works, my first
and yours. And in this example , classes will print:
shorewall
other modules
apache
bind
ssh
It is pretty clear to me that this seems a puppet bug that does not parse
properly classes when you are using inherits in site.pp manifets.
El viernes, 15 de febrero de 2013 21:10:41 UTC+1, jcbollinger escribió:
On Friday, February 15, 2013 10:51:06 AM UTC-6, Marc Bolós wrote:
Dear John,
I tryed as you suggested but I think I'm doing something wrong.
I can also see this line is same:
$service_modules = hiera_array('service_modules')
It is correct?
Where do I define array of modules? where you write service_modules?
The code was intended as an example. If you want to use it exactly as
written, then you must configure Puppet's hiera external data subsystem
on the master, and record the module list in a hiera data file (supposing
you use the YAML back end). That has a lot of advantages, but if you don't
know what I'm talking about then you might be better off starting simpler.
A very simple proof of concept would be to put
$fw_modules = ['apache2', 'bind9', 'ssh']
(or whatever module list you want) at the beginning of your
manifests/site.pp (outside any node block), and replace each of the two
lines invoking hiera_array() with this:
$service_modules = $::fw_modules
Once you've satisfied yourself that it works (which it should), you can
figure out a more appropriate way to declare the shared data.
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] Some thoughts on design patterns and hiera includes
I have been thinking about a good way to include things in Hiera--that is,
to insert a directive to add another stream. The problem is one of
attachment: inserting things becomes complex when you think much about it.
Consider the following:
---
key1: value1
key2: value2
key3: '%include values/me.yaml'
And a me.yaml:
---
:value: value3
Does that make sense? The result would be:
---
key1: value1
key2: value2
key3: value3
How about this me.yaml:
---
:value:
- element3.1
- element3.2
- element3.3
Giving the result:
---
key1: value1
key2: value2
key3:
- element3.1
- element3.2
- element3.3
And predictably with a hash:
---
:value:
subkey1: element3.1
subkey2: element3.2
subkey3: element3.3
And the result:
---
key1: value1
key2: value2
key3:
subkey1: element3.1
subkey2: element3.2
subkey3: element3.3
We could even predict shell globs, such that the following works:
---
key1:value1
key2:value2
vhosts: '%include vhosts/*.yaml'
Now here's the trick: What if you want to expand from a base?
---
key1: value1
key2: value2
key3:
- element1
- element2
- '%include values/me.yaml'
And you want a result like
---
key1: value1
key2: value2
key3:
- element1
- element2
- element3
- element4
You might say, But wait, with an array this always makes sense because an
array can't blind-insert a value (can it?), so something like this would
make no sense:
---
key1: value1
key2: value2
key3:
- element1
- element2
-
- element3
- element4
But what happens when you want to blindly append to a hash?
---
key1: value1
key2: value2
key3:
subkey1: element1
subkey2: element2
'%include values/key3.yaml'
This does not appear well-formed... and similarly unpalatable is the idea
of using a different semantic for this case:
---
key1: value1
key2: value2
key3:
subkey1: element1
subkey2: element2
':%include': values/key3.yaml
This is fairly significant because there are instances--for example, I'm
sitting on one--where you have an Apache httpd.conf that's, oh, what is
it... 4976 lines long, about 4500 of which are vhost definitions.
The Puppetlabs Apache module breaks vhosts out into individual files, just
like debian, even on CentOS/RHEL. This is a better way... trust me I've
done it both ways, extensively. I've worked in environments where having a
huge httpd.conf caused major pain and interruptions to our SLAs that we
handwaved away by having fine-print text that reads 99.99% uptime refers
to network uptime. We cannot guarantee against software or hardware
failures. Turns out multi-editing httpd.conf from vi causes problems
sometimes.
But what you get for your trouble is 300-500 virtual hosts defined in one
big friggin' YAML file, just so you can create a node that calls:
create_resources('apache::vhost', hiera('vhosts'))
create_resources('nginx::vhost', hiera('vhosts'))
And, you see, therein lies the problem. Sometimes you really, really want
a hierarchy like:
data/
common.yaml
nodes/
web-01.yaml
web/
vhosts-enabled/
*.yaml
Especially if you have automated systems dropping files in and out of these
directories, i.e. to create/delete/enable/disable sites. Kind of removes
data hotspots.
Perhaps a merge directive would be easier, like hiera_hash():
# web.yaml
---
:merge:web/vhosts/*
vhosts:
# web/vhosts/vhost1.yaml
---
vhosts:
www.example.com:
docroot: '/var/www/sites/www.example.com/html'
priority: 1
Thoughts? I kind of want to file a competent Feature Request on this that
proscribes a good way forward.
--
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] Re: Inheritance of classes in Ruby DSL
On Saturday, February 16, 2013 5:42:05 PM UTC-6, Ryan Bowlby wrote: ...Bueller Anyone have an answer for this? This seems like a pretty pertinent feature for anyone looking to take advantage of the ruby DSL. I for one would be eternally grateful. As Ingo Fischer observed, Puppet's current Ruby DSL is deprecated. I think I remember reading that PL's effort to create a replacement has been abandoned. As such, I would not advise basing any work on Ruby DSL. Although the Ruby DSL provided direct access to Ruby for defining manifests, there were always features of Puppet's native DSL that the Ruby DSL did not provide. In any case, class inheritance is a rather special-purpose tool in Puppet (as was Ruby DSL), so although you may have a good use case for it yourself, I don't think it's accurate to call inheritance a pretty pertinent feature for anyone looking to take advantage of the ruby DSL. If you tell us about what you're trying to do then perhaps we can suggest an alternative. 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] Re: Apparent bug in 'import' when directory name matches module name
On Monday, February 18, 2013 3:47:40 AM UTC-6, Steve Shipway wrote:
I've found an apparent bug in the puppet parser.
If you are using 'import' to include the contents of a subdirectory, like
this:
import 'foo/*.pp'
and then you create a new module 'foo', suddenly the import statement
silently stops working. This means that any node definitions in the
manifests that should have been included are not present, and those nodes
fall back to the default node. The 'foo' module can be completely minimal,
just a 'class foo { }' in the init.pp is enough to break the import.
Now, in our case, our default node closes the firewall. When we
productionised a new module called 'oracle', all of the node definitions
imported from oracle/*.pp suddenly stopped working, and so all the
production oracle servers fell back to the default node definition, and
closed their firewalls... Insert the sound of the brown stuff hitting the
fan...
I have successfully duplicated this, and logged it as a bug on the Puppet
bug tracker. A workaround seems to be to add a './' prefix to the imported
directory name:
import './foo/*.pp'
which has the same effect, but is not broken by having a 'foo' module
present.
I've tried to delve through the parser code to track this one down, but my
Ruby skills are not as good as my Perl skills, and I've not managed to
identify the reason. Possibly the parser creates a new class for the
imported directory?
I'd be interested in hearing if anyone else has experienced this, or if
this clears up odd behaviour you're experiencing on your system. Also, if
you also have the problem, please go to the bug tracker and give this a +1
to help it get higher priority on the fix list...
Steve
I have been working on a similar bug.
The root cause (of #1372 (http://projects.puppetlabs.com/issues/1372) )
seems to be that nodes are treated as classes,and both get loaded into top
scope.
I'll look into this one as well, I'm expecting to be able to spend time on
it this week.
*Steve Shipway*
University of Auckland ITS
*UNIX Systems Design Lead*
s.sh...@auckland.ac.nz javascript:
Ph: +64 9 373 7599 ext 86487
**
--
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] OS X Lion group membership not updated
Hi Gary, Any other thoughts on what could be going on here? I'm afraid I haven't made any further progress on it, and am at a bit of a loss. Any suggestions you or anyone else may have would be greatly appreciated! Thanks, Doug On Mon, Jan 28, 2013 at 4:38 PM, Doug Mayer d...@ebackpack.com wrote: Hi Gary, Thanks for the response. I am running Facter v1.6.17 and Puppet v2.7.20 (both are the latest versions for Ubuntu 12 LTS, so I wanted to run the same version on OS X if possible). Running OS X Server v10.7.5. Every time I run, it says that it changes the groups (it always says it was ) but it seems they're never actually persisted. Both the admin and sudo groups listed exist. I didn't specify a uid/gid for the user or the groups, so they're the default low IDs, making it impossible to inspect through the UI (I think they only show UIDs 500)--I've not been able to determine yet if that has any effect on it. * [my.server.net] notice: /Stage[main]/User::Virtual/User::Virtual::Ssh_user[doug]/User[doug]/groups: groups changed '' to 'admin,sudo' * [my.server.net] notice: Finished catalog run in 1.26 seconds Thanks! Doug On Sat, Jan 26, 2013 at 3:20 PM, Gary Larizza g...@puppetlabs.com wrote: Hi Doug, Yep, I did the work on that and it was merged in around 2.7.10, I believe -- http://projects.puppetlabs.com/issues/11293 Can you provide me with what specific error you're getting, the version of OS X you're running, and the versions of Facter/Puppet you're using? On Fri, Jan 25, 2013 at 2:33 PM, d...@ebackpack.com wrote: Sorry to revive an old thread, but this seems to be the only other thing I can find on this exact issue I'm having. Nigel - do you have any idea if the fixes have ever made it into a 2.7.x release? I'm using 2.7.20 (as that's what is used in our non-OSX hosts) and still getting this same error. Thanks! Doug On Wednesday, September 7, 2011 8:07:00 AM UTC-5, Nigel Kersten wrote: On Tue, Sep 6, 2011 at 12:42 PM, James Turnbull ja...@puppetlabs.comwrote: David Thompson wrote: Switching to puppet (2.7.3) for managing my OS X Lion systems, I'm finding group membership not being updated. Any help much appreciated... David I think there are a bunch of OSX Lion bugs in the ticket DB that might be worth checking if this one is picked up. We've got code for some and need to do some refactoring for others. So that people understand, Apple have changed a bunch of things around DirectoryServices that caused our provider to break under Lion. I just got Lion installed recently on my laptop, and I'm planning to churn through these issues in the next few days, targeting the fixes at 2.7.x. -- Nigel Kersten Product Manager, Puppet Labs *Join us for **PuppetConf * http://www.bit.ly/**puppetconfsig http://www.bit.ly/puppetconfsig Sept 22/23 Portland, Oregon, USA. * * -- 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. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- Gary Larizza Professional Services Engineer -- 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. Visit this group at http://groups.google.com/group/puppet-users?hl=en. 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 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] Controlling access to filebucket
Hi, Is there a way to control access to the filebucket? Specifically, I wish to allow agents to backup to the filebucket but never restore. Is this possible to do? Thanks, Brian -- 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: Coordinated application deployments
Why don't you use nodes groups or environments to prevent the second set of servers to be updated? Once validated on the first node group, you can easily deploy on the second set. -- 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: Coordinated application deployments
Why don't you use nodes groups or environments to prevent the second set of servers to be updated? Once validated on the first node group, you can easily deploy on the second set. -- 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: Coordinated application deployments
Sorry wrong thread *getting more coffee* -- 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] Error with service: invalid byte sequence in US-ASCII
I just built a new puppet master, and whenever I run puppet on it, it
throws an error while processing a service resource:
# puppet agent -t
Info: Retrieving plugin
Info: Caching catalog for i-45dc2b1d
Info: Applying configuration version 'g
9ea47ad19bc706a754c00f00a024309948d3ea03'
Error: /Stage[main]/Ipa::Client::Basic/Service[sssd]: Could not evaluate:
invalid byte sequence in US-ASCII
Notice: Finished catalog run in 15.37 seconds
The debug output:
Debug: Executing '/sbin/status sssd'
Debug: Executing '/sbin/initctl --version'
Error: /Stage[main]/Ipa::Client::Basic/Service[sssd]: Could not evaluate:
invalid byte sequence in US-ASCII
This is what the manifest for that resource looks like:
service { 'sssd':
ensure = running,
enable = true,
hasstatus = true,
hasrestart = true,
require= [ Package['sssd'], File['/etc/sssd/sssd.conf'], ],
}
This is with ubuntu 12.04 and puppet 3.1
Any ideas?
--
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] Stomp connector deprecated ?
On 18 February 2013 23:19, R.I.Pienaar r...@devco.net wrote: No eta for when the 2.2.x branch will move forward, no eta for when this adapter will be removed from production code, no need to panic. But if you're starting out now you should look to using one of the new connectors I posted links to. The ActiveMQ and RabbitMQ connectors are just specialised versions of the Stomp ones, they were introduced to the production branches 2012/04/30 and 2012/09/13 so they've had a good bit of time to be tested before we are now finally warning that we will at some point in the future move to them as standard. I'll update the docs with this information hopefully this week Thanks for the detailed response RI - appreciated 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.
Re: [Puppet Users] Puppet diff and preview of changes to node's catalog
Hi Elad, There is an audit mode which may help you. There is an explanation of how it works here. https://puppetlabs.com/blog/all-about-auditing-with-puppet/ On 18 February 2013 16:45, Elad Shmitanka elad.shmita...@gmail.com wrote: While trying to build safety mechanisms for applying new configuration, the aim: be able to fore-tell what will be the changes on the nodes, just like you can see the changes in SVN, I want to see how they will affect the nodes. I will manage this by having 2 modules directories, 1 currently used by the puppet master and the second is the new one that will be applied, Same for configuration directory. Since I'm a fan of Bash, the idea would be to use command line tools. Create list of the nodes: puppet cert --list --all Will give me list of all the nodes I want to examine Create a compiled catalog: puppet master --compile node name --modulepath module dir --confdir config directory node_name I will run it twice, one for each pair of directories, for each node then using this diff tool: https://github.com/ripienaar/**puppet-catalog-diffhttps://github.com/ripienaar/puppet-catalog-diff to show the diff between them Any thoughts? comments? things I may have overlooked? -- 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. -- 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: Checking GIT updates
On 17 February 2013 01:34, Jason Edgecombe ja...@rampaginggeek.com wrote: On 02/14/2013 07:25 PM, Peter Brown wrote: On 15 February 2013 10:04, joe lava...@gmail.com wrote: Puppet isn't particularly good at code deployment. Ideally, you'd package your code, set a package resource to ensure = latest, then update your package repo with the new code. Then, all the resources that subscribe to that package (services, etc.) would be refreshed when the package gets updated in your repo. I disagree. I use puppet for managing code deployments. I tend to use svn or git to roll it out because our internal software is a moving target and not well suited to packages and because it can be deployed multiple times on a node. Yes I realise I could use a package for that but I find it easier to use a source code management system. Updating is a simple process of updating one variable that specifies the tag to update to. Puppetforge has the vcsrepo module if you want to use the pull method: https://forge.puppetlabs.com/**puppetlabs/vcsrepohttps://forge.puppetlabs.com/puppetlabs/vcsrepo I'm just not sure if notify works with it. I was intending on having a look at vscrepo to see if i can get it to work with my setups. It looks pretty handy. Jason -- 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+unsubscribe@**googlegroups.compuppet-users%2bunsubscr...@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=enhttp://groups.google.com/group/puppet-users?hl=en . For more options, visit https://groups.google.com/**groups/opt_outhttps://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 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] Error with service: invalid byte sequence in US-ASCII
No, but it's not related to the manifest. The manifest this resource is
in actually hasn't changed in months. Also I can reboot the box and it
goes away. Other boxes that aren't doing it will sometimes start doing
it when they reboot. (at least that's the behaviour I've been observing,
but I have only rebooted a few boxes since this started occurring).
So it seems like it's environmental, but I have no clue what.
-Patrick
On 02/18/2013 11:57 PM, Conor wrote:
Have you looked for non-printable characters?
`cat -v filename` is one of the easier ways to check.
-Conor
On Feb 18, 2013 11:54 AM, Patrick patrick.hem...@gmail.com
mailto:patrick.hem...@gmail.com wrote:
I just built a new puppet master, and whenever I run puppet on it,
it throws an error while processing a service resource:
# puppet agent -t
Info: Retrieving plugin
Info: Caching catalog for i-45dc2b1d
Info: Applying configuration version 'g
9ea47ad19bc706a754c00f00a024309948d3ea03'
Error: /Stage[main]/Ipa::Client::Basic/Service[sssd]: Could
not evaluate: invalid byte sequence in US-ASCII
Notice: Finished catalog run in 15.37 seconds
The debug output:
Debug: Executing '/sbin/status sssd'
Debug: Executing '/sbin/initctl --version'
Error: /Stage[main]/Ipa::Client::Basic/Service[sssd]: Could
not evaluate: invalid byte sequence in US-ASCII
This is what the manifest for that resource looks like:
service { 'sssd':
ensure = running,
enable = true,
hasstatus = true,
hasrestart = true,
require= [ Package['sssd'], File['/etc/sssd/sssd.conf'], ],
}
This is with ubuntu 12.04 and puppet 3.1
Any ideas?
--
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
mailto:puppet-users%2bunsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com
mailto: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.
--
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.
