On 17/09/2014 11:34, J. Roeleveld wrote: > > On Wednesday, September 17, 2014 12:19:37 PM Eray Aslan wrote: >> On Tue, Sep 16, 2014 at 10:43:18PM +0200, Alan McKinnon wrote: >>> Puppet seems to me a good product for a large site with 1000 hosts. >>> Not so much for ~20 or so. >> >> I find that for a few machines, puppet is overkill. For a lot of >> machines, puppet can become unmanageable - with puppet master and >> security being the culprit. >> >> We have used puppet a lot but recently settled on salt (strictly >> speaking not my decision so cannot really compare it with ansible) and >> we are happy with the outcome. You might want to consider >> app-admin/salt as well. > > Looks good (had a really quick look). >>From what I read (and please correct me if I'm wrong), a difference between > salt and ansible is: > > Salt Requires a daemon to be installed and running on all machines > and the versions need to be (mostly) in sync > > For Alan, this might work, but for my situation it wouldn't, as I'd need to > keep various VMs in sync with the rest where I'd prefer to simply clone them > and then enforce changes. Relying on SSH and powershell makes that simpler. > > But, it does mean that all nodes need to have incoming ports open. With Salt, > all nodes connect back to the master. This allows a tighter security.
I'm not too stressed either way. All my hosts run sshd anyway and the security is not in whether tcp22 is open or not, it's in what I put in sshd_config. With the puppet design, the puppet daemon must be running (or a cronjob) and puppet can self host that along with nrpe, munin and all the other crap that gets installled so I can do my job :-) My issue with puppet is not it's network architecture but with it's convoluted config language that I can't wrap my brains around. Plus the re-use of similar keywords to mean quite different things meaning I have to read 5 topics in the manual to get stuff working. Nagios btw has the same problem hence why I'm switching to Icinga 2 which fixes Nagios's config language once and for all. -- Alan McKinnon alan.mckin...@gmail.com