Skip to content

Conversation

@jpartlow
Copy link
Contributor

Pull Request (PR) description

This task provides very basic configuration needed for the initial agent
run.

  • It allows generating a puppet.conf from a hash of parameters so that the
    server can set.
  • It allows generating a csr_attributes.yaml for autosigning and
    certificate extensions.
  • And it allows management of the puppet service.

This Pull Request (PR) fixes the following issues

#26

@jpartlow jpartlow force-pushed the configure_openvox branch 23 times, most recently from e038070 to ab01009 Compare July 12, 2025 03:46
@jpartlow
Copy link
Contributor Author

@lbetz when you have a moment, take a look and see if this covers your case for #26.

@jpartlow jpartlow force-pushed the configure_openvox branch from e054465 to 20eb2cb Compare July 15, 2025 21:20
jpartlow added 2 commits July 15, 2025 16:13
This will be shared with the configure.rb task.
This task provides very basic configuration needed for the initial agent
run.

* It allows generating a puppet.conf from a hash of parameters so that the
  server can set.
* It allows generating a csr_attributes.yaml for autosigning and
  certificate extensions.
* And it allows management of the puppet service.
@jpartlow jpartlow force-pushed the configure_openvox branch from 20eb2cb to 77a04a4 Compare July 15, 2025 23:14
@lbetz
Copy link
Member

lbetz commented Jul 16, 2025

@jpartlow thx. Hope, I'll will find some time today or on Friday.

@lbetz
Copy link
Member

lbetz commented Jul 16, 2025

@jpartlow What a suprise, works for me! Thought along similar lines myself. Even if I would find a task for installing and configuring more efficient. But handshakes could be solved via ssh client config.

@lbetz
Copy link
Member

lbetz commented Jul 16, 2025

Would it be a good idea if we could design the json in such a way that we could operate several targets with different parameters? In one task call?

@jpartlow jpartlow force-pushed the configure_openvox branch 3 times, most recently from 01086a1 to 13597fe Compare July 16, 2025 22:37
jpartlow added 5 commits July 16, 2025 15:51
File.chown ignores nils, so if the puppet user/group do not exist,
nothing is done, and the file remains root:root which is correct for the
agent.

This chown is only important on the node running openvox-server , as
puppetserver may otherwise choke on first startup because the file can't
be read during its ca bootstrap. (I think because puppetserver runs as
the puppet user and is calling puppet ssl at some point.)

Note that it is the openvox-server package that creates the puppet
user/group at install.
In particular, openvox-server lays down some settings in puppet.conf at
package installation time, so it would be best if this task didn't throw
out an existing puppet.conf. Using puppet-config set is safe (it's what
the openvox-server package uses); it does not trigger any of puppet's
auto certificate generation code the way an agent run does.
..with configure task and new type docs.
@jpartlow jpartlow force-pushed the configure_openvox branch from 13597fe to a0232ae Compare July 17, 2025 19:15
@jpartlow
Copy link
Contributor Author

Hi @lbetz,
I've made a couple changes for issues I encountered during testing.

  1. The csr_attributes.yaml will be owned puppet:puppet if the puppet user is present. This avoids a potential openvox-server startup ca bootstrap crash due to the file being unreadable.
  2. The puppet.conf config will now be set using puppet-config which will merge into an existing puppet.conf. This is because the openvox-server package does lay down initial puppet.conf config, and I didn't want to blow it away in that case.

Let me know if that's working for you.

For your questions:

Would it be a good idea if we could design the json in such a way that we could operate several targets with different parameters? In one task call?

If I'm understanding what you want here, this is operating outside of what a task can or should know about. This would be best coordinated in a plan, possibly by:

  • Sequentially calling the task with different parameters for different target sets
  • Or using the parallelize() function to do the same but in parallel
  • Or on a single target set using the run_task_with() function to customize the target parameters based on facts or target vars, for example.

Those are the solutions that come to mind.

Even if I would find a task for installing and configuring more efficient. But handshakes could be solved via ssh client config.

I'm not sure what you're referring to re the handshakes?

As for a single install_and_configure_openvox task, we could certainly write a wrapper task that did both things, but I think I'm more inclined to write a plan that coordinates running the two tasks. For one thing, that would make it reasonable to manage the ca.pem cert as well. But I'd like to reserve that for a separate ticket.

@lbetz
Copy link
Member

lbetz commented Jul 21, 2025

@jpartlow You're complete right to combine the tasks in a plan. With handshake I meant the ssh-handshake of several ssh different connections using by different tasks. So I am fine with all of that.

@jpartlow jpartlow merged commit f6c4cde into main Jul 25, 2025
56 checks passed
@jpartlow jpartlow deleted the configure_openvox branch July 25, 2025 19:07
@jpartlow
Copy link
Contributor Author

Sorry for the delay. I should be able to get this released early next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants