[Puppet Users] Re: puppet port 8139
lovewadhwa wrote: > Hi > > In some of my servers my puppetd daemon doesnot open the default port > 8139.I have specified explicitly in configuration file but to no > use.Also checked for by executing the puppetd daemon with debug and > verbose option but didnot find any information logged.I tried to open > some other service also on same port on same machine say mysql and it > opened up the port.Please help what needs to be done for the same. > > > > > Paste your config please. -- Joe McDonagh Operations Engineer www.colonfail.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 -~--~~~~--~~--~--~---
[Puppet Users] Re: what is queueing for storeconfigs?
makes sense. The access is only moderate in the e-mail! :-) --- Thanks, Allan Marcus 505-667-5666 On Oct 2, 2009, at 1:29 AM, Andrew Shafer wrote: You can't understand the slides unless you can hear the outrageous accent. On Fri, Oct 2, 2009 at 12:43 AM, Brice Figureau > wrote: On 2/10/09 0:35, Allan Marcus wrote: > I would have loved to attend, but out budgets are just too tight. > Would be great if you could post the presentation. Even better would > be a video. The video will be posted sometimes tomorrow afternoon. I'll eventually post the slides somewhere, but you won't get very far with the slide without the speech... -- Brice Figureau My Blog: http://www.masterzen.fr/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- smime.p7s Description: S/MIME cryptographic signature
[Puppet Users] Re: Puppet 0.25 - passenger + foreman (webfrontend)
On Fri, Oct 2, 2009 at 12:43 AM, philipp Hanselmann < philipp.hanselm...@gmail.com> wrote: > > > I found the answer by myself ... > Great, sorry for the late reply, we were kinda busy here at puppet camp :) > > Next steps will be to use passenger instead of mongrel > That should be really straight forward. cheers Ohad --~--~-~--~~~---~--~~ 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 way to manage a central file?
hello,
- "Aurelien Degremont" wrote:
> How do you deal with a file, like /etc/sysconfig/network which have
> content composed from
> different aspects (could be network, nfs, nis, ...). So managed by
> various modules but all
> of them should add its own stuff to the same file.
In the case of sysconfig files you'd need something clever, what if say 2
modules tried to set HOSTNAME= or any of the other variables, which one would
win? it would not be predictable. A lens or custom type would be best.
However, in many cases a simple snippet based system will do what you want, for
example my MOTD files advertise which modules are on the machine and I do this
using my concat snippets defined type [1]
define motd::register($content = "", $order = 10) {
concat_snippet{"motd_${name}":
owner => root,
group => root,
directory => "/etc/motd.d",
content => "\t\t- ${msg}\n",
order => $order,
}
}
class named::master {
motd::register{"bind master server": }
}
and the end result is something like:
Puppet Modules:
- apache
- bind master server
- iptables
1 - http://nephilim.ml.org/~rip/puppet/concatfile/
--
R.I.Pienaar
--~--~-~--~~~---~--~~
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] Puppet way to manage a central file?
Aurelien Degremont wrote: > I put /etc/sysconfig/network as an example. AFAIK, unfortunately, > Augeas only handles known files (existing lenses). If we trty to > handle /etc/our_local_config_file, it is not so easy. Indeed. Really silly design. There was a reason that I wrote "e.g." in my suggestion for Augeas; I often use my own textfile editing types instead. >> Shameless plug: I have a define 'rh_sysconfig' for setting /etc/sysconfig >> entries in a module I've written. You can get it by doing a git clone of >> http://www.nsc.liu.se/~bellman/nsc-puppet-utils.git. It doesn't use Augeas >> for manipulating the file, though, but some custom types for doing even >> lower level editing of text files. > I'm wondering if implementing such low-level define and file edition is > the best Puppet approach? The Puppet:y approach would, imho, be to have resource types on the same level as the builtin resource types 'host', 'mount', 'sshkey', and so on. My 'rh_sysconfig' definition is actually a bit too low-level; better would be a 'sysconfig' definition/type that knows to edit files in /etc/conf.d on Gentoo, /etc/sysconfig on RedHat, and so on, but I haven't gotten around to do that yet. (One problem for these kinds of settings, though, is that they have different names and values on different platforms, so the sysadmins needs to handle that in their manifests anyway.) And of course you would want a 'firewall' or 'iptables' type, types for adding /etc/sudoers entries, types for manipulating Apache configs, and so on, and so on. Whether those types are implemented as builtin types in Puppet, as custom types, or defines built on top of lower-level file editing tools like Augeas and/or my textfile editing types, doesn't matter much. But you very likely want something working on that level of abstraction. Then you can create definitions on top of those for even higher levels of abstraction. However, since the number of config file formats is nearly infinite, we also need to have the tools for sysadmins to write such types or definitions themselves. So we have Augeas, we have my textfile editing types, and we have exec to call out to sed/perl/whatever. And we have the ability to write our own custom types for full power. That's *my* take on it, at least. /Bellman --~--~-~--~~~---~--~~ 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: Using variables in virtual resources
On Friday 02 October 2009 13:41:44 Michael Gliwinski wrote:
> On Friday 02 October 2009 07:35:57 Erling wrote:
> > On 28 Sep, 19:44, Eric Gerlach wrote:
> > > You might be able to do something like:
> > >
> > > realize User[kenneth]
> > >
> > > User[kenneth] {
> > > groups => $server_type ? {
> > > typeA => "wheel",
> > > default => undef,
> > > }
> > >
> > > }
> > >
> > > to realize it the way you want. Haven't tried anything like that
> > > though. Maybe someone else can comment if it works.
> >
> > I have tried this:
> >
> >
> > node 'mynode.local' {
> >
> > $server_type = "webserver"
> >
> > adduser { "joe":
> > server_type => $server_type,
> > user_name => "joe",
> > }
> > }
> >
> > define adduser ( $user_name, $server_type ) {
> >
> > realize User[$user_name]
> > realize Group[$user_name]
> >
> > User[$user_name] {
> > groups => $server_type ? {
> > webserver => wheel,
> > default => $user_name,
> > },
> > }
> > }
> >
> >
> >
> > @group { "joe":
> > ensure => present,
> > gid => 1234,
> > allowdupe => false
> > }
> >
> > @user {"joe":
> > ensure => present,
> > managehome => true,
> > uid => 1234,
> > gid => 1234,
> > home => "/home/joe",
> > shell => "/bin/bash",
> > comment => "Joe",
> > password => '$1$ij21Zc04$MwyqTQP2fXc0BqMIjtz5b/',
> > }
> >
> > When running puppetd on mynode.local I get this message:
> >
> > notice: Ignoring cache
> > err: Could not retrieve catalog: Only subclasses can override
> > parameters at /etc/puppet/manifests/classes/adduser.pp:11
> > warning: Not using cache on failed catalog
> >
> > Best regards,
> >
> > Erling Ringen Elvsrud
>
> You should try re-organizing this so that you have your resources (here
> users) defined in a class, e.g.
>
> class all_users {
> @user {"joe":
> ensure => present,
> ...
> groups => $servertype ? {
> webserver => wheel,
> default => $user_name
> }
> }
> }
>
> node 'mynode.local' {
> $server_type = "webserver"
> incldue all_users
> }
>
> This is a simpliest example, you may still use a define and have to watch
> out for scoping rules, but that's the general idea.
>
> Regards,
Aaand of course I made a mistake :O when you're using virtual resources you
have to realize them somewhere, e.g.:
class all_users {
@user {"joe":
ensure => present,
...
groups => $servertype ? {
webserver => wheel,
default => $user_name
}
}
}
node 'mynode.local' {
$server_type = "webserver"
incldue all_users
realize(User["joe"])
}
Again, note that this is simplistic, you usually don't realize resources
directly in the nodes.
--
Michael Gliwinski
Henderson Group Information Services
9-11 Hightown Avenue, Newtownabby, BT36 4RT
Phone: 028 9034 3319
**
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee and access to the email by anyone else
is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and
may be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail
are subject to the terms and conditions expressed in the governing client
engagement leter or contract.
If you have received this email in error please notify
supp...@henderson-group.com
John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland,
BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*
--~--~-~--~~~---~--~~
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 way to manage a central file?
On Friday 02 October 2009 11:06:39 Aurelien Degremont wrote: > Thomas Bellman a écrit : > > Aurelien Degremont wrote: > >> How do you deal with a file, like /etc/sysconfig/network which have > >> content composed from different aspects (could be network, nfs, nis, > >> ...). So managed by various modules but all > of them should add its > >> own stuff to the same file. > >> > >> What is your elegant way to deal with this? > > > > Edit the individual settings using e.g. Augeas. Preferably wrap it in > > a define, so you don't have to deal with the augeas type directly every > > time you want to change something in /etc/sysconfig. > > I put /etc/sysconfig/network as an example. AFAIK, unfortunately, Augeas > only handles known files (existing lenses). If we trty to handle > /etc/our_local_config_file, it is not so easy. I usually handle that by distributing custom augeas lenses with puppet and putting them in /usr/share/augeas/lenses/. This isn't actually very hard as most of those lenses are slightly customized versions of lenses bundled with augeas (very often only with adjusted filter to include the file I need to change). That is unless you have a not-yet-supported config file type or a really hard to handle one. Suppose augeas could be a bit more flexible with regards to the file filters, or at least allowing to modify it on runtime :) -- Michael Gliwinski Henderson Group Information Services 9-11 Hightown Avenue, Newtownabby, BT36 4RT Phone: 028 9034 3319 ** The information in this email is confidential and may be legally privileged. It is intended solely for the addressee and access to the email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients, any opinions or advice contained in this e-mail are subject to the terms and conditions expressed in the governing client engagement leter or contract. If you have received this email in error please notify supp...@henderson-group.com John Henderson (Holdings) Ltd Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT. Registered in Northern Ireland Registration Number NI010588 Vat No.: 814 6399 12 * --~--~-~--~~~---~--~~ 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: How to structure configuration using Puppet and version control tools
On Thu, Oct 1, 2009 at 10:56 AM, Calimero wrote: > > On 30 sep, 17:20, Kenneth Holter wrote: >> Hello all. >> >> We're running Puppet to manage our linux-servers, but as of now we don't >> really have a good setup for dealing with different environments >> (production, qass, and so forth). The puppet manifests have been added to >> Subversion. > > We also have our puppet conf versioned by SVN. And, well, ... we still > don't have a proper system for various stages. > > I thought of creating multiple branches in SVN (each branch being > configured as a puppet environment) and then, when changes seem OK, > merge (svn merge) them from the dev branch to the testing branch and > so forth. > > But this of course requires some change in SVN usage: commit only > things that belong together (so that you can 'svn merge -c N ...') > instead of committing any changes that are dangling in your working > copy. > > Anyway, I would also like to hear how people do this in their setups. > We make use of a combination of SVN tags as well as environments. We configure puppet with the following environments: development, staging (a.k.a. QA), production, prod-clone, branch1 and branch2 The first 3 should be self-explanatory. Prod-clone is for emergency fixes outside of our normal update schedule where we can point a production machine to a branch with the prod puppet code + a fix. Branch1 and Branch2 are similar to development for major refactoring. We also have to deal with production control issues, so we created a schedule for each environment - Development, Branch1 and Branch2 we are free to update at any time, so systems in those environments are generally new builds or test/dev systems. QA we update in our Tuesday evening change window and Production and Prod-clone are updated in our Thursday evening change window. Prod-clone, by its nature, can get updated anytime after that, but only in an emergency situation to fix a problem. Development is our puppet SVN trunk. Branch1 and Branch2 *can* be SVN branches, but aren't always. More often than not they're trunk plus some local changes that once we vet are merged back into trunk. At some point before Tuesday, we copy trunk to a tag that becomes the next QA->Production configuration. We tried doing things the Right Way(TM) with SVN and having branches, merging fixes from trunk to the branches, cutting tags from the branches, etc. but it was just too much overhead for what we were doing. We have found if we keep the release tags fairly frequent (every week or two), it's fairly easy to stay on top of things and not break anything. We also comment our check-ins in a specific format so we know what host(s) the change(s) affect and what the change is. We use this to generate a summary page that is presented at our weekly rollout meetings so that the other groups (DBAs, App Developers, etc.) can see what changes are scheduled for the next change. This lets us remain agile enough to respond to things, but also gives some oversight to the process so we don't go breaking anything in production because we fat-fingered an SVN update or something similar. Matt --~--~-~--~~~---~--~~ 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 way to manage a central file?
Nicolas Szalay a écrit : > Le vendredi 02 octobre 2009 à 12:06 +0200, Aurelien Degremont a écrit : >> Thomas Bellman a écrit : >>> Aurelien Degremont wrote: >>> How do you deal with a file, like /etc/sysconfig/network which have content composed from different aspects (could be network, nfs, nis, ...). So managed by various modules but all > of them should add its own stuff to the same file. What is your elegant way to deal with this? >>> Edit the individual settings using e.g. Augeas. Preferably wrap it in >>> a define, so you don't have to deal with the augeas type directly every >>> time you want to change something in /etc/sysconfig. >> I put /etc/sysconfig/network as an example. AFAIK, unfortunately, Augeas >> only handles >> known files (existing lenses). If we trty to handle >> /etc/our_local_config_file, it is not >> so easy. > > A bunch of templates + concatened_file would do the trick I suppose. Indeed, but I was seeking if there was something else than a "trick"? -- Aurelien Degremont CEA --~--~-~--~~~---~--~~ 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 way to manage a central file?
Le vendredi 02 octobre 2009 à 12:06 +0200, Aurelien Degremont a écrit : > Thomas Bellman a écrit : > > Aurelien Degremont wrote: > > > >> How do you deal with a file, like /etc/sysconfig/network which have > >> content composed from different aspects (could be network, nfs, nis, > >> ...). So managed by various modules but all > of them should add its > >> own stuff to the same file. > >> > >> What is your elegant way to deal with this? > > > > Edit the individual settings using e.g. Augeas. Preferably wrap it in > > a define, so you don't have to deal with the augeas type directly every > > time you want to change something in /etc/sysconfig. > > I put /etc/sysconfig/network as an example. AFAIK, unfortunately, Augeas only > handles > known files (existing lenses). If we trty to handle > /etc/our_local_config_file, it is not > so easy. A bunch of templates + concatened_file would do the trick I suppose. Nico. signature.asc Description: Ceci est une partie de message numériquement signée
[Puppet Users] Re: Using variables in virtual resources
On Friday 02 October 2009 07:35:57 Erling wrote:
> On 28 Sep, 19:44, Eric Gerlach wrote:
> > You might be able to do something like:
> >
> > realize User[kenneth]
> >
> > User[kenneth] {
> > groups => $server_type ? {
> > typeA => "wheel",
> > default => undef,
> > }
> >
> > }
> >
> > to realize it the way you want. Haven't tried anything like that though.
> > Maybe someone else can comment if it works.
>
> I have tried this:
>
>
> node 'mynode.local' {
>
> $server_type = "webserver"
>
> adduser { "joe":
> server_type => $server_type,
> user_name => "joe",
> }
> }
>
> define adduser ( $user_name, $server_type ) {
>
> realize User[$user_name]
> realize Group[$user_name]
>
> User[$user_name] {
> groups => $server_type ? {
> webserver => wheel,
> default => $user_name,
> },
> }
> }
>
>
>
> @group { "joe":
> ensure => present,
> gid => 1234,
> allowdupe => false
> }
>
> @user {"joe":
> ensure => present,
> managehome => true,
> uid => 1234,
> gid => 1234,
> home => "/home/joe",
> shell => "/bin/bash",
> comment => "Joe",
> password => '$1$ij21Zc04$MwyqTQP2fXc0BqMIjtz5b/',
> }
>
> When running puppetd on mynode.local I get this message:
>
> notice: Ignoring cache
> err: Could not retrieve catalog: Only subclasses can override
> parameters at /etc/puppet/manifests/classes/adduser.pp:11
> warning: Not using cache on failed catalog
>
> Best regards,
>
> Erling Ringen Elvsrud
>
You should try re-organizing this so that you have your resources (here users)
defined in a class, e.g.
class all_users {
@user {"joe":
ensure => present,
...
groups => $servertype ? {
webserver => wheel,
default => $user_name
}
}
}
node 'mynode.local' {
$server_type = "webserver"
incldue all_users
}
This is a simpliest example, you may still use a define and have to watch out
for scoping rules, but that's the general idea.
Regards,
--
Michael Gliwinski
Henderson Group Information Services
9-11 Hightown Avenue, Newtownabby, BT36 4RT
Phone: 028 9034 3319
**
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee and access to the email by anyone else
is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and
may be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail
are subject to the terms and conditions expressed in the governing client
engagement leter or contract.
If you have received this email in error please notify
supp...@henderson-group.com
John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland,
BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*
--~--~-~--~~~---~--~~
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 way to manage a central file?
Thomas Bellman a écrit : > Aurelien Degremont wrote: > >> How do you deal with a file, like /etc/sysconfig/network which have >> content composed from different aspects (could be network, nfs, nis, >> ...). So managed by various modules but all > of them should add its >> own stuff to the same file. >> >> What is your elegant way to deal with this? > > Edit the individual settings using e.g. Augeas. Preferably wrap it in > a define, so you don't have to deal with the augeas type directly every > time you want to change something in /etc/sysconfig. I put /etc/sysconfig/network as an example. AFAIK, unfortunately, Augeas only handles known files (existing lenses). If we trty to handle /etc/our_local_config_file, it is not so easy. > Shameless plug: I have a define 'rh_sysconfig' for setting /etc/sysconfig > entries in a module I've written. You can get it by doing a git clone of > http://www.nsc.liu.se/~bellman/nsc-puppet-utils.git. It doesn't use Augeas > for manipulating the file, though, but some custom types for doing even > lower level editing of text files. I'm wondering if implementing such low-level define and file edition is the best Puppet approach? Aurelien --~--~-~--~~~---~--~~ 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 way to manage a central file?
Aurelien Degremont wrote: > How do you deal with a file, like /etc/sysconfig/network which have > content composed from different aspects (could be network, nfs, nis, > ...). So managed by various modules but all > of them should add its > own stuff to the same file. > > What is your elegant way to deal with this? Edit the individual settings using e.g. Augeas. Preferably wrap it in a define, so you don't have to deal with the augeas type directly every time you want to change something in /etc/sysconfig. Shameless plug: I have a define 'rh_sysconfig' for setting /etc/sysconfig entries in a module I've written. You can get it by doing a git clone of http://www.nsc.liu.se/~bellman/nsc-puppet-utils.git. It doesn't use Augeas for manipulating the file, though, but some custom types for doing even lower level editing of text files. /Bellman --~--~-~--~~~---~--~~ 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 0.25 - passenger + foreman (webfrontend)
I found the answer by myself ... mongrel network settings can be changend in /opt/foreman/vendor/rails/railties/lib/commands/server.rb I noticed that our company firewall is blocking Port 3000. Now it is working, I can see the webgui ... Next steps will be to use passenger instead of mongrel philipp Hanselmann wrote: > Hi > > > I was trying to installed foreman, but up to know it fails ... > > (Setup: Redhat Server 5.0 Puppet 0.25 + Passenger, foreman is > installed on the same server than Puppet ) > > I did the following steps: > > > 1.) r...@id-lnx-deployment:/opt # git clone > git://github.com/ohadlevy/foreman.git foreman >Initialized empty Git repository in /opt/foreman/.git/ >remote: Counting objects: 3578, done. >remote: Compressing objects: 100% (2690/2690), done. >remote: Total 3578 (delta 1193), reused 2516 (delta 566) >Receiving objects: 100% (3578/3578), 3.29 MiB | 1269 KiB/s, done. >Resolving deltas: 100% (1193/1193), done. > > 2.) r...@id-lnx-deployment:/opt # cd foreman > > > 3.) r...@id-lnx-deployment:/opt/foreman # git submodule init >Submodule 'vendor/plugins/active_scaffold' > (git://github.com/activescaffold/active_scaffold.git) registered for > path 'vendor/plugins/active_scaffold' >No submodule mapping found in .gitmodules for path > 'vendor/plugins/ruby-net-ldap' > > 4.) r...@id-lnx-deployment:/opt/foreman # git submodule update >Initialized empty Git repository in > /opt/foreman/vendor/plugins/active_scaffold/.git/ >remote: Counting objects: 8210, done. >remote: Compressing objects: 100% (2166/2166), done. >remote: Total 8210 (delta 6070), reused 7746 (delta 5647) >Receiving objects: 100% (8210/8210), 1016.04 KiB | 614 KiB/s, done. >Resolving deltas: 100% (6070/6070), done. >Submodule path 'vendor/plugins/active_scaffold': checked out > '4dcef6d830b3201711ae5b3d2c193a19a31924fd' >No submodule mapping found in .gitmodules for path > 'vendor/plugins/ruby-net-ldap' > > > 5.) >RAILS_ENV=production rake db:migrate > > > 6.) rake puppet:migrate:populate_hosts RAILS_ENV=production > > > 7.) r...@id-lnx-deployment:/opt/foreman # ./script/server -e production > => Booting Mongrel > => Rails 2.3.2 application starting on http://0.0.0.0:3000 > => Call with -d to detach > => Ctrl-C to shutdown server > > When I did these steps it looked for me everything was working, but > when I finally try to get access to id-lnx-deployment:3000 in my > webbrowser I can't load the page ;-( > > > For me it looks like that http://0.0.0.0:3000 is only accessible > locally but not not from outside? > > And if I try on the server "cd /tmp ; wget http://localhost:3000"; I > will download successfully a *empty* page? > > The same empty page I get on my local machine with > http://localhost:3000"; with an ssh tunnel (ssh -D 3000 > r...@id-lnx-deployment) ... > > Questions: > 1.) Where can I configure that mongrel is accepting connections from > outside? > 2.) Why does foreman provide empty pages? > > Thanks for the help! > Philipp > > --~--~-~--~~~---~--~~ 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] Puppet way to manage a central file?
Hello I facing I think a typical problem when using Puppet and I'm wondering what is the Puppet way to deal with this. I'm explaining. How do you deal with a file, like /etc/sysconfig/network which have content composed from different aspects (could be network, nfs, nis, ...). So managed by various modules but all of them should add its own stuff to the same file. What is your elegant way to deal with this? Thanks -- Aurelien Degremont CEA --~--~-~--~~~---~--~~ 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: what is queueing for storeconfigs?
You can't understand the slides unless you can hear the outrageous accent. On Fri, Oct 2, 2009 at 12:43 AM, Brice Figureau < brice-pup...@daysofwonder.com> wrote: > > On 2/10/09 0:35, Allan Marcus wrote: > > I would have loved to attend, but out budgets are just too tight. > > Would be great if you could post the presentation. Even better would > > be a video. > > The video will be posted sometimes tomorrow afternoon. > I'll eventually post the slides somewhere, but you won't get very far > with the slide without the speech... > -- > Brice Figureau > My Blog: http://www.masterzen.fr/ > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
