Live data from Hacker News

Fucking Shell Scripts

fuckingshellscripts.org

141–150 of 180 posts

Re: Fucking Shell Scripts

#141
post #28

The nice thing about an approach like this is that you don't actually need to use shell for your scripts - you could use Perl, Python, etc. The point is you can just write in whatever scripting language you like/gets the job done and not need to worry about learning a new domain-specific configuration language. Does anyone else here see value in a configuration management system that centers around installing files a…

I use (my own tool) Slaughter for configuring about fifteen servers. The vast majority of configuration changes are:

* Upload/update a configuration file, and if it resulted in a change then restarting the affected service. * Append a line to a file, if it is missing. * Search/replace a pattern against a file and do something if that resulted in a change.

So yes, add the ability to install/remove a native package (be it a .deb, .rpm, or whatever) and you've got a lot of power.

http://www.steve.org.uk/Software/slaughter/

Re: Fucking Shell Scripts

#143
post #137

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.

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

Re: Fucking Shell Scripts

#144
post #137

Earlier quoted context omitted.

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

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.

Re: Fucking Shell Scripts

#145

Earlier quoted context omitted.

> 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…

Are there VPS providers that offer NixOS by OOTB?

No need for that. The configuration management of NixOS is baked right into the installation procedure. This makes it super simple to install a fresh machine completely from the configuration.nix file that you've developed over time.

Re: Fucking Shell Scripts

#146

Earlier quoted context omitted.

Are there VPS providers that offer NixOS by OOTB?

No need for that. The configuration management of NixOS is baked right into the installation procedure. This makes it super simple to install a fresh machine completely from the configuration.nix file that you've developed over time.

Well, with an OpenVZ VPS, the most common variety these days, you'd have to have it offered by the provider.

Re: Fucking Shell Scripts

#147

Earlier quoted context omitted.

Which is another way of saying it's Ansible without all of the stuff you don't need (plus obscenities).

We can add obscenities if you want :) We do have cowsay integration though. (There are some questionable cowsay modes!) That all being said, the thing missing here between any of these tools is most obviously the resource model -- and the templating system and where you put variables and things to manage variance between systems. Thus, it will blast out some commands for you, but that is the easiest part of the equat…

You just sold me on trying ansible.

Re: Fucking Shell Scripts

#148
post #96

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.

In my experience, there's a huge amount of work involved in just getting Ansible (and other CM systems) to work right in the first place, especially if you're relatively new to CM.

Sometimes you're working on a scrappy prototype and it's just quicker to use shell scripts initially and then go back to solidify the setup into CM scripts afterwards, once you know what you actually need.

Of course that approach will fall to hell if one never gets back around to making the CM scripts.

Re: Fucking Shell Scripts

#149
post #96

Earlier quoted context omitted.

"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.

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.

Re: Fucking Shell Scripts

#150

Earlier quoted context omitted.

No need for that. The configuration management of NixOS is baked right into the installation procedure. This makes it super simple to install a fresh machine completely from the configuration.nix file that you've developed over time.

Well, with an OpenVZ VPS, the most common variety these days, you'd have to have it offered by the provider.

Ahh, I would never use a VPS that didn't let me use my own OS install image.
Post reply on HN