...
- create a namespace (directory) for each service
- apply the basic structure to each namespace
- continue to use the basic (top-level) module structure to manage module-wide configurations and resource orderings
...
Separate Client and Server Components
In the case that you have a server and client that are two separately isolated services, such as the SSH server and client, then two separate modules should be created. This provides for a clean usage pattern over time.
Combined Client and Server Components
There are going to be times where the server and client components cannot be split. In these cases, isolate the functionality within the module to the bests of your ability and repeat the pattern below each subdirectory segment.
As an example, you may use something like the following:
- module/manifests/
- init.pp
- params.pp, config.pp, etc (for module-wide settings)
- server.pp
- server/
- params.pp
- install.pp
- config.pp
- service.pp
- firewall.pp
- logging.pp
- audit.pp
- selinux.pp
- client.pp
- client/
- params.pp
- install.pp
- config.pp
- service.pp
- firewall.pp
- logging.pp
- audit.pp
- selinux.pp
NOTE: Many legacy modules will use an earlier client/server pattern in init.pp where the Boolean parameters $is_client and $is_server. To maintain compatibility, keep the parameters in init.pp and .
Modules that manage their own internal "services"
...