Slashdot Mirror

It's interesting that they bought out another tool when they already do some of the work a configuration management tool does with their satellite server, and for a larger setup integrate/sell puppet enterprise (one of Ansible's main competitors).

Now that PuppetLabs has destroyed everything by making puppet 4 incompatible with puppet 3, I'll take a look at ansible.

Most of that "incompatibility"? It's not like it's that hard to upgrade. To be honest, for most of it? If (for instance) you haven't quoted your strings all this time (and if you haven't kept your booleans non-quoted), then it's more your fault than theirs; clean your shiz up.

(...and seriously, they even include future parser in the later 3.x versions to check for all that shit beforehand, so it's not like nobody got warned for something like 6-9 months in advance...)

This problem isn't just in pure developer-land.

As an example, meander on down to the PuppetForge and look at the common modules used to do boring stuff.

For example, installing and maintaining PHP on a box via Puppet should be drop-simple, with little-to-no work... I designed and wrote a simple module for it in like 30 minutes, spending 15 minutes of that having a cigarette, no sweat. But one look at some of these, and you'd think they were writing Turing-capable climate modeling software. Okay, I exaggerate (a little), but the point is, these guys spend untold hours trying to turn a set of car tires into jet engines.

Here's where it gets ugly: Most DevOps folks liberally download these beasts and implement them, never realizing (until it's way too late) that the vast majority of these modules are written either to be cute, to be clever-by-too-far, or to bolster someone's resume ('look, I'm a coding deity!' type crap***). They then spend hours on end busting their ass trying to get these damned things to work in their environment, and end up with something that quite frankly eats more CPU cycles and disk space then it really should... by orders of magnitude.

TL;DR? The greatest wasting of time I've seen in development and beyond is when people try to get too cute or too clever with code.

*** if someone showed me some of these ugly-assed bloat-factories as part of the interview process, they would face some damned hard questions from me about design before I'd even think of recommending them to be hired.

Seriously? Puppet Labs has supported it for 5 years now. Managing a slackware sever or servers is no harder or easier than any other one. Now, if you're hand rolling special snowflakes and have no strategy to manage them, sure. But that would be true for any distro or OS.

Also, I forgot to mention, Puppet Labs' IT automated config is pretty effing amazing. I've been trying to dedicate time to ramping on it, and have been to a few classes at their office in Portland, but it is definitely on my list of tools to learn.

http://puppetlabs.com/

Using anything like puppet or chef under version control to do all server ops will not only leave you with a full timestamped documentation, but will allow you to easily horizontally scale servers, rebuild them should disaster strike and protect you from stupid upstream package updates that b0rk your config files.

Have a staging and production environment? pushing your chef/puppet scripts to production after they're proven to work insures you have the same changes applied on both sides, and avoid manual operations on production.

What makes you think that this was intentional and not just a typo?

Your agenda. Your post is clearly biased on defending Ruby.

Interestingly I do not have an agenda on Ruby and in fact it was a simple typo. As a non-native speaker I find the way how names and compounds are handled in the English language confusing at best. It's much easier in German: all compounds are written in one single word, no spaces, no dashes. You're allowed to add dashes to make life for the reader easier (Atombombenzündmechanismus is not a handy word).

That would be Ok, we're all biased somehow - but experience taught me that tech people has a strong inclination to include lies and fallacies while arguing on subjects he/she has a bias on.

Isn't it ironic that your own post represents a fallacy? Of course I have the arrogance to assume that I know best which motives my original post was based on -- and which not.

"Javascript" is a word massively disseminated - very improbable that one professional that makes a living in this field would misspell this word the way you did.

See, indeed I am a CS professional. I've specialized in HPC. The way I use Ruby is very different from what the web folks use it for: thanks to Puppet Ruby has become a popular language for managing system configuration, especially for large scale deployments. Hence I do have a significant exposure to Ruby, without ever doing any serious JS coding. And that's what I criticize in TFA: it seems to equate Ruby with "language for web apps". Its argument revolves around "b/c of node.js becoming popular, Ruby is/might be dying". And that's just wrong because even if Rails would just disappear, there would still be tons of valid use cases for Ruby (text mangling, build automation, rapid prototyping, network automation...).

If fact I don't care much about whether Ruby is popular or not. I've used it before Rails was popular, and I wouldn't have any second thoughts about adding another language to my portfolio, should I see any major benefit in it.

We kids have no idea what its like upgrading thousands of computers at work because unlike you, grandpa, we use [Ansible / Salt / Chef / CFEngine / Puppet]. And making changes to thousands and thousands of machines takes seconds to send out to all of them. A bit more time to verify, and any that are stuck can be rebuilt from scratch in a few more moments without even worrying about why it didn't work the first time.

