puppetmasterd and puppetd on the same box causing problems

[Joe McDonagh]

The puppetmaster package if installed from apt drags down puppet. This is not only unnecessary but it borks the permissions of /var/lib/puppet... to the package maintainer:

puppetd runs as root because it does the actual changing of config files
puppetmasterd runs as user puppet because there is no need for this daemon to have root privileges, it just needs to read some data to pass to the clients (puppets).

I guess puppet used to behave differently prior to this release, but this package looks to be a little messed up here...

[Joe McDonagh (joseph-e-mcdonagh)]

I revisited this today and I didn't accurately describe the problem in the title. Conceptually it seems correct BUT the code in puppetmasterd does import code from puppet. That being said, the real problem is running puppetmasterd and puppetd on the same box, as in the box is a client to itself. The package(s) is/are configured to do some SSL magic and store files in the same working directory. I think the solution to fix this/these package(s) is to have a couple of things happen:

1. Most importantly, fix the init scripts.
2. Do not make puppetd and puppetmasterd have the same working directories.
3. Might want to do some of those cute ncurses dialogs too during .deb postinstall to determine if this is a puppet client or puppetmaster, if client what is the server name and some other options etc.

[kc7zzv (kc7zzv)]

I'm not having any trouble in Karmic. This might be fixed.

If it's not fixed:
What about making the "puppet" (the package) not start puppet (the service) by default. Then create a package that depends on puppet called puppet-client that does everything the client option should do? I install puppet using preseed so adding a dialog would probably not work well.

[Joe McDonagh (joseph-e-mcdonagh)]

I stopped seeing that problem roughly a year ago, shortly after this. The package seemed to be pretty rough around the edges at the time.

[ZhengPeng Hou (zhengpeng-hou)]

since the original reporter can't reproduce this bug, and other users can't see it as well, we shall take it as invalid