Puppet

Todd Zullinger wrote:

To echo myself from puppet-users, I think this might be something that has is not entirely clear in the client.sysconfig comments. The commented out port number for PUPPET_PORT is 8140, which would make you think it’s intended to specify the port to connect to the puppetmaster. If that’s the case, then we should be using —masterport in the init script and perhaps add a PUPPET_LISTEN_PORT to use with the —port option.

OTOH, if PUPPET_PORT is intended to specify the port that puppetd listens on, then we should make that clear in the comments above the PUPPET_PORT setting in the sysconfig file and likely add a PUPPETMASTER_PORT setting as well so that port —port and —masterport can be configured by the user via the sysconfig file.

(Of course, it’s also possible that it’s simply too early for me to think clearly and that I’m missing something obvious.)

Everything I wrote is for the client init script only. I think that the existing conf/redhat/client.sysconfig entry is explicit enough with its “to connect to” :

# If you wish to specify the port to connect to do so here
#PUPPET_PORT=8140

As for the server, it has different sysconfig and init script files as “puppetmaster” instead of the client’s “puppet” and the option to control the port to listen on is PUPPETMASTER_PORTS, so no overlapping or possible confusion here.

Right, but puppetd takes a —port option to specify the port it listens on as well as —masterport for the port to connect to. I understand that the comment and default of 8140 make it seem like it should refer to the master port, but the history in git makes it unclear to me which it is really intended to be used with. I’d like to get that cleared up so we don’t just change it to —masterport and then get an immediate bug report from someone that used the value to control the —port option. I understand that we’re talking about the client init/sysconfig here and that the puppetmaster service has it’s own init/sysconfig.

Todd Zullinger wrote:

Right, but puppetd takes a —port option to specify the port it listens on as well as —masterport for the port to connect to.

Well, last I tried, the —port option wasn’t valid for the client, so the sysconfig/initscript option is currently “broken” and switching to use —masterport fixes it. Or are you implying that the puppet client listens on a tcp port for connections? (if it doer or even can, then I’m highly confused)

You can run puppetd —port 1234. The puppetd executable from 0.25.1rc1 still supports this (as in, it doesn’t complain about it). I don’t have much time to fully test it right now, but I expect it to still work. The idea with this is that you can use puppetrun from the puppetmaster to to trigger a puppet run on the clients. So yeah, the client can listen on a TCP port for connections and this port is specified via the —port option. In that case, it seems like we should have a way to configure both the port puppetd listens on as well as the port it connects to the puppetmaster on in the client’s sysconfig file.

The sysconfig files were created way before the client had a —listen option, so I am pretty confident that PUPPET_PORT was meant to set the port on which the master listens, and the init script should therefore use —masterport.

On a related note, the sysconfig files were created before puppet had its own config files; nowadays, they are not needed anymore, and we should figure out ways to remove them completely (maybe start with including a comment at the top “Legacy cruft – set these up in the puppet config files instead”)

I held off on adding any ‘legacy’ comments to the sysconfig files for now. Is it even possible to do the equivalent of:

[…]

outside of the puppetmaster sysconfig file?

no, because if PUPPETMASTER_PORTS is defined and an array the init.d script will automagically start multiple master processes using mongrel, which is the whole idea behind this feature.

Perhaps a note like this would suffice:

[…]

?

maybe yes. Maybe it will also raise confusion, which one is treated with priority, as the sysconfig are passed as cli-switches. But generally I agree to reduce them to the minimum.