Hi, all! I'm trying out Foreman for the first time, and I was hoping you
could help.
I have a relatively small Puppet installation I'm happy with, with Puppet
3.x (not-PE) everywhere, directory environments, separate masters running
in each of 2 locations (under apache/passenger on Debian Jessie), and r10k
for deploying modules from Forge and from internal work. Everything
installed on the managed computers (including the Puppet servers) except
for Puppet itself is specified in our manifests. The two things I'm missing
are an ENC (currently everything is spelled out in a per-environment
nodes.pp) and a status dashboard. Obvious solution: Foreman!
I'm trying to install Foreman on our existing masters. I've tried the
interactive install 2 ways, both with enable-puppet and not. Either way, my
nodes can no longer talk to the master. I see that "Passenger RackApp:
/usr/share/foreman" is running, but my nodes are giving me a bunch of
'Connection refused - connect(2) for "puppet" port 8140' errors. What's
going on here? Do I have to go into the Foreman web interface just to make
Puppet master work again, and if so, how? Or is something else wrong, due
to the apparently-unsupported nature of my attempt to install Foreman where
I have an existing and working master?
As a secondary question, I would really like it if there were a way to
specify a working Foreman setup not through an interactive installer, but
through a Puppet manifest, so I can deploy it automatically to one or more
masters. Is this possible? I know that the foreman installer uses Puppet
under the hood, so I imagine it is. And I'd be surprised if not, because it
would be ironic if the only thing I can't install via a Puppet manifest is
my Puppet management tool…
Thanks so much for your help!
Josh
Hi Josh,
That's a super exciting problem as the existing installer pretty much
destroys any existing Puppet setup.
You might want to take a look at our Foreman Puppet module. It's part of
the SIMP stack and very SIMP-centric but it's non-destructive on an
existing Puppet master and might provide the guidance that you need.
I'm linking you to the Gerrit repo because, while it has been tested, we're
still finalizing the code review.
https://review.gerrithub.io/#/c/256972/
You can download it from Gerrit with this link:
https://review.gerrithub.io/changes/256972/revisions/5153ccbf6debc5dad91075decb267579a5a25b20/archive?format=tgz
It should be pushed all the way through early next week.
Thanks,
Trevor
···
On Wed, Dec 30, 2015 at 5:45 PM, Josh Rosenberg wrote:
Hi, all! I’m trying out Foreman for the first time, and I was hoping you
could help.
I have a relatively small Puppet installation I’m happy with, with Puppet
3.x (not-PE) everywhere, directory environments, separate masters running
in each of 2 locations (under apache/passenger on Debian Jessie), and r10k
for deploying modules from Forge and from internal work. Everything
installed on the managed computers (including the Puppet servers) except
for Puppet itself is specified in our manifests. The two things I’m missing
are an ENC (currently everything is spelled out in a per-environment
nodes.pp) and a status dashboard. Obvious solution: Foreman!
I’m trying to install Foreman on our existing masters. I’ve tried the
interactive install 2 ways, both with enable-puppet and not. Either way, my
nodes can no longer talk to the master. I see that “Passenger RackApp:
/usr/share/foreman” is running, but my nodes are giving me a bunch of
’Connection refused - connect(2) for “puppet” port 8140’ errors. What’s
going on here? Do I have to go into the Foreman web interface just to make
Puppet master work again, and if so, how? Or is something else wrong, due
to the apparently-unsupported nature of my attempt to install Foreman where
I have an existing and working master?
As a secondary question, I would really like it if there were a way to
specify a working Foreman setup not through an interactive installer, but
through a Puppet manifest, so I can deploy it automatically to one or more
masters. Is this possible? I know that the foreman installer uses Puppet
under the hood, so I imagine it is. And I’d be surprised if not, because it
would be ironic if the only thing I can’t install via a Puppet manifest is
my Puppet management tool…
Thanks so much for your help!
Josh
–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.
–
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
– This account not approved for unencrypted proprietary information –
> Hi, all! I'm trying out Foreman for the first time, and I was hoping you
> could help.
>
> I have a relatively small Puppet installation I'm happy with, with Puppet
> 3.x (not-PE) everywhere, directory environments, separate masters running
> in each of 2 locations (under apache/passenger on Debian Jessie), and r10k
> for deploying modules from Forge and from internal work. Everything
> installed on the managed computers (including the Puppet servers) except
> for Puppet itself is specified in our manifests. The two things I'm missing
> are an ENC (currently everything is spelled out in a per-environment
> nodes.pp) and a status dashboard. Obvious solution: Foreman!
>
> I'm trying to install Foreman on our existing masters. I've tried the
> interactive install 2 ways, both with enable-puppet and not. Either way, my
> nodes can no longer talk to the master. I see that "Passenger RackApp:
> /usr/share/foreman" is running, but my nodes are giving me a bunch of
> 'Connection refused - connect(2) for "puppet" port 8140' errors. What's
> going on here? Do I have to go into the Foreman web interface just to make
> Puppet master work again, and if so, how? Or is something else wrong, due
> to the apparently-unsupported nature of my attempt to install Foreman where
> I have an existing and working master?
>
thats odd, can you paste your installer answer file / logs? normally it
should start the puppet master under passenger or use puppet-server (jvm
version).
>
> As a secondary question, I would really like it if there were a way to
> specify a working Foreman setup not through an interactive installer, but
> through a Puppet manifest, so I can deploy it automatically to one or more
> masters. Is this possible? I know that the foreman installer uses Puppet
> under the hood, so I imagine it is. And I'd be surprised if not, because it
> would be ironic if the only thing I can't install via a Puppet manifest is
> my Puppet management tool…
>
Our installer is based on puppet 
just download the puppet modules from
the forge [1] or from out git repos [2]
Ohad
[1] https://forge.puppetlabs.com/theforeman
[2] https://github.com/theforeman?query=puppet-
···
On Thu, Dec 31, 2015 at 12:45 AM, Josh Rosenberg wrote:
Thanks so much for your help!
Josh
–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.
destroys any existing Puppet setup.
… by default, that is. You have quite a lot of options to configure how
the installer runs, including disabling configuring puppet at all.
My personal preference for brownfield installations is to run the installer
with "-nv" for noop + verbose. Then you can see the list of what the
installer will change, and then iterate through chaning installer options
until you're happy with the proposed changes. Then, as Ohad says, you can
import the installer modules and set up the same options in Foreman itself
to maintain the puppetmaster as you want it configured.
···
On 31 December 2015 at 23:25, Trevor Vaughan wrote:
>
> Hi Josh,
>
> That's a super exciting problem as the existing installer pretty much
Greg, I tried that option. I ended up with puppet not running at all. (It
seemed to be that the Passenger/Rack configuration for Foreman overwrote
the existing one for Puppet, leaving no server setup for Puppet itself? I'm
not quite sure.) Though I guess I can try again with -nv and see what's
going on…
Thanks,
Josh
···
On Sunday, January 3, 2016 at 3:14:20 PM UTC-5, Greg Sutcliffe wrote:
>
> On 31 December 2015 at 23:25, Trevor Vaughan > wrote:
> >
> > Hi Josh,
> >
> > That's a super exciting problem as the existing installer pretty much
> destroys any existing Puppet setup.
>
> ... by default, that is. You have quite a lot of options to configure how
> the installer runs, including disabling configuring puppet at all.
>
The Java-based puppetmaster makes things quite a bit easier.
The biggest issue in the past was the insistence on taking over the
passenger setup as well as the apache configuration.
We also had issues with certificate selection since we needed our external
interfaces (apache) to use domain certificates not Puppet-signed
certificates.
Thanks,
Trevor
···
On Sun, Jan 3, 2016 at 3:14 PM, Greg Sutcliffe wrote:
On 31 December 2015 at 23:25, Trevor Vaughan tvaughan@onyxpoint.com > wrote:
Hi Josh,
That’s a super exciting problem as the existing installer pretty much
destroys any existing Puppet setup.
… by default, that is. You have quite a lot of options to configure how
the installer runs, including disabling configuring puppet at all.
My personal preference for brownfield installations is to run the
installer with “-nv” for noop + verbose. Then you can see the list of what
the installer will change, and then iterate through chaning installer
options until you’re happy with the proposed changes. Then, as Ohad says,
you can import the installer modules and set up the same options in Foreman
itself to maintain the puppetmaster as you want it configured.
–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.
–
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
– This account not approved for unencrypted proprietary information –
Thanks, Trevor. Unfortunately the java-based puppetmaster is not an option
in Debian Jessie. And my certificates are puppet-signed, so I wonder if
that's part of my problem.
And thanks everyone else, too. No time to debug today, but I'm sure you'll
hear from me again soon, as I try some of these suggestions. Any other
ideas, especially someone with direct experience with a setup like mine,
I'm still all ears…
Josh
···
On Monday, January 4, 2016 at 10:37:30 AM UTC-5, Trevor Vaughan wrote:
>
> The Java-based puppetmaster makes things quite a bit easier.
>
> The biggest issue in the past was the insistence on taking over the
> passenger setup as well as the apache configuration.
>
> We also had issues with certificate selection since we needed our external
> interfaces (apache) to use domain certificates not Puppet-signed
> certificates.
>
> Thanks,
>
> Trevor
>
> On Sun, Jan 3, 2016 at 3:14 PM, Greg Sutcliffe > wrote:
>
>> On 31 December 2015 at 23:25, Trevor Vaughan > > wrote:
>> >
>> > Hi Josh,
>> >
>> > That's a super exciting problem as the existing installer pretty much
>> destroys any existing Puppet setup.
>>
>> ... by default, that is. You have quite a lot of options to configure how
>> the installer runs, including disabling configuring puppet at all.
>>
>> My personal preference for brownfield installations is to run the
>> installer with "-nv" for noop + verbose. Then you can see the list of what
>> the installer will change, and then iterate through chaning installer
>> options until you're happy with the proposed changes. Then, as Ohad says,
>> you can import the installer modules and set up the same options in Foreman
>> itself to maintain the puppetmaster as you want it configured.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Foreman users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-user...@googlegroups.com .
>> To post to this group, send email to forema...@googlegroups.com
>> .
>> Visit this group at https://groups.google.com/group/foreman-users.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
>
> -- This account not approved for unencrypted proprietary information --
>
seemed to be that the Passenger/Rack configuration for Foreman overwrote
the existing one for Puppet, leaving no server setup for Puppet itself? I'm
not quite sure.) Though I guess I can try again with -nv and see what's
going on…
That's a combination of disabling the puppet module and the fact that the
apache config is set to purge unmanaged entries from the vhosts directory.
You're probably better leaving puppet enabled and using -nv to check the
changes, as you say. Most things are configurable these days, so with
enough options set, you can probably get close to what you already have
running (cosmetic changes such as re-ordering lines in config files
notwithstanding). Do let us know if you get stuck with anything though
Greg
···
On 4 January 2016 at 16:00, Josh Rosenberg wrote:
>
> Greg, I tried that option. I ended up with puppet not running at all. (It
Ah, OK, that information about the apache config was helpful! So I
installed Foreman 1.10 from the installer, using the defaults except
turning Puppet off. And then, after using other configs to get my old
Puppet vhost back in the apache directory, I have both Foreman and Puppet
master running on the same host. The problem is that it seems they're not
talking to each other? The Foreman dashboard is not showing any hosts (even
the current host itself), even though many machines are calling home for
catalogs and leaving reports behind at /var/lib/puppet/reports. How can I
make Foreman know about the hosts?
Thanks,
Josh
···
On Tuesday, January 5, 2016 at 4:19:21 AM UTC-5, Greg Sutcliffe wrote:
>
> On 4 January 2016 at 16:00, Josh Rosenberg > wrote:
> >
> > Greg, I tried that option. I ended up with puppet not running at all.
> (It seemed to be that the Passenger/Rack configuration for Foreman
> overwrote the existing one for Puppet, leaving no server setup for Puppet
> itself? I'm not quite sure.) Though I guess I can try again with -nv and
> see what's going on...
>
> That's a combination of disabling the puppet module and the fact that the
> apache config is set to purge unmanaged entries from the vhosts directory.
> You're probably better leaving puppet enabled and using -nv to check the
> changes, as you say. Most things are configurable these days, so with
> enough options set, you can probably get close to what you already have
> running (cosmetic changes such as re-ordering lines in config files
> notwithstanding). Do let us know if you get stuck with anything though :)
>
> Greg
>
You'll need the puppet report processor installed. See
Foreman :: Manual for manual
setup steps if you need it.
