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

101–110 of 180 posts

Re: Fucking Shell Scripts

#101

Post by oftenwrong »

agwa wrote: post #51
sbt wrote: post #38

Earlier quoted context omitted.

This does not manage a server, it provisions a server. The whole point of configuration management software is to bring your software into a desired state from any actual state the server may be in. This rests on the notion that configuration drifts, i.e. for long running services a server gets misconfigured eventually for a variety of reasons. Bottom line, if you are just running a small startup with a few servers a…

The CM system I'm using "journals" every change it makes to the system, so if you later remove or change a file or script in your CM repository, it undoes the old change. This eliminates virtually all configuration drift, provided you aren't making changes by hand outside of the CM system (which you should never do anyways). This system has been managing about 100 servers and several hundred desktops at a single site…

Which CM system?

Re: Fucking Shell Scripts

#103

Post by joevandyk »

enjo wrote: post #96
atweiden wrote: post #85

Earlier quoted context omitted.

I use a Bash script to set up Arch with Btrfs on LUKS and optionally enable SSH [1]. Assuming you have a base machine running, config management tools are great and quickly start to make sense. If you're starting from scratch with a blank physical machine, I think the answer is still shell scripts and then add on CM afterwards. 1: https://github.com/atweiden/pacstrapit

"I think the answer is still shell scripts and then add on CM afterwards." I'm genuinely curious. Why? Ansible, in particular, provides the same value (easy) but has existing modules to do a bunch of the things you'd have to script.

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.

Re: Fucking Shell Scripts

#104

Post by _hyn3 »

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…

If using a cloud, another often overlooked option is to just tear down and replace the instance rather than try to update/correct its configuration. In that case, a shell script or Userdata script will be more than enough and represents a single source of truth for how a server will be built (never upgraded).

Re: Fucking Shell Scripts

#105

Post by jamiesonbecker »

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…

Simple is almost always Correct.

Conversely, complex is almost always incorrect.

Re: Fucking Shell Scripts

#106

Post by jamiesonbecker »

rjzzleep wrote: post #65
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…

hah, this is awesome! thank you. i've used both chef, and puppet. and i still have a puppet standalone bootstrap script that i use every now and then. but I too created a simple shell script bootstrapping process for one of the projects i was working on. it pretty much boils down to this: tar cjf bootstrap.tar.bz2 VERSION library $2 scp bootstrap.tar.bz2 protonet@$1:/tmp ssh -A -t myuser@$1 /bin/bash -c " mkdir -p /t…

I agree.

It does in fact make me smile a little bit when the puppet installation script is longer than the script to do whatever it is that needs to be done to install the app itself. :)

Over time, it may make sense to move to a more deterministic solution, but to start there (IMO) is often a case of premature optimization.

Re: Fucking Shell Scripts

#107

Post by billsix »

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…

I thought the unix quote on simple vs correct is regarding things like "what should the kernel do when a process is processing a system call like read/write and needs to handle a signal. should it return an error of type EAGAIN, or somehow completely shield the user-space program of this condition?".

http://www.jwz.org/doc/worse-is-better.html

> This may have been true in an era when every site had to roll a homegrown solution for pert-near everything that didn't come with the base OS, but in this era of open source it is far more important for the implementation to be correct, because the Right Thing can be written once and everybody can use it, and save themselves the accumulated hours of frustration incurred by simple-but-subtly-incorrect implementations.

The BSDs and linux are open source, but we still must check for EAGAIN.

Re: Fucking Shell Scripts

#108

Post by jamiesonbecker »

colechristensen wrote: post #97
deathanatos wrote: post #93

Earlier quoted context omitted.

It's hard to write a portable shell script. My dotfiles need to be portable, and they involve a lot of shell. Every time I introduce a new OS, I have to make changes. Various oddities get you. These, for example, look really innocent but aren't portable: find -iname 'foo*' # [1] ... | sed -e 's/ab\+c//' # [2] ... | sed -i -e 's/abc//' # [3] tar -xf some-archive.tar.gz # [4] python -c 'anything' # [5] Things like mess…

It's a well known fact that GNU tools have plenty of extra features which you have to be careful about using if you want portibility AND that many of the legacy commercial Unix implementations have positively ancient implementations and feature sets. I wouldn't really say it is so very difficult though. Every script you write isn't going to be portable, but it's not that much of a stretch to endeavor to keep your scr…

Portability is a red herring anyway. If you pursue it, you'll always end up chasing the lowest common denominator.

YOU can control where the app is deployed (this is largely true even if you're selling your app just by having installation requirements or by selling appliances instead of installable apps).

Re: Fucking Shell Scripts

#109

Post by icebraining »

cmbaus wrote: post #92
cmbaus wrote: post #59

Earlier quoted context omitted.

I agree. This would be far more awesome if you could install it with a fucking shell script. It is called fucking shell scripts. Not fucking ruby scripts.

Joking aside, there is something to be said about doing CM with the shell. If somebody created a list of requirements for the perfect language for doing CM it would probably be similar to: - Always available on every machine - Proven reliable and stable - Built to interface with the OS and other utilities Hmm, that sounds a lot like the shell. If your application doesn't already depend on Ruby, bringing Ruby in as a…

On the other hand, Python comes installed by default on Red Hat, CentOS, Scientific Linux, Gentoo, Debian, Ubuntu, MacOS X, Solaris and OpenIndiana, at least, so a "full" CM system like Ansible is potentially more portable than FSS :)

Re: Fucking Shell Scripts

#110

Post by _hyn3 »

RyanZAG wrote: post #24
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…

I'm making the assumption that you are running a bunch of AWS instances off the same AMI. If you're not, a shell script is not going to be deterministic or maintainable - but most companies these days are just using AWS with an ubuntu AMI and then running some software on top x100 for each server. The solution to this has been generally very complex deployment and management programs that you need a devops team to ke…

Finally, someone who gets it.

Just because someone wrote something shiny and new that replaces 10 lines of shell with 20 lines of chef installation and another 10 lines of chef, doesn't mean you have to use it.

for box in box1 box2 box3; do

cat # do something

EOF

done

easy. Even better, just pass in some data into userdata with your autoscaling group. (That userdata field? just start it with a #! line just like a shell script... and it'll execute your shell, php, perl, python, etc script!)

Post reply on HN