[Puppet Users] Re: Resources existing in different operating systems.
On Thu, Jun 2, 2011 at 12:36 PM, Douglas Garstang wrote: > So... I'm thinking about how to have puppet manage different operating > systems. It's one thing to use a selector to determine the value of specific > resources attribute, but what do you do when a file may not exist on a > specific O/S? You can't use a selector in this case. > > I really don't like the approach described here either... > > http://m0dlx.com/blog/Puppet_manifests__a_multi_OS_style_guide.html > > ...where classes are loaded dynamically based on the value of a variable. > > What would best practice indicate? > > Doug. > > *jabs anyone that's prepared to be jabbed* -- 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] Certificate problems
On Jun 2, 2011, at 9:32 AM, John Kennedy wrote: > Replies inline > > On Wed, Jun 1, 2011 at 17:55, Patrick wrote: > > On Jun 1, 2011, at 8:05 AM, John Kennedy wrote: > >> I have several servers being hosted on Amazon Web Services. They have all >> been build from the same manifest so apart from the hostnames, IP, etc they >> are all identical. >> >> All but 3 of the boxes can connect to the puppetmaster. When kicked from the >> puppetmaster two give: >> Host host.example.com failed: Connection refused - connect(2) >> >> one gives: >> >> Host host.example.com failed: SSL_connect returned=1 errno=0 state=SSLv3 >> read server certificate B: certificate verify failed >> >> All then give an exit code of 2 >> >> I have deleted /etc/puppet/ssl on the node and revoked the certs on the >> puppet master (puppetca -c host.example.com) with the same results on all 3 >> boxes. >> >> I know it is not my laptop's fault but I am about to throw it out the >> window... >> >> Please save the poor thing and give me a hint as to what else I can do... >> >> Thanks, > > What version of puppet is running on the clients? What version on the server? > > Client is 2.6.7 > Server is 2.6.4 > > > Did you forget "listen=true" on the ones that say "connection refused"? > > No They are all the same... > > > Is "host.example.com" the master or the client you're kicking? > > host.example.com is the client I am trying to kick > > > On the client and the server, try this command: > md5sum /var/lib/puppet/ssl/ca/ca_crt.pem > > On the server try this command: > md5sum /var/lib/puppet/ssl/certs/ca.pem > > Do all 3 certs match? > None of the files exist. (our puppet config files are in /etc) Hmm. I'd guess puppet's storing the ssl config in a different location from where puppet stores them on my system. To get the of those files for you run as root: puppetd --genconfig | grep 'localcacert = ' " on the client to find the client's ssl cert location. CA's cert path (run as root): puppet master --genconfig | grep ' cacert = ' Then check if the md5sums of those files match between the server and the client that gives the SSL Verify error. -- 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] Server side filebucket issue
I am having issues with filebucket. I have looked through the puppet
users google groups with similar issues but have not found a solution
that works.
I am trying to setup a central filebucket on the puppetmaster server.
I am replacing the client's /etc/puppet/puppet.conf file with a
preconfigured version. The server delivers a copy of the puppet.conf
file to the client, but the backup puppet.conf file is stored in the
clients /var/lib/puppet/clientbucket directory.
I have defined a filebucket in the site.pp manifest, I have called the
backup directive in a class called client-conf.
Both files are listed below.
Can you help me or point me to a solution please?
Cheers
LawrieC
site.pp contains
#Define server filebucket as destination for file backups.
#
filebucket { puppet:
server => puppetmaster-cbr.it.csiro.au
}
module client-conf contains
class client-conf {
# Class to replace client's puppet.conf file with a pre-configured
puppet.conf.
# Replace client's puppet.conf file with a pre-configured puppet.conf
file. Backup the clients existing puppet.conf file.
#
file { "/etc/puppet/puppet.conf":
owner => "root",
group => "root",
mode => "0640",
source => "puppet:///modules/client-conf/puppet.conf",
backup => puppet
}
}
Below is an extract of the debug dialogue between the client and the
server.
debug: /Stage[main]/Client-conf/File[/etc/puppet/puppet.conf]/content:
Executing 'diff -u /etc/puppet/puppet.conf /tmp/puppet-
file20110530-21374-19v5hpf-0'
--- /etc/puppet/puppet.conf 2011-05-30 12:46:48.0 +0930
+++ /tmp/puppet-file20110530-21374-19v5hpf-02011-05-30
12:47:06.0 +0930
@@ -14,7 +14,7 @@
# Module path
# modulepath = /etc/puppet/modules
- ##
+
# Enable Pluginsync to make custom facts visible to client
machines
pluginsync = true
factpath = $vardir/lib/facter
debug: Finishing transaction 70040199723080
info: FileBucket adding /etc/puppet/puppet.conf as {md5}
a7cba91810e80edb9b72f3070e6809b4
info: /Stage[main]/Client-conf/File[/etc/puppet/puppet.conf]:
Filebucketed /etc/puppet/puppet.conf to puppet with sum
a7cba91810e80edb9b72f3070e6809b4
debug: file_metadata supports formats: b64_zlib_yaml marshal pson raw
yaml; using pson
notice: /Stage[main]/Client-conf/File[/etc/puppet/puppet.conf]/
content: content changed '{md5}a7cba91810e80edb9b72f3070e6809b4' to
'{md5}c777f1c5a94ca961292e3ff03b4efa7b'
--
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] Concat Module posted to Onyx Point Github.
Currently, the way that I'm preventing this is by bookending the
concat_build with a file object.
Basically:
concat_build { 'foo': target => '/etc/foo' }
file { '/etc/foo': checksum => md5, owner, mode, etc }
something { 'bar': subscribe => File['/etc/foo'] }
It's not elegant, but, in most cases, I wanted to manage the file
anyway and didn't relish trying to inherit the file type and do
anything useful.
Trevor
On Thu, Jun 2, 2011 at 9:02 AM, Greg Sutcliffe wrote:
> Hi Trevor,
> I'll add my thanks to the pile, this is pretty awesome stuff! I compared the
> --graph results with the old concat moule, and this one - impressive
> difference :)
> As Larry says, the fact that it executes Concat_build on every run is a
> stopper for us, since the dependant services get restarted and we get report
> emails of any changes.
> Also, I can't see any way to hook into the filebucket for backups. I managed
> to hack in a "cp file file.bak" type functionality just before it actually
> cp's the newly-built file. However, my Ruby-fu isn't up to pulling in the
> filebucket stuff yet - might be worth adding to the todo list.
> Thanks again for the great module though :)
> Greg
>
> --
> 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/-/OXRxUlV4QnVxU3NK.
> 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.
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
--
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] Concat Module posted to Onyx Point Github.
Thanks for the patch set! Feel free to add a pull request on GitHub, that way I can also just pull into a branch. Trevor On Thu, Jun 2, 2011 at 11:25 AM, James Turnbull wrote: > Greg Sutcliffe wrote: >> Hi again, >> >> After an hour or three of hacking, I've managed to add the insync? >> checks to both the build and fragment types. It's the first time I've >> ever really messed with types and providers, so it's very ugly (and >> probably has bugs), however I'm happy to share my patches. Would that be >> best a) here b) in puppet-dev, or c) direct to Onyx Point? >> > > Awesome stuff! The puppet-dev list is the best place. > > Cheers > > James > > -- > James Turnbull > Puppet Labs > 1-503-734-8571 > > -- > 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. > > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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] Certificate problems
On Thu, Jun 2, 2011 at 9:32 AM, John Kennedy wrote: > >> What version of puppet is running on the clients? What version on the >> server? >> >> Client is 2.6.7 > Server is 2.6.4 > Although this may work, the only supported configuration is to have the server the same version as the clients or newer. I have no actual evidence this is your problem though. -- 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] Resources existing in different operating systems.
So... I'm thinking about how to have puppet manage different operating systems. It's one thing to use a selector to determine the value of specific resources attribute, but what do you do when a file may not exist on a specific O/S? You can't use a selector in this case. I really don't like the approach described here either... http://m0dlx.com/blog/Puppet_manifests__a_multi_OS_style_guide.html ...where classes are loaded dynamically based on the value of a variable. What would best practice indicate? Doug. -- 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] Package type: enable/disable repo vs options (#2247 vs #4113)
On Thursday, June 2, 2011 at 10:16 AM, Jacob Helwig wrote: > We currently have to feature requests to add similar (or at least > overlapping) functionality to the Package type. > > #2247[1] - enablerepo and disablerepo for yum type > > #4113[2] - Provide a generic "options"-style parameter for packages. > > It seems like having #4113 would remove the need for having #2247, but I > wanted to get some wider opinions to make sure I wasn't ignoring some > use-case that would make this not the case. > > Personally, I think we should move forward on #4113 instead of #2247, > since #4113 seems like the more general solution, and isn't tied > directly to the yum provider. > > #2247 does currently have some code submitted for it, however it > requires a signed CLA before we can accept it. While no code has been > written for #4113 yet, it doesn't look like it would actually be that > much work to do. > > Thoughts? Opinions? Comments? > It looks like the crux of this problem is that many, many providers add their own, fairly unique, capabilities. We then try to model all of these capabilities in the type, and end up with a package type that has ~15 parameters, many of which are ignored on almost all providers, and no properties. And yet we have no real ability to add provider-specific attributes, aside from adding them to the type, with an associated feature, and declaring our provider as the only one that supports that feature. So my generic proposal is that we add some better way to do that. To keep the definition of a resource consistent across providers, this should only allow additional parameters (data) to be specified, and not properties. I have a few ideas for this: 1) Add an 'options' or 'data' or similar metaparameter which accepts a hash. This would basically be a place to add arbitrary data accessible to the provider. Thus, for the enablerepo example, it would just be a key/value in the options hash. Any provider is free to use or ignore it as desired. A big problem with this is there's no real validation for which keys are allowed, or what they must look like, which leads us to: 2) As 1, but with an ability for a provider to specify the options acceptable. In this case, a provider would have some method for declaring a legal option, and its validation and/or munging. But in this case, what's the difference between a parameter and an option? Apparently only where/how we declare and specify them. Although, there may be some benefit to distinguishing generic type parameters from provider-specific options. 3) As 2, but remove the concept of parameters. This is one possible way to reconcile the difference between parameters and options. But is there really an advantage to wrapping all of our data which is essentially parameters in a hash? Maybe, for distinguishing parameters from properties, but probably not. 4) As 2, but instead using something like newparam on provider. This is similar to the previous idea, in that it unifies "options" and "parameters", but in the other direction. In addition to specifying generic type parameters, also add the ability to specify provider-specific parameters. This has the advantage of not requiring any changes to existing manifests using provider parameters. It has the disadvantage that we can't really validate provider parameters on the master (though we've talked about removing validation on the master anyway). Since I can't even decide which of my own four suggestions I prefer, please poke holes in as many of them as you can to ease my mental burden. :) > [1] http://projects.puppetlabs.com/issues/2247 > [2] http://projects.puppetlabs.com/issues/4113 > > -- > Jacob Helwig -- 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: [Puppet-dev] Package type: enable/disable repo vs options (#2247 vs #4113)
On 02/06/11 18:16, Jacob Helwig wrote: > We currently have to feature requests to add similar (or at least > overlapping) functionality to the Package type. > > #2247[1] - enablerepo and disablerepo for yum type > > #4113[2] - Provide a generic "options"-style parameter for packages. > > It seems like having #4113 would remove the need for having #2247, but I > wanted to get some wider opinions to make sure I wasn't ignoring some > use-case that would make this not the case. The only use case I can't see being solved with #4113, is support for selecting a repo with the zypper package provider. It selects a repo by running "zypper install repo:package" (as I understand it), rather than as a separate command line option. > Personally, I think we should move forward on #4113 instead of #2247, > since #4113 seems like the more general solution, and isn't tied > directly to the yum provider. I'd prefer to see both. I don't think #2247 needs to be tied to yum as the same notion of selecting the source repository(s) applies to four other providers[1], not to mention the others that already have this ability via the "source" attribute to select a repository by URL. The difficulty might be how to design it so that it's generic enough, rather than using attributes named enablerepo and disablerepo (which I dislike, because they're so very yum-specific). I have a more detailed suggestion I can outline in another post.. [1] http://projects.puppetlabs.com/issues/2247#note-36 -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- 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] Package type: enable/disable repo vs options (#2247 vs #4113)
+1 for #4113 Charles On Thu, Jun 2, 2011 at 12:16 PM, Jacob Helwig wrote: > We currently have to feature requests to add similar (or at least > overlapping) functionality to the Package type. > > #2247[1] - enablerepo and disablerepo for yum type > > #4113[2] - Provide a generic "options"-style parameter for packages. > > It seems like having #4113 would remove the need for having #2247, but I > wanted to get some wider opinions to make sure I wasn't ignoring some > use-case that would make this not the case. > > Personally, I think we should move forward on #4113 instead of #2247, > since #4113 seems like the more general solution, and isn't tied > directly to the yum provider. > > #2247 does currently have some code submitted for it, however it > requires a signed CLA before we can accept it. While no code has been > written for #4113 yet, it doesn't look like it would actually be that > much work to do. > > Thoughts? Opinions? Comments? > > [1] http://projects.puppetlabs.com/issues/2247 > [2] http://projects.puppetlabs.com/issues/4113 > > -- > Jacob Helwig > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQGcBAEBAgAGBQJN58V4AAoJEHJabXWGiqEBjbEL/2Rm3YS7DL5nMj0O2GmOKwC8 > 78uG3dfpdzrM7FPKruMzUIAEMv+OIYzyp8moUvtRPz/lWgC2Qy0ubI6Ras4CDiaT > EXxC9GtAx9cJ7ZhzxhzDjhb8ZTeOoejKVUIddxt6NZRyYxtE4soK3Cmuj6/c8rp3 > mwkTgSrXgd4s8lpWi60s9D726e1z7uQwXIMeIUGM5XOa1Me3AcX87lKoillrqq7d > gkaYbRvdh8k/EFpA6qdyHaRblXWMO7YelpJ5RmDq2sMbAX+x0dF5tW2wdQFuv3t8 > F9M8w9L/itQSfu5bHT/VAylLx+5jkITCty1GsKMGKrujqetzfD94zLTTOVr1XZ+t > OxLfpFrjL9VRaEvWmtyoPOaRKFouubbIVl/7gNF026FfEU97mGytHgdgy2BDP5wg > G6lnq7qwVd77ZniaxuHgZvBwlhnqFUJ+ma+4gPog4sa6Z6t+IDKAHC+Sepaba0dN > R+u+YHkkjGD2ZursvkZdQsASNWGG4CiP4gnqEdZccg== > =AcGW > -END PGP SIGNATURE- > > -- 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] Package type: enable/disable repo vs options (#2247 vs #4113)
We currently have to feature requests to add similar (or at least overlapping) functionality to the Package type. #2247[1] - enablerepo and disablerepo for yum type #4113[2] - Provide a generic "options"-style parameter for packages. It seems like having #4113 would remove the need for having #2247, but I wanted to get some wider opinions to make sure I wasn't ignoring some use-case that would make this not the case. Personally, I think we should move forward on #4113 instead of #2247, since #4113 seems like the more general solution, and isn't tied directly to the yum provider. #2247 does currently have some code submitted for it, however it requires a signed CLA before we can accept it. While no code has been written for #4113 yet, it doesn't look like it would actually be that much work to do. Thoughts? Opinions? Comments? [1] http://projects.puppetlabs.com/issues/2247 [2] http://projects.puppetlabs.com/issues/4113 -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] Certificate problems
Replies inline On Wed, Jun 1, 2011 at 17:55, Patrick wrote: > > On Jun 1, 2011, at 8:05 AM, John Kennedy wrote: > > I have several servers being hosted on Amazon Web Services. They have all > been build from the same manifest so apart from the hostnames, IP, etc they > are all identical. > > All but 3 of the boxes can connect to the puppetmaster. When kicked from > the puppetmaster two give: > Host host.example.com failed: Connection refused - connect(2) > > one gives: > > Host host.example.com failed: SSL_connect returned=1 errno=0 state=SSLv3 > read server certificate B: certificate verify failed > > All then give an exit code of 2 > > I have deleted /etc/puppet/ssl on the node and revoked the certs on the > puppet master (puppetca -c host.example.com) with the same results on all > 3 boxes. > > I know it is not my laptop's fault but I am about to throw it out the > window... > > Please save the poor thing and give me a hint as to what else I can do... > > Thanks, > > > What version of puppet is running on the clients? What version on the > server? > > Client is 2.6.7 Server is 2.6.4 > > > Did you forget "listen=true" on the ones that say "connection refused"? > > No They are all the same... > > > Is "host.example.com" the master or the client you're kicking? > > host.example.com is the client I am trying to kick > > > On the client and the server, try this command: > md5sum /var/lib/puppet/ssl/ca/ca_crt.pem > > On the server try this command: > md5sum /var/lib/puppet/ssl/certs/ca.pem > > Do all 3 certs match? > None of the files exist. (our puppet config files are in /etc) > -- > 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. > -- John Kennedy -- 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] ruby dsl manifests
Thanks for the reply, from what you said it might be better for me to go about it in a different direction. On Thu, Jun 2, 2011 at 1:07 AM, Dan Bode wrote: > you should be able to do something like: > > call_function(:defined, 'Foo['bar']') > > just keep in mind that the defined function (or anything for resource > detection) is parse order dependent which can lead to unexpected results. > > > On Wed, Jun 1, 2011 at 9:04 PM, Matt wrote: > >> I've been searching and havent found an answer yet. Is there a scope >> or variable that I can parse to find out if a resource is defined? I >> know there is the defined command in puppet manifests. >> >> -- >> 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] uploading files via REST?
Still, this doesn't seem to work in my test setup, i.e. apache as proxy in
front of puppet. I get a "..timeout specified has expired: proxy: prefetch
request body failed to 127.0.0.1:18140" in apache's log.
GETs do work, just PUTs fail. Config is
Listen 8140
BalancerMember http://127.0.0.1:18140
BalancerMember http://127.0.0.1:18141
SSLEngine On
SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA
SSLCertificateFile /var/lib/puppet/ssl/certs/server.pem
SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/server.pem
SSLCertificateChainFile /var/lib/puppet/ssl/ca/ca_crt.pem
SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem
SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem
SSLVerifyClient require
SSLVerifyDepth 1
SSLOptions +StdEnvVars
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
SetHandler balancer-manager
Order allow,deny
Allow from all
ProxyPass / balancer://puppetmaster/
ProxyPassReverse / balancer://puppetmaster/
ProxyPreserveHost On
ErrorLog /mirror/log/balancer_error_log
CustomLog /mirror/log/balancer_access_log "%h %l %u %t \"%r\" %>s %b
\"%{SSL_CLIENT_S_DN}x\" \"%{User-Agent}i\""
and the perl code is
{
open my $up, "<", "$_[0]" or die "Something went wrong: ".$!; binmode
$up;
my $ck = Digest::MD5->new; $ck->addfile($up); close $up;
my $req = HTTP::Request::StreamingUpload->new(
PUT => "https://
".$server."/file_bucket_file/tftp/md5/".$ck->hexdigest,
path => $_[0],
headers => HTTP::Headers->new(
'Content-Type' => 'application/binary',
'Content-Length' => -s $_[0],
'Accept' => 's',
),
);
my $res = $ua->request($req);
die "Something went wrong: ".$res->status_line unless $res->is_success;
return $res->content;
}
SSL handshake does work, but the puppet process doesn't seem to receive any
data (I'm tailing its debug log). Not sure if I am doing something wrong, or
it is a problem in mod_proxy..
On Thu, Jun 2, 2011 at 4:47 PM, Razvan Cosma wrote:
>
> On Tue, May 31, 2011 at 7:41 PM, Daniel Pittman wrote:
>
>> On Tue, May 31, 2011 at 07:21, RCosma wrote:
>> > Should I compute the MD5 of the file and port its contents at the url ?
>>
>> Yeah, you would need to: the indirector, which this is an instance of,
>> requires that you uniquely identify where you are writing to. So, in
>> the case of the filebucket the "key" is that MD5 checksum; you would
>> need to calculate it for the file and supply it.
>>
>>
--
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] Concat Module posted to Onyx Point Github.
Greg Sutcliffe wrote: > Hi again, > > After an hour or three of hacking, I've managed to add the insync? > checks to both the build and fragment types. It's the first time I've > ever really messed with types and providers, so it's very ugly (and > probably has bugs), however I'm happy to share my patches. Would that be > best a) here b) in puppet-dev, or c) direct to Onyx Point? > Awesome stuff! The puppet-dev list is the best place. Cheers James -- James Turnbull Puppet Labs 1-503-734-8571 -- 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] uploading files via REST?
Thank you, and one more q: can I specify a folder/share for the uploaded
file, assuming there are several available?
On Tue, May 31, 2011 at 7:41 PM, Daniel Pittman wrote:
> On Tue, May 31, 2011 at 07:21, RCosma wrote:
> > Hello,
> > I am a bit confused by the REST syntax - how can I PUT an arbitrary file
> in
> > the bucket? Downloading works fine (Perl+LWP), see below, but for PUT I
> only
> > see this line in the docs (
> http://docs.puppetlabs.com/guides/rest_api.html):
> > PUT /{environment}/file_bucket_file/md5/{checksum}
> > Should I compute the MD5 of the file and port its contents at the url ?
>
> Yeah, you would need to: the indirector, which this is an instance of,
> requires that you uniquely identify where you are writing to. So, in
> the case of the filebucket the "key" is that MD5 checksum; you would
> need to calculate it for the file and supply it.
>
> There is no support in the indirector for uploading the data with the
> server calculating the checksum.
>
> (As a side note, I don't think we actually *check* you were honest
> about that, other than when the target checksum already exists, so
> please try not to lie about it. ;)
>
> Daniel
> --
> ⎋ Puppet Labs Developer – http://puppetlabs.com
> ✉ Daniel Pittman
> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
> ♲ Made with 100 percent post-consumer electrons
>
> --
> 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] Re: Any good documentation NGINX + Passenger + Puppet?
Thanks
It end up a restart of nginx and everything is working! So pretty
happy
my next thing would be document what I did and make that available to
whoever needs it
On Jun 2, 4:28 am, Russell Howe wrote:
> > 3. SO my next issue is a function I wrote (random minute for
> > cron), this stopped working, So instead of executing the
> > function is takes is a value... Anyone ???
>
> I can't help with the problem you're having, but would this do for your
> random minute?
>
> # Random minute between 10 past and 10 to the hour
> $random_minute = fqdn_rand(40) + 10
> cron { "foo":
> command => "bar",
> minute => $random_minute,
> ensure => present,
> }
>
> fqdn_rand is described
> here:http://docs.puppetlabs.com/references/stable/function.html#fqdnrand
>
> --
> Russell Howe
> rh...@moonfruit.com
--
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] Concat Module posted to Onyx Point Github.
Hi again, After an hour or three of hacking, I've managed to add the insync? checks to both the build and fragment types. It's the first time I've ever really messed with types and providers, so it's very ugly (and probably has bugs), however I'm happy to share my patches. Would that be best a) here b) in puppet-dev, or c) direct to Onyx Point? Cheers, Greg -- 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/-/bDJFMXd4Q0VFMG9K. 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] Concat Module posted to Onyx Point Github.
Hi Trevor, I'll add my thanks to the pile, this is pretty awesome stuff! I compared the --graph results with the old concat moule, and this one - impressive difference :) As Larry says, the fact that it executes Concat_build on every run is a stopper for us, since the dependant services get restarted and we get report emails of any changes. Also, I can't see any way to hook into the filebucket for backups. I managed to hack in a "cp file file.bak" type functionality just before it actually cp's the newly-built file. However, my Ruby-fu isn't up to pulling in the filebucket stuff yet - might be worth adding to the todo list. Thanks again for the great module though :) Greg -- 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/-/OXRxUlV4QnVxU3NK. 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] Re: Any good documentation NGINX + Passenger + Puppet?
> 3. SO my next issue is a function I wrote (random minute for
> cron), this stopped working, So instead of executing the
> function is takes is a value... Anyone ???
I can't help with the problem you're having, but would this do for your
random minute?
# Random minute between 10 past and 10 to the hour
$random_minute = fqdn_rand(40) + 10
cron { "foo":
command => "bar",
minute => $random_minute,
ensure => present,
}
fqdn_rand is described here:
http://docs.puppetlabs.com/references/stable/function.html#fqdnrand
--
Russell Howe
rh...@moonfruit.com
--
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] [SOLVED] line replace triggers file reload
On Wed, Jun 1, 2011 at 11:22 PM, Giovanni Bordello wrote: > Sorted, I've done it using a template: > > search <%= dns_search_path %> > nameserver ... > nameserver ... > > That way the file is (presumably?) created on the master and looks constant > to the client. > > To answer your implicit question. The file is generated on the master and embedded in the catalog. Then the catalog is send to the client. -- 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] Managing /etc/fstab options with augeas
Hi again,
I'm trying to manage mount options in /etc/fstab with Augeas but can't
figure out how to add more than one option.
augeas { "/etc/fstab":
context => "/files/etc/fstab",
changes => [
'set *[file = "/tmp"]/opt nosuid',
'set *[file = "/home"]/opt nosuid',
],
}
I would like to add "nodev" as well but can't figure out how. When I
simply replace "nosuid" with "nosuid,nodev" it fails with:
err: /Stage[main]/System::Files/Augeas[/etc/fstab]/returns: change from
need_to_run to 0 failed: Save failed with return code false
I have just spent some time in augtool but am still confused. I have
manually changed the options for /apps to defaults,nosuid and this is
augtool's output:
augtool> print /files/etc/fstab/*[file = "/apps"]
/files/etc/fstab/3
/files/etc/fstab/3/file = "/apps"
/files/etc/fstab/3/opt[1] = "defaults"
/files/etc/fstab/3/opt[2] = "nosuid"
[..]
Now I can "set /files/etc/fstab/3/opt[2] nodev" but can't figure out:
1. how to do it with the [file="/apps"] because I don't know the index
(.../3/...) for each mountpoint.
2. how to add a new 'opt' for mountpoints that only have 'default' at
the moment.
Any ideas?
Thanks!
GiBo
--
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.
