5 ms·

The first five minutes on any of my servers involve giving it a name, installing puppet and adding the server name to my central puppet config. You seriously d

by zrail 14y ago

The first five minutes on any of my servers involve giving it a name, installing puppet and adding the server name to my central puppet config. You seriously do this by hand for every server? That seems error prone and a huge waste of time when tools like puppet and chef exist.

trxblazr 14y ago
I think the author meant for this to be a simple set of security guidelines for beginners. But yeah, any reasonably large prod stack should probably be deployed and setup with puppet and what not. It's DRY and less error prone than a human low on sleep.
ams6110 14y ago
Puppet and Chef are yet another thing to learn and maintain, if the guy is a part-time admin with a lot of other responsibilities and a small number of servers it may not be worth it.
- WALoeIII 14y ago
  You don't have to re-learn puppet/chef/cfengine/bash script every time. You learn it once. It requires much less effort to "maintain" than manually updating more than 1 box.
- dbarlett 14y ago
  I was in the same position - too many distinct environments for bash/Fabric, too little time to learn Chef/Puppet/CFEngine. Ansible [1] seems like a good compromise: you get the simplicity (runs over SSH) and host targeting of Fabric with the declarative nature and idempotency of the more complex tools. You can start with all-in-one "playbooks" [2], then split out tasks, handlers, Jinja2 templates, files, and variables [3]. As an aside, I think the default fail2ban config is too loose and quiet. Here's [4] an Ansible task file that configures it to be more aggressive and send notification emails. [1] http://ansible.cc/ http://ansible.cc/ [2] https://gist.github.com/dbarlett/5079802 https://gist.github.com/dbarlett/5079802 [3] https://github.com/fdavis/ansible-best-practices https://github.com/fdavis/ansible-best-practices [4] https://gist.github.com/dbarlett/5079715 https://gist.github.com/dbarlett/5079715
  - slurgfest 14y ago
    What do you usually do with these fail2ban notifications?
  - gingerlime 14y ago
    I'm using fabric quite frequently, and am trying to understand what makes a configuration management tools a much better choice. I'm currently using fabric for anything from bootstrap a new environment from scratch, via restoring a snapshot from backups, to pushing code updates stored on git. Perhaps I'm being really daft, but it always evades me why something as simple as sudo("apt-get install -y <name your packages>") needs to be replaced with - name: Install prerequisites for PPA management apt: pkg=$item state=present update_cache=yes with_items: - python-software-properties - software-properties-common I do use a pretty homogeneous environment, which makes things simpler, but this is a deliberate choice to avoid complexity. If I know all my hosts are e.g. debian 6, then what makes ansible/chef/puppet so much better than fabric? I'm not trying to be provocative or negative. I'm really trying to understand the supposedly big difference between what's labelled a deployment tool, and configuration management tools.
    - vacri 14y ago
      that same line in puppet is "package { 'packagename': ensure => installed }". Or you can use 'latest' to keep it updated. multiple packages can be done this way if you have a lot: $prep_packages = ['package1', 'package2', 'blahblah'] package { $prep_packages: ensure => installed } You can of course use extra arguments if you need them.
    - zargon 14y ago
      Deployment tools like fabric are imperative, and configuration management tools are declarative. With configuration management, you define the final state you want the server to be in, and it will do whatever is needed to get it into that state. Some or all of the parts might already be done, and it won't change the parts that are already correct (the declarative configuration is idempotent). Deployment tools just execute whatever script you hand them, and so the scripts are either more brittle (server must be in a precise state beforehand or it doesn't work right), or require more effort to duplicate the work that the configuration management software does to only make the needed changes. If your deployment scripts get complex, it's more difficult to see at a glance what the end configuration is supposed to be.
- grey-area 14y ago
  Puppet and Chef are yet another thing to learn and maintain, if the guy is a part-time admin with a lot of other responsibilities and a small number of servers it may not be worth it. Speaking from experience as a part time admin, it is definitely worth it to automate the process, even with one or two servers. Any build system will repay in spades the first time you have to set up a new server or rebuild an old one, esp. if you're in a hurry after a server failure. That said Linode offers other easier options (Linode specific of course). You can take the commands usually executed, and put them in a shell script in the language of your choice which is uploaded and executed on first run (they call this StackScripts - there are lots of examples and helper scripts on their site, but the scripts are really very basic). It's perhaps easier than learning a DSL as it's just codifying the same commands you would run via ssh by hand. You can also clone nodes so you could set one up in a known good state and clone that each time. This does tie you to linode, so long term one of the other options available would be worth looking in to.
- kelnos 14y ago
  I think being a part-time admin with other responsibilities is a perfect reason to learn something like Chef or Puppet. It'll end up saving you a lot of time that you can devote to other things.
baghali 14y ago
Without Chef there would be no way for me to rollout a new server in our cluster. Investing time into Chef was one of the greatest things I ever did. Chef is the best documentation of our infrastructure. The second best tool I'm using is fpm[1] to make custom debian packages. [1] https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm
Volpe 14y ago
While not directly related to this article, last I checked Puppet/Chef don't have particularly useful windows support. Is there an chef like solution for windows?
- tedchs 14y ago
  Puppet has great Windows support nowadays; not sure about Chef.

