5 ms·

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

by dogas 13y ago

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 replace ansible where we work. All that being said however, I feel like this (or a project like this) does have merit, if executed properly. I feel that once you get used to how FSS works, it might be a good solution for you. We intentionally tried to keep it as simple as possible.

sdegutis 13y ago
We're using Chef right now, and evaluating other options. They seem to either be between way too over-engineered, or not flexible enough, but nowhere in between. I'd love to see a tool like yours be brought to full maturity, then I think I'd love to use it.
- frist45 13y ago
  Other co-author here: I couldn't agree with you enough. We settled on Ansible, but have had our fair share of speed bumps along the way.
  - mikegirouard 13y ago
    Out of pure curiosity, what makes Ansible the best choice for you? For my team, I decided on Ansible because it was the simplest option (no agents to install, pure ssh).
    - sdegutis 13y ago
      By the way, that's the same reason I'm investigating using Pallet[1]. [1]: http://palletops.com/ http://palletops.com/
    - frist45 13y ago
      We were coming from Chef where no one knew what was going on. We were looking for something simpler. There wasn't really many other options unfortunately. We're not full-time devops people...hence much of our frustration.
- digisign 13y ago
  As I mentioned in another place above, if you'd like an alternative that is even simpler than ansible, yet still idempotent, try pave: https://pypi.python.org/pypi/pave https://pypi.python.org/pypi/pave https://bitbucket.org/mixmastamyk/pave https://bitbucket.org/mixmastamyk/pave
Spittie 13y ago
Thanks for this. Lately I've been researching a way to automate things for a bunch of vps I own (nothing important, mostly self-hosted services like tt-rss), and obviously I looked at Chef/Puppet/Salt/Ansible and the likes. While those are valuable and awesome tools, I feel that they're too complicated for my simple needs. FSS seems exactly the right compromise between running everything manually and using a full blown management tool.
_Adam 13y ago
I can imagine someone proposing this at some meeting with managers. "For our next product, we're going to use FUCKING SHELL SCRIPTS for configuration and deployment". What would the managers' faces look like... I wonder if this is what you guys had in mind when you came up with the name
- dogas 13y ago
  The name came about when we were writing the majority of our ansible code. We mentioned to each other in frustration multiple times, "Man, this would be so much easier if I could just use fucking shell scripts."
  - mpdehaan2 13y ago
    http://docs.ansible.com/script_module.html http://docs.ansible.com/script_module.html :)
  - dorfsmay 13y ago
    When was this? Ansible today is much smoother than a year ago.
- dasil003 13y ago
  Just say FSS, managers love acronyms!
digisign 13y ago
If you'd like an alternative that is even simpler than ansible, yet still idempotent, try pave: https://pypi.python.org/pypi/pave https://pypi.python.org/pypi/pave https://bitbucket.org/mixmastamyk/pave https://bitbucket.org/mixmastamyk/pave
rjzzleep 13y ago
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 /tmp/runscript cd /tmp/runscript . ~/.profile tar xjvf /tmp/bootstrap.tar.bz2 bash /tmp/runscript/$2 $3 rm -rf /tmp/runscript rm /tmp/bootstrap.tar.bz2" so far i haven't really found a good reason why we can't just have a library of generic bash scripts doing things. i have to apologize about the crappy function style, and the inconsistent shebangs, but meh, whatever. https://github.com/fishman/simple_deploy https://github.com/fishman/simple_deploy
- jamiesonbecker 13y ago
  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.
  - jsmeaton 13y ago
    Installation is mostly trivial. Maintaining a bunch of systems is not. > 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. I mostly agree with this though.
- area51org 13y ago
  why we can't just have a library of generic bash scripts doing things. It depends on what you're doing, I suppose. Me? I wouldn't want to try to use "simple" bash scripts to manage a large (or even medium) app farm, especially when those servers need ongoing management.
