Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fucking Shell Scripts

fuckingshellscripts.org

Post reply on HN
Print view View original

161–170 of 180 posts

Re: Fucking Shell Scripts

#161

Post by jewel »

mercurial wrote: post #135
mattjaynes wrote: post #81

Have to say I'm a bit puzzled by the claim of Ansible being "blow your brains out" difficult. In many cases, Ansible is even easier than shell scripts. I wrote a post about this a few months ago: https://devopsu.com/blog/ansible-vs-shell-scripts/ I completely understand where the sentiment is coming from though. I wrote a comparison book on Puppet, Chef, Salt, and Ansible a few months ago and am currently finishing t…

> A huge advantage of using a configuration management (CM) tool is that they're "idempotent". Idempotency basically means that you can run the directives over and over again safely. They're idempotent only as long as the configuration stays the same. If you removed this "apt: package=XXX state=present" line, XXX is not going to be magically uninstalled, but you may have a nasty surprise the next time you attempt to…

Until Nix becomes more popular, I've been thinking about ways to build an audit tool that would work with CM tools to handle this case:

http://stevenjewel.com/2014/03/puppet-undo-and-puppet-audit/

Re: Fucking Shell Scripts

#162

Post by bdunbar »

darklajid wrote: post #138
mattjaynes wrote: post #81

Have to say I'm a bit puzzled by the claim of Ansible being "blow your brains out" difficult. In many cases, Ansible is even easier than shell scripts. I wrote a post about this a few months ago: https://devopsu.com/blog/ansible-vs-shell-scripts/ I completely understand where the sentiment is coming from though. I wrote a comparison book on Puppet, Chef, Salt, and Ansible a few months ago and am currently finishing t…

In my experience (playing with ansible, on and off, for quite a while) limitations or bugs in the tool often lead to your ansible scripts to become .. shell scripts. The more raw/command/shell modules you have to use, the uglier the whole approach seems to me - and maybe not worth the trouble in the first place. If it can't be done 100% 'right', should I bother? I put my efforts on hold so far. Ansible improved great…

> The more raw/command/shell modules you have to use

Yeah, that's a problem. It's gotten a lot better with the 1.5 release.

Example: we just made the light-speed jump from 1.1 to 1.5. While re-doing a role yesterday, I noticed we now have a module for ec2 snapshots.

So _next_ week I'm replacing a 50-line bash script with a five-line playbook. Which will be run by Jenkins.

Re: Fucking Shell Scripts

#163

Post by mercurial »

mateuszf wrote: post #149
joevandyk wrote: post #103

Earlier quoted context omitted.

you gotta setup the ssh user, modify/install ssh keys, install python if it's not there, possibly adjust firewalls, setup the hostnames, possibly tell the machine where to find the private dns servers, etc.

Actually, to use Ansible you need only ssh access (with password or public key) to root user. Everything else can be done easily in a simple Ansible role.

In fact you can specify the user, you can have a dedicated user with sudo for instance.

Re: Fucking Shell Scripts

#164

Post by eikenberry »

kelnos wrote: post #144
eikenberry wrote: post #143

Earlier quoted context omitted.

The primary user of your implementation is the next developer to maintain it.

The user of a piece of software is more important than its current or future maintainers.

Thinking like this is why we have so much crappy software out there.

Re: Fucking Shell Scripts

#165

Post by bitwize »

kelnos wrote: post #137
jamiesonbecker wrote: post #105

Earlier quoted context omitted.

Simple is almost always Correct. Conversely, complex is almost always incorrect.

Strongly disagree. Often complexity in your implementation is necessary to present a simple interface to your user.

To quote Ryan Dahl: The only thing that matters in software is the experience of the user.

How many more times must it be said? How many more times must Apple win -- and win big -- before open source nerds get the message?

Re: Fucking Shell Scripts

#166

Post by bashcoder »

rdtsc wrote: post #120
mattjaynes wrote: post #81

Have to say I'm a bit puzzled by the claim of Ansible being "blow your brains out" difficult. In many cases, Ansible is even easier than shell scripts. I wrote a post about this a few months ago: https://devopsu.com/blog/ansible-vs-shell-scripts/ I completely understand where the sentiment is coming from though. I wrote a comparison book on Puppet, Chef, Salt, and Ansible a few months ago and am currently finishing t…

> Have to say I'm a bit puzzled by the claim of Ansible being "blow your brains out" difficult. Well not blow your brains out difficult but "learn a new syntax, behavior, rules, depend on a new package" difficult if a few shell commands is all you want to do. I can see where they are coming from. I can go a long way just using shell script to configure (and yes, you can make them idempotent too). From your site: > Yo…