by zrail 14y ago

trxblazr 14y ago

I think the author meant for this to be a simple set of security guidelines for beginners. But yeah, any reasonably large prod stack should probably be deployed and setup with puppet and what not. It's DRY and less error prone than a human low on sleep.

ams6110 14y ago

Puppet and Chef are yet another thing to learn and maintain, if the guy is a part-time admin with a lot of other responsibilities and a small number of servers it may not be worth it.

WALoeIII 14y ago
You don't have to re-learn puppet/chef/cfengine/bash script every time. You learn it once. It requires much less effort to "maintain" than manually updating more than 1 box.
dbarlett 14y ago
I was in the same position - too many distinct environments for bash/Fabric, too little time to learn Chef/Puppet/CFEngine. Ansible [1] seems like a good compromise: you get the simplicity (runs over SSH) and host targeting of Fabric with the declarative nature and idempotency of the more complex tools. You can start with all-in-one "playbooks" [2], then split out tasks, handlers, Jinja2 templates, files, and variables [3]. As an aside, I think the default fail2ban config is too loose and quiet. Here's [4] an Ansible task file that configures it to be more aggressive and send notification emails. [1] http://ansible.cc/ http://ansible.cc/ [2] https://gist.github.com/dbarlett/5079802 https://gist.github.com/dbarlett/5079802 [3] https://github.com/fdavis/ansible-best-practices https://github.com/fdavis/ansible-best-practices [4] https://gist.github.com/dbarlett/5079715 https://gist.github.com/dbarlett/5079715
- slurgfest 14y ago
  What do you usually do with these fail2ban notifications?
- gingerlime 14y ago
  I'm using fabric quite frequently, and am trying to understand what makes a configuration management tools a much better choice. I'm currently using fabric for anything from bootstrap a new environment from scratch, via restoring a snapshot from backups, to pushing code updates stored on git. Perhaps I'm being really daft, but it always evades me why something as simple as sudo("apt-get install -y <name your packages>") needs to be replaced with - name: Install prerequisites for PPA management apt: pkg=$item state=present update_cache=yes with_items: - python-software-properties - software-properties-common I do use a pretty homogeneous environment, which makes things simpler, but this is a deliberate choice to avoid complexity. If I know all my hosts are e.g. debian 6, then what makes ansible/chef/puppet so much better than fabric? I'm not trying to be provocative or negative. I'm really trying to understand the supposedly big difference between what's labelled a deployment tool, and configuration management tools.
  - vacri 14y ago
    that same line in puppet is "package { 'packagename': ensure => installed }". Or you can use 'latest' to keep it updated. multiple packages can be done this way if you have a lot: $prep_packages = ['package1', 'package2', 'blahblah'] package { $prep_packages: ensure => installed } You can of course use extra arguments if you need them.
  - zargon 14y ago
    Deployment tools like fabric are imperative, and configuration management tools are declarative. With configuration management, you define the final state you want the server to be in, and it will do whatever is needed to get it into that state. Some or all of the parts might already be done, and it won't change the parts that are already correct (the declarative configuration is idempotent). Deployment tools just execute whatever script you hand them, and so the scripts are either more brittle (server must be in a precise state beforehand or it doesn't work right), or require more effort to duplicate the work that the configuration management software does to only make the needed changes. If your deployment scripts get complex, it's more difficult to see at a glance what the end configuration is supposed to be.
grey-area 14y ago
Puppet and Chef are yet another thing to learn and maintain, if the guy is a part-time admin with a lot of other responsibilities and a small number of servers it may not be worth it. Speaking from experience as a part time admin, it is definitely worth it to automate the process, even with one or two servers. Any build system will repay in spades the first time you have to set up a new server or rebuild an old one, esp. if you're in a hurry after a server failure. That said Linode offers other easier options (Linode specific of course). You can take the commands usually executed, and put them in a shell script in the language of your choice which is uploaded and executed on first run (they call this StackScripts - there are lots of examples and helper scripts on their site, but the scripts are really very basic). It's perhaps easier than learning a DSL as it's just codifying the same commands you would run via ssh by hand. You can also clone nodes so you could set one up in a known good state and clone that each time. This does tie you to linode, so long term one of the other options available would be worth looking in to.
kelnos 14y ago
I think being a part-time admin with other responsibilities is a perfect reason to learn something like Chef or Puppet. It'll end up saving you a lot of time that you can devote to other things.

baghali 14y ago

Without Chef there would be no way for me to rollout a new server in our cluster. Investing time into Chef was one of the greatest things I ever did. Chef is the best documentation of our infrastructure. The second best tool I'm using is fpm[1] to make custom debian packages. [1] https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm

Volpe 14y ago

While not directly related to this article, last I checked Puppet/Chef don't have particularly useful windows support. Is there an chef like solution for windows?

tedchs 14y ago
Puppet has great Windows support nowadays; not sure about Chef.