puppet packets

[Mark Foster]

Does anyone happen to have or can point me to a write-up describing the
internal workings of the puppet client-server transaction? Specifically
what is sent by the client to the server and back (headers & payload).
Either a generic or specific example would be fine.
I'm trying to understand what the client provides to the server as
"identification"... presume it's the facter values as seen on the client
and maybe more.
Thanks.

--
Mark Foster - Sr. Systems Engineer
BitPusher - premier managed services provider
http://www.bitpusher.com/

[Luke Kanies]

On Apr 23, 2008, at 12:38 PM, Mark Foster wrote:

>
> Does anyone happen to have or can point me to a write-up describing
> the
> internal workings of the puppet client-server transaction?
> Specifically
> what is sent by the client to the server and back (headers & payload).
> Either a generic or specific example would be fine.
> I'm trying to understand what the client provides to the server as
> "identification"... presume it's the facter values as seen on the
> client
> and maybe more.

Authentication is all handled at the http/ssl layer by lower-level
libraries. You can look at (in the current code base) lib/puppet/
network/http_pool.rb#cert_setup to see how the client sets up its SSL,
and in lib/puppet/network/http_server/webrick.rb#setup_webrick for how
the server is set up (Mongrel can't do ssl, so there's no
configuration for that).

In other words, Puppet doesn't handle any of the connections -- it
configures SSL, and lets the http libraries do the work.

Is that what you were looking for?

--
To get back my youth I would do anything in the world, except take
exercise, get up early, or be respectable. -- Oscar Wilde
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

[Mark Foster]

Luke Kanies wrote:
>
> Authentication is all handled at the http/ssl layer by lower-level
> libraries. You can look at (in the current code base) lib/puppet/
> network/http_pool.rb#cert_setup to see how the client sets up its SSL,
> and in lib/puppet/network/http_server/webrick.rb#setup_webrick for how
> the server is set up (Mongrel can't do ssl, so there's no
> configuration for that).
>
> In other words, Puppet doesn't handle any of the connections -- it
> configures SSL, and lets the http libraries do the work.
>
> Is that what you were looking for?
>
>

I'm more interested in they layer 7 payload data after the SSL
handshake. It looks like it is XMLRPC.
Is there an explanation somewhere of the transactions.
I do see some hints in the debug on the client...
debug: Calling puppetca.getcert
warning: peer certificate won't be verified in this SSL session.
notice: Got signed certificate
debug: Retrieved facts in 0.19 seconds <---(1)
debug: Retrieving catalog <---(2)
debug: Calling puppetmaster.getconfig <---(3)

Does the client call facter itself then send the output (translated into
an XMLRPC request) to puppetmaster?
What else is taking place @ 1, 2 and 3?

Maybe the answers aren't readily and I will be told to see the code, if
so fine.
Thanks if at all.

[James Turnbull]

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

Mark Foster wrote:

> I'm more interested in they layer 7 payload data after the SSL
> handshake. It looks like it is XMLRPC.

It is.

> Is there an explanation somewhere of the transactions.
> I do see some hints in the debug on the client...
> debug: Calling puppetca.getcert
> warning: peer certificate won't be verified in this SSL session.
> notice: Got signed certificate
> debug: Retrieved facts in 0.19 seconds <---(1)
> debug: Retrieving catalog <---(2)
> debug: Calling puppetmaster.getconfig <---(3)
>
> Does the client call facter itself then send the output (translated into
> an XMLRPC request) to puppetmaster?

The source code is the best place for this knowledge - the
wiki/documentation doesn't go to this detail. The code's pretty simple
to parse.

Regards

James Turnbull

- --
James Turnbull (ja...@lovedthanlost.net)
- --
Author of:
- - Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
- - Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
- - Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFID8YP9hTGvAxC30ARAoznAKCyV8/qeDNJYVEO+sa3qTbJGI/2SQCeLruF
+Y3WXBhkx+43fAFS4BxSzPk=
=qm1U
-----END PGP SIGNATURE-----

[Luke Kanies]

On Apr 23, 2008, at 4:37 PM, Mark Foster wrote:
> I'm more interested in they layer 7 payload data after the SSL
> handshake. It looks like it is XMLRPC.
> Is there an explanation somewhere of the transactions.
> I do see some hints in the debug on the client...
> debug: Calling puppetca.getcert
> warning: peer certificate won't be verified in this SSL session.
> notice: Got signed certificate
> debug: Retrieved facts in 0.19 seconds <---(1)
> debug: Retrieving catalog <---(2)
> debug: Calling puppetmaster.getconfig <---(3)
>
> Does the client call facter itself then send the output (translated
> into
> an XMLRPC request) to puppetmaster?
> What else is taking place @ 1, 2 and 3?
>
> Maybe the answers aren't readily and I will be told to see the code,
> if
> so fine.

Well, the answers are pretty readily available, but they're most
readily available by looking at the code at network/client/master.rb.

Yes, the client calls Facter, then sends them to the server in an
xmlrpc call, and gets the catalog as the result of the call.

--
Aizu's Second Law:
What changes the world is communication, not information.

[Mark Foster]

Luke Kanies wrote:
> Well, the answers are pretty readily available, but they're most
> readily available by looking at the code at network/client/master.rb.
>
> Yes, the client calls Facter, then sends them to the server in an
> xmlrpc call, and gets the catalog as the result of the call.
>
>

I will review that part of the code.

So next question. Let's say client has custom facter variables such as
puppetclass = foo
puppetclass = bar
Is this (in and of itself) sufficient to have the client associated to
the foo & bar classes by puppetmaster, or does pm only trust it's own
node definitions for class association (whether in it's nodes.pp or in
LDAP node definition for instance).

[David Schmitt]

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

The puppetmaster uses the facts only as input into the manifest compilation.
how the various components (puppet, .pp, ldap, external node classification)
use this information to generate the actual list of classes and resources is
up to them.

Regards, DavidS

- --
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIEDiV/Pp1N6Uzh0URAgcEAJ9ChomXWJrp7gzUXgkWgh9kPN7P0gCfZv7v
iguCmCZb99eJ62KZw5HsDfY=
=uqvT
-----END PGP SIGNATURE-----

[Luke Kanies]

On Apr 23, 2008, at 4:57 PM, Mark Foster wrote:

> So next question. Let's say client has custom facter variables such as
> puppetclass = foo
> puppetclass = bar
> Is this (in and of itself) sufficient to have the client associated to
> the foo & bar classes by puppetmaster, or does pm only trust it's own
> node definitions for class association (whether in it's nodes.pp or in
> LDAP node definition for instance).

The server can't even tell if a fact is custom or built-in, so they're
treated equivalently.

The parser just gets a big hash of facts; it doesn't know or care
about anything else.

--
A complex system that works is invariably found to have evolved from a
simple system that works. -- John Gaule

[Peter Meier]

Hi

>> So next question. Let's say client has custom facter variables such as
>> puppetclass = foo
>> puppetclass = bar
>> Is this (in and of itself) sufficient to have the client associated to
>> the foo & bar classes by puppetmaster, or does pm only trust it's own
>> node definitions for class association (whether in it's nodes.pp or in
>> LDAP node definition for instance).
>
> The server can't even tell if a fact is custom or built-in, so they're
> treated equivalently.
>
> The parser just gets a big hash of facts; it doesn't know or care
> about anything else.

Mark Foster: looking at the current thread and that it's quite some
stuff that is not yet documented somewhere: would you mind to document
this somewhere on the wiki on appropriate page? Also other things you
find out while looking at the code. Thanks!
If nobody else is against that?

greets Pete