Puppet on a purely push basis no possible?

[Kristopher]

I would like to confirm that the following is not possible:

[Kristopher]

I would like to confirm that the following is not possible:

I have servers I would like to manage via puppet in my DMZ, I have my
puppet server in the trusted zone of my network. Due to this
arrangement (which cannot be changed due to other services running on
the puppet master) puppet clients cannot initiate a connection with
the puppet master. So I would like to use puppet on a purely push
basis using puppet kick.

So I handled the cert signing out of band for a client and set up the
namespaceauth.conf. The problem is that when I start the client with --
no-client and --listen it still tries to connect to the puppet server,
which fails because of the firewall rules. In addition when I asked on
#puppet I was informed that puppet kick just tells the client to phone
home by creating a new connection to request its configs.

From all this I came to conclusion that puppet cannot be used on a
purely push basis, is this true? If it is true is it likely to change
at any point?

Thanks.

[Adam Gibbins]

That's correct, if you wish to run in "push" its recommended you run a
masterless puppet setup and push your manifests to the host which then
executes them.
I could be wrong, but I can't see it changing due to the way puppet is
engineered. Nodes subscribe to puppet updates rather than updates
being forced upon them.

[Nan Liu]

If you do not want the puppet agent to initiate any network connection
to the puppet master, compile the catalog on the master, ship the
catalog and dependent files to the agent, then apply the catalog on
the agent.

Thanks,

Nan

[James Louis]

My experience is having "listen = true" in the puppet conf and starting the client with --no-client does prevent the puppet pull. This works for me so that I can issue a puppet kick on the server to only serve changes when I want to.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

--

To be is to do = Immanuel Kant
To do is to be = Descartes.
Do be do be do = Frank Sinatra

[Daniel Pittman]

Other people answered other parts of this, but to be totally clear:

'puppet kick' is *NOT* a push mechanism for puppet. It is a mechanism
to trigger the regular, pull-based, puppet run on a specific machine.

In the bigger picture I would strongly suggest you just open the
single port used for puppet management from the DMZ to the secure
network, and allow that (and only that) exception. Alternately,
establish a second puppet master in the DMZ for use there, and feed it
catalogs from the same VCS that the internal one uses.

(Personally, I would suggest that opening the port is less security
auditing overhead than an entire puppet master out in the DMZ, but
YM(and auditors)MV.)

Daniel

--
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <dan...@puppetlabs.com>
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons

[Trevor Vaughan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is completely possible.

Look at the threads on pushing out pre-compiled configurations.

You do lose some features, such as pulling from the puppet filestore unless that's OK with you.

Trevor

On 02/15/2011 02:16 PM, Kristopher wrote:
> I would like to confirm that the following is not possible:
>

- --
Trevor Vaughan
Vice President, Onyx Point, Inc.
email: tvau...@onyxpoint.com
phone: 410-541-ONYX (6699)
pgp: 0x6C701E94

- -- This account not approved for unencrypted sensitive information --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJNWyi8AAoJECNCGV1OLcypJC4H/A7JIP57Y1YzU9fg+ni+ZTRy
KdeA/zDeaufi98AiogDciY5nLnvsijXt3aR40gB8YXH6zSN8N88xrb93FtsFjFvQ
M99/Kjf6mC5Gx//t8d3hpjyul1lx19CzLDlaXgW6f3UNUGLvY4vJY6PCtrkQyVGu
4VE5gU2XIcWWj1BWTHNt9VHJDF7ZNJCy814CfAooIOmNBCgrPkWOfsU8XiLtPaw4
hDzR2XXpMg84c9rsatZwhiKsNyCHSScX98LP0hkMnRKH9kLBjZtdDa+0kyT/noPF
ikjQZJ6dawgNjovgaW4JX+P9ofwIgBeUBhwwyHF6T5tdF1HJEPh/ZGXNqSFyz0M=
=6bhZ
-----END PGP SIGNATURE-----

[James Louis]

in spite of this not actually being a "push" mechanism if it walks like a duck. it would be nice if the documentation and previous discussions on this were more clear or even better if it's not a "push" then the it should be "redefined" within puppet world. IMHO

[Patrick]

I think you're saying that it's close enough that it shouldn't matter.  In the context of this thread, there's a huge difference though.  If the puppet client is in a DMZ, (and can't connect to the puppetmaster) it needs the catalog to be pushed to the client.  Not just the server telling the client to pull the config, because the client can't connect to the server since the client is locked in the DMZ.

[James Louis]

I see what you are saying. We are going with a plan to authorize an opening in the firewall for just the instance of the kick. As any changes to our production environment require a change request one would have to be created to allow the ports to be opened just for the kick.

[Russell Jackson]

On 02/15/2011 05:37 PM, James Louis wrote:
> in spite of this not actually being a "push" mechanism if it walks like
> a duck. it would be nice if the documentation and previous discussions
> on this were more clear or even better if it's not a "push" then the it
> should be "redefined" within puppet world. IMHO
>

Actually, almost anything that is referred to as "push" is usually
implemented as some sort of pull trigged via a notification mechanism.

--
Russell A Jackson <r...@csub.edu>
Network Analyst
California State University, Bakersfield

[Daniel Pittman]

On Thu, Feb 17, 2011 at 12:16, Russell Jackson <r...@csub.edu> wrote:
> On 02/15/2011 05:37 PM, James Louis wrote:
>
>> in spite of this not actually being a "push" mechanism if it walks like
>> a duck. it would be nice if the documentation and previous discussions
>> on this were more clear or even better if it's not a "push" then the it
>> should be "redefined" within puppet world. IMHO
>
> Actually, almost anything that is referred to as "push" is usually
> implemented as some sort of pull trigged via a notification mechanism.

That seems an odd claim in general, but whatever. In the specific
case of puppet we have a prototype for a "static compiler" that we are
working on internally. The goal is to allow a set of files, catalog
included, to be pushed out from the central server to the client, with
no loss of fidelity or control.

So, we are sympathetic to the requirement for a genuine push solution
(which is actually push), and are working on solutions to the problem.
They don't even have a roadmap date yet, though, I fear. :)

Daniel

[Russell Jackson]

On 02/18/2011 11:32 AM, Daniel Pittman wrote:
> On Thu, Feb 17, 2011 at 12:16, Russell Jackson <r...@csub.edu> wrote:
>> On 02/15/2011 05:37 PM, James Louis wrote:
>>
>>> in spite of this not actually being a "push" mechanism if it walks like
>>> a duck. it would be nice if the documentation and previous discussions
>>> on this were more clear or even better if it's not a "push" then the it
>>> should be "redefined" within puppet world. IMHO
>>
>> Actually, almost anything that is referred to as "push" is usually
>> implemented as some sort of pull trigged via a notification mechanism.
>
> That seems an odd claim in general, but whatever. In the specific
> case of puppet we have a prototype for a "static compiler" that we are
> working on internally. The goal is to allow a set of files, catalog
> included, to be pushed out from the central server to the client, with
> no loss of fidelity or control.
>
> So, we are sympathetic to the requirement for a genuine push solution
> (which is actually push), and are working on solutions to the problem.
> They don't even have a roadmap date yet, though, I fear. :)
>

Well, let look at "push" email in IMAP for example. The client connects
to the server and issues the IDLE command and waits for the server to
send a notification via an EXISTS response that a mailbox has new mail.
The client then "pulls" the email from the server the usual way. The
server doesn't ever actually "push" email to the client, but it's still
referred to as "push" email.