Well, I'm a Salt user and I was communicating with Matt during the writing of his book. During that time he certainly gave Salt a solid, fair evaluation. He also spent a lot of time hanging out in #salt IRC asking key questions, and answering some as well.

So I would suggest that it's natural and OK for someone's evaluation process to yield a favorite (apparently in Matt's case, it's Ansible), without it becoming a "religious passion."

Re: Fucking Shell Scripts

#167

Post by phazmatis »

justizin wrote: post #45
phazmatis wrote: post #32

Earlier quoted context omitted.

Most people coming from chef would have done the drudgery of msking surr ruby works.

chef installs as omnibus, so you're suggesting that people should install the massive chef stack, and then the FSS gem? _brilliant_ !

Well this is clearly aimed at people who are frustrated with Chef, above and beyond the frustrations of figuring out how to install ruby (just install from source, rvm sucks).

If someone doesn't already have Chef installed, why would they even have clicked on this link?

Re: Fucking Shell Scripts

#168

Post by phazmatis »

icebraining wrote: post #83
phazmatis wrote: post #34

Earlier quoted context omitted.

I guess you could load your favorite language runtime. That sounds like a one line change. In your shell script. Which is the point. I'm betting at some point you look back and realize that much of your config doesn't need a secondary language.

How would you take a template file, fill in some values, copy it to a certain path on the server and give it the right permissions? With, say, Python, I'd have to read the file, using mako or jinja to fill in the values, scp the file to some temporary file, then somehow run Python code on the server using SSH to copy the file and give it the right permissions. With Ansible, this is a single line.

Let's see... I would take the template file, fill in some values, scp it up to it's final location on the server, and run chmod on the server.

I guess I could learn the "one-line" ansible way to do it, but I'd also have to learn to set up ansible. And I'm guessing it's not as flexible as, say, shell scripts.

Re: Fucking Shell Scripts

#169

Post by Curmudgel »

colechristensen wrote: post #35
nawitus wrote: post #13

Earlier quoted context omitted.

Typically shell scripts are fine in the beginning, but over time the complexity rises and it becomes an unmaintanable mess, and you'll end up reimplementing it in a proper programming language. Shell scripts are not easily portable either, unless by "portable" you mean "works in Linux". Node.js scripts, for example, really (mostly) work on Linux and other platforms like Windows. Until you hit some nasty "path is long…

Shell scripts are extremely portable and should be the preferred method for a large set of tasks. Properly written, a shell script can run on a 20 year old Solaris machine, any version of Windows (with installed tools like Cygwin) and any modern Unix variant... claiming Node.js is more portable is ridiculous on so many levels. The problem is so many programmers don't take the time (or care to take the time) to learn…

>The problem is so many programmers don't take the time (or care to take the time) to learn to use the well thought out design of Unix tools opting instead to see every problem as a nail corresponding to the latest trend in hammers (programming languages).

Unix tools are the arguably the best tools available to a modern user. That, however does not mean that the Unix tools are well designed; many would argue that the Unix tools are extremely poorly designed or have no discernible design at all. S-expression are a much more powerful and useful abstraction than a "stream of bytes". POSIX was hacked on many years later in attempt to make sense out of the mess that shell commands had become. Shell scripts are very fragile and have never been truly portable across various *nixes, although the situation is better than it was twenty years ago, when it was enormously difficult to port scripts across the various commercial Unix installations, because they would break in many different and subtle ways.

I recommend reading the out of date but still useful Unix Haters Handbook: http://pdf.textfiles.com/books/ugh.pdf

Re: Fucking Shell Scripts

#170

Post by kjs3 »

bitwize wrote: post #82
dogas wrote: post #16

Coauthor here. Well, this is a surprise! This project was mainly borne out of our frustrations with Chef and then Ansible for configuring our servers. A few thoughts: 1) This project is incomplete and is more of a concept than anything. We wrote it literally in an afternoon, and were giggling like schoolgirls the whole time. 2) There is value in what Ansible provides. It does a lot of things for you. FSS did not repl…

It's pretty funny, but it's an example of where we do NOT want to be headed. The Unix philosophy is a set of tenets based on assumptions that held in the 1970s and 1980s, but don't really hold today. One of these tenets is, "make the implementation as simple and as correct as possible; it is better for an implementation to be simple than to be correct." This may have been true in an era when every site had to roll a…

> One of these tenets is, "make the implementation as simple and as correct as possible; it is better for an implementation to be simple than to be correct."

Having been a Unix admin since long before Linux existed, I find this statement to be complete bullshit.

Post reply on HN