[Puppet Users] puppet error in component.rb
I am implementing a scheme to manage our server configuration using Puppet + git + rsync. I run Puppet on nodes as a cron job, and I am getting errors as follows. /usr/local/lib/site_ruby/1.8/puppet/type/component.rb:4: [BUG] terminated node (0xb77054c4) ruby 1.8.7 (2010-01-10 patchlevel 249) [i486-linux] Executing the cron job command in a shell executes successfully. Usually, this suggests something wonky in the environment, but I can't think of anything that would cause such an error. I don't know Ruby at all, but I looked at the Ruby source code and this error is raised from eval.c, which suggests a parsing error of some sort. Any help, suggestions or speculation would be appreciated. ------ Charles Yeomans Senior Software Engineer Dakim, Inc. char...@dakim.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-us...@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] How to bootstrap a new puppet instance?
On Aug 26, 2010, at 11:36 AM, Mike Peck wrote: I've spent some time beginning to learn how puppet works, and one seemingly rather daunting task I'm facing, is how to setup the initial state of things. What I'm specifically thinking about, is that I have machines running that I want to get their current state pulled into puppet. How do I do that? I have various flavors/versions of BSD systems and various flavors/versions of *nix machines, and right now it's seeming like I have to tackle each one of each type, one by one, figuring out all the myriad steps needed to build each one. One thing I may be mis-understanding, however, is the base OS. Should I be expecting to have puppet start from a freshly installed OS, and if so what level of configuration should be assumed? I am expecting puppet to be able to handle OS updates, but I haven't yet run across examples of that. Does anybody know of any docs that describe what a significantly sized existing organization might go through in order to adopt puppet? Of course I would expect this to ignore all the policy issues of adoption, I'm looking for ideas on how to get started. I've been engaged in more or less the same task. One suggestion I have is that you don't need to do it all up front. You can get Puppet installed and running on all of your nodes with trivial configuration for each. You (or some delegates) can then update the configuration bit by bit, and refactor into modules as appropriate. -- Charles Yeomans Senior Software Engineer Dakim, Inc. char...@dakim.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-us...@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] Is a puppet server essential?
On Aug 26, 2010, at 10:04 PM, bonobo wrote: It appears that running a puppet server is essential. In his book "Pulling Strings with Puppet", James Turnbull says: "... the node will request whatever configuration is specified for that node. The master server will then compile and deliver that configuration." [p. 25] Our firewall environment is very restrictive, and there's no way a server on our publicly accessible network will be allowed to initiate a connection to a puppet server on our internal network. (Of course, I could run the puppet server on the publicly accessible network, but you have no idea what a hassle that would be.) Since the configuration is compiled on the server, is it impossible to run puppet without allowing clients to initiate connection to the puppet server? We are running puppet in standalone mode on nodes in a setup that does not require punching holes in the firewall. We use rsync to push configuration information to nodes. Our Puppet configurations live on a server running gitosis. As changes are committed by sys admins, gitosis hook scripts move the data along and run rsync. ------ Charles Yeomans Senior Software Engineer Dakim, Inc. char...@dakim.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-us...@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: Inherit VS include
On Aug 31, 2010, at 11:48 AM, Nigel Kersten wrote:
> On Tue, Aug 31, 2010 at 4:35 AM, Oliver Hookins wrote:
>> On Aug 31, 10:09 am, Kenneth Holter wrote:
>>> Hello all.
>>>
>>> Are there any rule of thumb regarding using "inherits" versus "include"? For
>>> example, if I'm creating the class "syslog::base" which should servere as a
>>> building block for syslog clients, should I go for a "class syslog::client
>>> inherits syslog::base { }" or "class syslog::client { include
>>> syslog::base }"?
>>
>> Directly from the horse's mouth (we have training this week)...
>> Inherits should only be used when you actually intend to use inherits
>> with overrides. If you don't it makes the code less understandable
>> than if you just used includes. It's more a code understandability
>> issue than functionality.
>
> ++
>
> You really don't want to bother with inherits unless you're overriding
> resources in the parent.
>
> I still feel like we don't have a good term for "namespace" children
> classes, as in a succinct and accurate term for the relationship
> between "syslog" and "syslog::foo". They're not child classes, they're
> ... ?
>
I might call them "nested classes".
--
Charles Yeomans
Senior Software Engineer
Dakim, Inc.
char...@dakim.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-us...@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] Design help: django deployment
> On Feb 10, 2015, at 5:13 AM, Jonathan Gazeley > wrote: > > Hi folks, > > The developers at my place are designing a new set of webapps, which will be > written in Python/Django. This is new to us (our old stuff is nasty Perl) and > I've been asked to look at how to deploy these new apps using Puppet. > > The Django apps will be developed in Git repos and releases will be tagged so > I am envisaging using puppetlabs/vcsrepo to deploy releases of the apps to > the web server's filesystem. The developers want to use virtualenv to handle > dependencies in their apps. Is there are a recommended method among other > Puppet admins to deploy Django apps from git with virtualenv and have them > served preferably with Apache or Nginx? > > I can't find a monolithic module to do this on the Forge so if nobody has a > wiser suggestion, I will probably write something using puppetlabs/vcsrepo, > stankevich/python and puppetlabs/apache. > There are plenty of little problems you'll need to solve here. As for the server, my preference is to use Nginx and reverse-proxy to Apache + mod_wsgi. A good way to set up the Django python stuff is to make one or more python packages and install them using pip. This approach works well with git, virtualenv and puppet. Then you'll be left to deal with Django itself... Charles Yeomans -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/B5ADABCB-5962-47BC-81E2-081A34E12B36%40dakim.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Update package (latest) only if installed in Debian
Probably the simplest approach would be to write an exec resource using the
command
/usr/bin/apt-get install --only-upgrade
for apt packages.
Charles Yeomans
> On Feb 24, 2015, at 10:47 AM, Ximena Cardinali
> wrote:
>
> I just want to upgrade specific Packages.
>
> The idea is something like : ensure=>latest, onlyif=>present
>
> Cheers,
> Ximena.
>
> On Tuesday, 24 February 2015 16:43:06 UTC+1, David Schmitt wrote:
> On 2015-02-24 16:28, Ximena Cardinali wrote:
> > Hello There,
> >
> > I'm trying to write a module to update certain vulnerable packages in
> > Debian Systems.
> > My idea is to update them only and only if they are *installed*. Is
> > there any exec command or any other tricks that you may know to do that?
> >
> > So far, I've got the basics: :$
> >
> > package { '$package_update':
> > name=> $package_update,
> > ensure => latest,
> > }
> >
> > Can anyone throw me an idea? I will really appreciate it!
>
> What about "aptitude full-upgrade"?
>
> Regards, David
>
> --
> * Always looking for people I can help with awesome projects *
> Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
> Blog: http://club.black.co.at/log/
> LinkedIn: http://at.linkedin.com/in/davidschmitt
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/72682c9d-5194-4cf9-9b65-729eebd77645%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/1CA1A652-88A5-454C-AB34-F5245DC96A85%40dakim.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Question about setting master-less server
> On Mar 11, 2015, at 8:32 PM, Hubert Lubaczewski wrote:
>
> Hi,
>
> I'm trying to learn puppet by using it on a test machine I have. Figured that
> for single server, it makes sense to use master-less mode.
>
> So, my question is like this. To set it up, I figured that:
> 1. /etc/puppet would be clone of some repo
> 2. in /etc/puppet/manifests/site.pp, I would add vcsrepo{} that would make
> sure that puppet will update itself on each run
> 3. I'll add a cronjob to periodically run "puppet apply
> /etc/puppet/manifests/site.pp"
>
> Optionally, I would run "git pull" before actual puppet apply, so that puppet
> will run on already updated repo.
>
> Does it make sense? Am I missing something? I know it's pretty basic, but in
> one place I had to write quite a lot of manifests/modules for puppet, and
> finally decided to setup whole machine, on my own, using puppet.
>
> Thanks for any help/guidance,
>
> depesz
>
I've used masterless puppet setups for several years.
My current starter template for puppet projects is at
https://github.com/declaresub/git-puppet-bootstrap . It may be useful for what
you want to do. It is intended for use with VMs; I've tested it with Ubuntu
12.04 and Debian Wheezy on Linode and Vagrant VMs.
I have a simple puppet module for postgresql if you need one too :)
Charles
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/600A56EB-E62D-479F-8A52-5E81691A54DC%40dakim.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Question about setting master-less server
The basic idea is this: you have a server to be configured using puppet. On
your machine, you have a git repository containing the puppet configuration,
plus some other scripts. The puppet configuration sets up /var/lib/git as the
home directory for user git, and a remote clone of your git repository is
stored there. The script run_puppet.bash gets the puppet config from the git
repository and copies it to /etc/puppet_hash, and sets a symlink to
/etc/puppet.
The git repository on the server is bare, so I can't just make a symlink from
/etc/puppet to the config directory in the repository. Thus the need to export
it, and it seems a little wasteful to do the export every time. So I export to
/etc/puppet_hash and symlink /etc/puppet to this directory. Then I export only
if the repository has been updated.
You push from your git repository to the server repository over ssh; thus the
purpose of the ssh keys is to enable this communication. It is often the case
that puppet repositories contain sensitive information such as passwords, so I
prefer not to put the repository on servers not under my control (i.e. github
or bitbucket). Also, introducing something like github brings with it a fair
amount of additional work to set up and maintain the chain. The approach I'm
using works for multiple developers and multiple servers (e.g.
development/test/production).
I suppose I could pull the sensitive bits out of the puppet configuration and
store them in yet another location, but this starts up the Puppet Workaround
Stack that I try to avoid.
Charles
> On Mar 11, 2015, at 11:46 PM, Hubert Lubaczewski wrote:
>
> Hi,
> I checked the repo, but I don't understand what you wrote in the README. What
> is the purpose of these ssh keys? Why are you, in the run_puppet script,
> copying config to some place versioned by git commit, and run puppet from
> there, instead of just keeping /etc/puppet as git repo?
>
> Basically - it is likely that your scripts solve problems that I am not aware
> of, yet, but then, would greatly appreciate more information what it is for -
> I can read what it does, but why?
>
> depesz
>
> On Thursday, March 12, 2015 at 3:38:21 AM UTC+1, Charles Yeomans wrote:
> > On Mar 11, 2015, at 8:32 PM, Hubert Lubaczewski wrote:
> >
> > Hi,
> >
> > I'm trying to learn puppet by using it on a test machine I have. Figured
> > that for single server, it makes sense to use master-less mode.
> >
> > So, my question is like this. To set it up, I figured that:
> > 1. /etc/puppet would be clone of some repo
> > 2. in /etc/puppet/manifests/site.pp, I would add vcsrepo{} that would make
> > sure that puppet will update itself on each run
> > 3. I'll add a cronjob to periodically run "puppet apply
> > /etc/puppet/manifests/site.pp"
> >
> > Optionally, I would run "git pull" before actual puppet apply, so that
> > puppet will run on already updated repo.
> >
> > Does it make sense? Am I missing something? I know it's pretty basic, but
> > in one place I had to write quite a lot of manifests/modules for puppet,
> > and finally decided to setup whole machine, on my own, using puppet.
> >
> > Thanks for any help/guidance,
> >
> > depesz
> >
>
>
> I've used masterless puppet setups for several years.
>
> My current starter template for puppet projects is at
> https://github.com/declaresub/git-puppet-bootstrap . It may be useful for
> what you want to do. It is intended for use with VMs; I've tested it with
> Ubuntu 12.04 and Debian Wheezy on Linode and Vagrant VMs.
>
> I have a simple puppet module for postgresql if you need one too :)
>
> Charles
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/85ee6161-3430-4d60-8efc-6cbe66032508%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/8B0737E0-2093-464F-9601-08BC2B1D2BA5%40dakim.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Question about setting master-less server
If I understand your question, the reason I don't just export to /etc/puppet is that the git repository contains files other than the puppet configuration, and I prefer to keep those files out of the puppet directory. Certainly one could clone the bare repository in /var/lib/git, and symlink /etc/puppet to the puppet directory in that non-bare repository. Then the script that executes puppet apply would first run git pull, then puppet apply. I didn't do it that way for no reason other than I didn't think to do it that way. In fact it might be less complicated to implement, in exchange for some more disk space. Charles > On Mar 12, 2015, at 10:42 AM, hubert depesz lubaczewski > wrote: > > I understand most of it, but why checkout as /etc/puppet_hash, and and not > simply as /etc/puppet, and just `git pull` when necessary? > > I.e. What is the benefit of having to do clone from scratch on every run > (i.e. when something has changed)? > > depesz > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/190FCE9C-CD14-47C3-A338-D3ECEB13D6CB%40dakim.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Question about setting master-less server
No; there would be two repositories on the server. The repository in /var/lib/git is bare; recall that a bare git repository does not have a working copy. It would be possible to make the server repository non-bare, but that's generally a bad idea. Charles > On Mar 12, 2015, at 3:35 PM, hubert depesz lubaczewski > wrote: > > Why more disk space use? There would still be one clone of the repo, it just > would be located in different place (not /etc/puppet_HASH, but directly > /etc/puppet). > > I think i can see one benefit of doing it the way you did it - we have > guarantee that there will be no things in /etc/puppet that were added without > adding them to git repo. Which is a good thing, I guess. > > Thanks, > > depesz > > On Thu, Mar 12, 2015 at 8:12 PM, Charles Yeomans wrote: > If I understand your question, the reason I don't just export to /etc/puppet > is that the git repository contains files other than the puppet > configuration, and I prefer to keep those files out of the puppet directory. > > Certainly one could clone the bare repository in /var/lib/git, and symlink > /etc/puppet to the puppet directory in that non-bare repository. Then the > script that executes puppet apply would first run git pull, then puppet > apply. I didn't do it that way for no reason other than I didn't think to do > it that way. In fact it might be less complicated to implement, in exchange > for some more disk space. > > > Charles > > > On Mar 12, 2015, at 10:42 AM, hubert depesz lubaczewski > > wrote: > > > > I understand most of it, but why checkout as /etc/puppet_hash, and and not > > simply as /etc/puppet, and just `git pull` when necessary? > > > > I.e. What is the benefit of having to do clone from scratch on every run > > (i.e. when something has changed)? > > > > depesz > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/29040E55-23D7-46DA-9FA0-6C7163695842%40dakim.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Question about setting master-less server
In my current scheme, I export the git repository, grab the puppet subdirectory from the export, and move it to /etc/puppet_hash. I put it there instead of /etc/puppet because I only want to update the files if there is a new commit. To check this, I need to store the hash of the HEAD of the exported code somewhere. Instead of writing that information to a separate file, I stick it into the filename of the puppet config. Charles > On Mar 12, 2015, at 7:35 PM, hubert depesz lubaczewski > wrote: > > Sure. I wasn't talking about what's in /var/lib/git. > > In your approach there is bare in /var/lib/git/server, and checkout/clone in > /etc/puppet_HASH. > The situation I was asking about is where there is still bare in > /var/lib/git/server (or wherever I will decide to put it), and checkout/clone > in /etc/puppet > > Since you are symlinking /etc/puppet to /etc/puppet_HASH the effect is the > same, and content of the directory is the same. > > Unless I am seriously missing something. > > depesz > > > On Thu, Mar 12, 2015 at 11:09 PM, Charles Yeomans wrote: > No; there would be two repositories on the server. The repository in > /var/lib/git is bare; recall that a bare git repository does not have a > working copy. It would be possible to make the server repository non-bare, > but that's generally a bad idea. > > > Charles > > > > On Mar 12, 2015, at 3:35 PM, hubert depesz lubaczewski > > wrote: > > > > Why more disk space use? There would still be one clone of the repo, it > > just would be located in different place (not /etc/puppet_HASH, but > > directly /etc/puppet). > > > > I think i can see one benefit of doing it the way you did it - we have > > guarantee that there will be no things in /etc/puppet that were added > > without adding them to git repo. Which is a good thing, I guess. > > > > Thanks, > > > > depesz > > > > On Thu, Mar 12, 2015 at 8:12 PM, Charles Yeomans wrote: > > If I understand your question, the reason I don't just export to > > /etc/puppet is that the git repository contains files other than the puppet > > configuration, and I prefer to keep those files out of the puppet directory. > > > > Certainly one could clone the bare repository in /var/lib/git, and symlink > > /etc/puppet to the puppet directory in that non-bare repository. Then the > > script that executes puppet apply would first run git pull, then puppet > > apply. I didn't do it that way for no reason other than I didn't think to > > do it that way. In fact it might be less complicated to implement, in > > exchange for some more disk space. > > > > > > Charles > > > > > On Mar 12, 2015, at 10:42 AM, hubert depesz lubaczewski > > > wrote: > > > > > > I understand most of it, but why checkout as /etc/puppet_hash, and and > > > not simply as /etc/puppet, and just `git pull` when necessary? > > > > > > I.e. What is the benefit of having to do clone from scratch on every run > > > (i.e. when something has changed)? > > > > > > depesz > > > > > -- > You received this message because you are subscribed to a topic in the Google > Groups "Puppet Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/puppet-users/GA4KHIebUc4/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/29040E55-23D7-46DA-9FA0-6C7163695842%40dakim.com. > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/CAKrjmhd00rWHZjUbMidyhDwv8hSabuTJUmAN_Q6oeT%3DtSqJa9g%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/E8C4AC83-DC81-405D-AB7A-9B361F2FF801%40dakim.com. For more options, visit https://groups.google.com/d/optout.