Second point: why would you need some kind of interface to your firewall rules. Its a text file. Learn the syntax and keep in in version control. Then have the back end of version control push the change out through the programs that I just mentioned.

You're getting old. Its probably time to retire.

Whoosh ... read a little below on the comments section :-)

We kids have no idea what its like upgrading thousands of computers at work because unlike you, grandpa, we use [Ansible / Salt / Chef / CFEngine / Puppet]. And making changes to thousands and thousands of machines takes seconds to send out to all of them. A bit more time to verify, and any that are stuck can be rebuilt from scratch in a few more moments without even worrying about why it didn't work the first time.

Second point: why would you need some kind of interface to your firewall rules. Its a text file. Learn the syntax and keep in in version control. Then have the back end of version control push the change out through the programs that I just mentioned.

You're getting old. Its probably time to retire.

Make sure you get the official documention from Ahttp://docs.puppetlabs.com/. I haven't really seen any books or anything else that is as complete and accurate, especially the reference and learning puppet books.

I find the "puppet resource" command is one of the most useful. You can use it to generate a script for a given configuration and use it to duplicate it elsewhere.

Who will be the first to make a Puppet tutorial running multiple networked Linux instances in your browser?

http://puppetlabs.com/

There you go.

You DID miss something. You pay those prices if you want SUPPORT for the licenses. If you can support yourself, just use the Open Source version. Sort of like RHEL vs Fedora

No. There's plenty functionality you get in the Enterprise version that you don't get in the open source version, so nothing like RHEL vs CentOS (which I assume is what you meant). If you want those features you'll be paying whether you want support or not.

Either I'm missing something obvious, or it's free for 10-nodes and you start paying quite a bit for anything beyond that. http://puppetlabs.com/puppet/how-to-buy/

Node Packs Puppet Enterprise with Standard Support and Maintenance
10 FREE
25 $1,995
100 $6,995
250 $16,995
500 $29,995
1,000 $55,995
More than 1,000 Contact sales@puppetlabs.com

You DID miss something. You pay those prices if you want SUPPORT for the licenses. If you can support yourself, just use the Open Source version. Sort of like RHEL vs Fedora

Either I'm missing something obvious, or it's free for 10-nodes and you start paying quite a bit for anything beyond that.
http://puppetlabs.com/puppet/how-to-buy/

Node Packs
10 FREE
25 $1,995
100 $6,995
250 $16,995
500 $29,995
1,000 $55,995
More than 1,000 Contact sales@puppetlabs.com

Say what?

http://puppetlabs.com/

LOL this is the weekly ask /. where the questioner describes the perfect application for Puppet and then asks what to use.

My only other addition is install and set up torque and dish.

Torque is a decent queuing system. Everybody queue up a job to do "something" as quickly as possible, but strictly one at a time.

The DISH distributed shell lets you run a single command line (which could be a script...) on all machines right now. Simultaneously or whatever.

Puppet combined with either Foreman or Cobbler

http://puppetlabs.com/

You have to use the correct tools... try puppet as the number of server increase

for AD like, try likewise or esoeproject.org

AD works for windows, but only windows... if you have MacOSX, Linux, Solaris, etc you need more tools or at least more cross-platform ones... the AD LDAP part can be replaced easily and most of the time you can still use the same windows tools... with samba 4 you will be able to replace the AD totally

finally, you can use policy setting in most linux apps, just set the config and change the permission of the config file

It doesn't. There's some infrastructure in place, but nothing close to the out of box simplicity and functionality of AD and Group Policy.

While agreed, it's not out of the box, there are AD solutions for LInux. http://www.quest.com/identity-management/

There's also distribution tools and models for ease of distribution. http://www.puppetlabs.com/

And let's not forget a centralized intrusion detection system. http://www.la-samhna.de/samhain/

Plenty of tools available for system distribution, and no need to 're-invent the wheel' or 'roll their own' to do so. So productivity generally includes installing these tools, configuring them, then globally distributing them based on preset configurations to all the other servers.

We use a lot of the tools above, and many others, to be able to rebuild a system, with a unique configuration, unique mount points, unique application and databases, and can generally go from bare-bone box to live server in under 20 minutes.

I'll just use the puppet master feat I unlocked from playing so many hours.

Policy management: This is a little less defined in the Unix world than it is in Windows, but still manageable. Most of these policies are managed by various text files in Unix, so what I typically do is run a script when I first install them to set everything the way I want it. In the unlikely event I need to make a change I just change one system and propagate it to all the others. I have a script that copies a file where ever it needs to go on every machine in the network. You can also automate this through rsync though I've never personally bothered to set this up. I've never run a network complicated enough to really need it. The hard part here is if you have a heterogeneous Unix environment, since nearly all Unix's insist on using different files and different syntax to manage this stuff. I'll admit this is a slightly weak area, but definitely manageable.

Save yourself some headaches and use Puppet. It's great!