samstave 13y ago
I love it - we got into a dialogue at work today with OPs and Eng on what to use for config mgmt (of our app)... and then this hit HN today... I sent this along as a tongue-in-cheek 100% Solution. And.... I actually read the site after I sent this along and realized its actuallyfuckingcoolshellscripts.org So... thanks!
networked 13y ago
I see the appeal of FSS; I've felt frustrated with the extra effort it takes to describe some operations using Ansible compared to shell scripts. However, your project suggests to me that what we may really need is a tool to translate shell scripts into (reasonably idiomatic) Ansible playbooks, perhaps interactively and with further review from the user. That, or to otherwise automate the creation of playbooks where possible. Edit: removed speculation about an idempotent *nix shell.
bitwize 13y ago
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 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. This is why the Linux world is standardizing on systemd -- to get AWAY from Fucking Shell Scripts and towards a more deterministic, declarative model of what we want done. In the case of configuration management, what you want is a tool that accepts a description of what the system configuration should be, diffs that against the current configuration, and enacts a plan of changes to get from point A to point B automatically. NixOS seems to be a good step in this overall direction. Fun fact: I used to do instancing of robotic control computers running a specialized version of Debian with Fucking Shell Scripts (FAI, to be exact: http://fai-project.org/ http://fai-project.org/ ). It was pure hell. We would have killed for a more deterministic solution.
- jamiesonbecker 13y ago
  Simple is almost always Correct. Conversely, complex is almost always incorrect.
  - mercurial 13y ago
    "Simple enough is almost always correct". "Too simple for the problem domain" is almost always a synonym for "build a heap of absolutely terrible and verbose pile of complexity on top of the 'simple' system". See also sysvinit.
  - kelnos 13y ago
    Strongly disagree. Often complexity in your implementation is necessary to present a simple interface to your user.
twic 13y ago
What were your frustrations with Ansible?
stevekemp 13y ago
You definitely win points for working over pure SSH, I love tools that do that. (Which include 'fabric', 'ansible', and similar.) Me? I like perl and I decided I'd write something that just executed "primitives" locally. Then setup a flexible system of pulling them from git, via rsync, etc. My tool is largely ignored, but modelled after CFENgine 2.x, and is here: http://www.steve.org.uk/Software/slaughter/ http://www.steve.org.uk/Software/slaughter/

by dogas 13y ago

sdegutis 13y ago

We're using Chef right now, and evaluating other options. They seem to either be between way too over-engineered, or not flexible enough, but nowhere in between. I'd love to see a tool like yours be brought to full maturity, then I think I'd love to use it.

frist45 13y ago
Other co-author here: I couldn't agree with you enough. We settled on Ansible, but have had our fair share of speed bumps along the way.
- mikegirouard 13y ago
  Out of pure curiosity, what makes Ansible the best choice for you? For my team, I decided on Ansible because it was the simplest option (no agents to install, pure ssh).
  - sdegutis 13y ago
    By the way, that's the same reason I'm investigating using Pallet[1]. [1]: http://palletops.com/ http://palletops.com/
  - frist45 13y ago
    We were coming from Chef where no one knew what was going on. We were looking for something simpler. There wasn't really many other options unfortunately. We're not full-time devops people...hence much of our frustration.
digisign 13y ago
As I mentioned in another place above, if you'd like an alternative that is even simpler than ansible, yet still idempotent, try pave: https://pypi.python.org/pypi/pave https://pypi.python.org/pypi/pave https://bitbucket.org/mixmastamyk/pave https://bitbucket.org/mixmastamyk/pave

Spittie 13y ago

Thanks for this. Lately I've been researching a way to automate things for a bunch of vps I own (nothing important, mostly self-hosted services like tt-rss), and obviously I looked at Chef/Puppet/Salt/Ansible and the likes. While those are valuable and awesome tools, I feel that they're too complicated for my simple needs. FSS seems exactly the right compromise between running everything manually and using a full blown management tool.

_Adam 13y ago

I can imagine someone proposing this at some meeting with managers. "For our next product, we're going to use FUCKING SHELL SCRIPTS for configuration and deployment". What would the managers' faces look like... I wonder if this is what you guys had in mind when you came up with the name

dogas 13y ago
The name came about when we were writing the majority of our ansible code. We mentioned to each other in frustration multiple times, "Man, this would be so much easier if I could just use fucking shell scripts."
- mpdehaan2 13y ago
  http://docs.ansible.com/script_module.html http://docs.ansible.com/script_module.html :)
- dorfsmay 13y ago
  When was this? Ansible today is much smoother than a year ago.
dasil003 13y ago
Just say FSS, managers love acronyms!

digisign 13y ago

If you'd like an alternative that is even simpler than ansible, yet still idempotent, try pave: https://pypi.python.org/pypi/pave https://pypi.python.org/pypi/pave https://bitbucket.org/mixmastamyk/pave https://bitbucket.org/mixmastamyk/pave

rjzzleep 13y ago

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 /tmp/runscript cd /tmp/runscript . ~/.profile tar xjvf /tmp/bootstrap.tar.bz2 bash /tmp/runscript/$2 $3 rm -rf /tmp/runscript rm /tmp/bootstrap.tar.bz2" so far i haven't really found a good reason why we can't just have a library of generic bash scripts doing things. i have to apologize about the crappy function style, and the inconsistent shebangs, but meh, whatever. https://github.com/fishman/simple_deploy https://github.com/fishman/simple_deploy

jamiesonbecker 13y ago
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.
- jsmeaton 13y ago
  Installation is mostly trivial. Maintaining a bunch of systems is not. > 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. I mostly agree with this though.
area51org 13y ago
why we can't just have a library of generic bash scripts doing things. It depends on what you're doing, I suppose. Me? I wouldn't want to try to use "simple" bash scripts to manage a large (or even medium) app farm, especially when those servers need ongoing management.

samstave 13y ago

I love it - we got into a dialogue at work today with OPs and Eng on what to use for config mgmt (of our app)... and then this hit HN today... I sent this along as a tongue-in-cheek 100% Solution. And.... I actually read the site after I sent this along and realized its actuallyfuckingcoolshellscripts.org So... thanks!

networked 13y ago

I see the appeal of FSS; I've felt frustrated with the extra effort it takes to describe some operations using Ansible compared to shell scripts. However, your project suggests to me that what we may really need is a tool to translate shell scripts into (reasonably idiomatic) Ansible playbooks, perhaps interactively and with further review from the user. That, or to otherwise automate the creation of playbooks where possible. Edit: removed speculation about an idempotent *nix shell.

bitwize 13y ago

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 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. This is why the Linux world is standardizing on systemd -- to get AWAY from Fucking Shell Scripts and towards a more deterministic, declarative model of what we want done. In the case of configuration management, what you want is a tool that accepts a description of what the system configuration should be, diffs that against the current configuration, and enacts a plan of changes to get from point A to point B automatically. NixOS seems to be a good step in this overall direction. Fun fact: I used to do instancing of robotic control computers running a specialized version of Debian with Fucking Shell Scripts (FAI, to be exact: http://fai-project.org/ http://fai-project.org/ ). It was pure hell. We would have killed for a more deterministic solution.

jamiesonbecker 13y ago
Simple is almost always Correct. Conversely, complex is almost always incorrect.
- mercurial 13y ago
  "Simple enough is almost always correct". "Too simple for the problem domain" is almost always a synonym for "build a heap of absolutely terrible and verbose pile of complexity on top of the 'simple' system". See also sysvinit.
- kelnos 13y ago
  Strongly disagree. Often complexity in your implementation is necessary to present a simple interface to your user.

twic 13y ago

What were your frustrations with Ansible?

stevekemp 13y ago

You definitely win points for working over pure SSH, I love tools that do that. (Which include 'fabric', 'ansible', and similar.) Me? I like perl and I decided I'd write something that just executed "primitives" locally. Then setup a flexible system of pulling them from git, via rsync, etc. My tool is largely ignored, but modelled after CFENgine 2.x, and is here: http://www.steve.org.uk/Software/slaughter/ http://www.steve.org.uk/Software/slaughter/