61–70 of 71 posts
Could you explain what this line of code does? ssh -t user@example.com "$(
It's a weird way of writing ssh -t user@example.com /bin/bash That is, take the contents of the local file 'my-setup-script.sh' and run them as commands on example.com as the 'user' user (using SSH to authenticate the user & transport the commands).
Author claims all 90% of the time all they need is a single shell script. Then shows an example directory structure that mostly reminds me of Ansible. How is Welder different from Ansible, except bash vs python?
It also depends on Ruby and liquid templates. I am not sure how he can still claim it is "plain shell scripts"
http://tldp.org/LDP/abs/html/string-manipulation.html
See the section under Substring Replacement.
I completely agree with OP when Ansible is overkill for must cases, and even slower than a plain smart shell script.
For my solution, simple create a bash function:
function play ()
local remote=${2}
local script=${1}
local directory=$(dirname ${script})
tar cpf - ${directory}/ | ssh -t ${remote} "
tar xpf - -C /tmp &&
cd /tmp/${dirname} &&
bash /tmp/${script} &&
rm -rf /tmp/${dirname} "
}
play provision/bootstrap.sh ubuntu@10.0.0.1
I tried https://github.com/myplaceonline/posixcube and it has zero dependencies , just bash itself, and it is nice.
Honestly, I find ansible quite simple and straight forward. You don't have to use third party playbooks and using 'autoenv' I achieved a very straight forward, simple, dynamic setup.
Agree - not sure what the advantage is. I understand bootstrapping can be a minor irritation (and I dont have a great way to do it 100% auto) Dynamic inventory scripts + ansible-playbook -k -u root .... can do the same thing for bootstrapping. How is this an advantage over that?
- name: Bootstrap Ansible
hosts: all
gather_facts: False
tasks:
- name: Install Python 2
raw: test -e /usr/bin/python || (sudo apt -y update && sudo apt install -y python-minimal)Earlier quoted context omitted.
Ansible, Chef and Puppet are not languages. They are systems for managing the state of your server, during the whole lifetime of the server. You typically tell them "I want X to be in Y state" and they will take whatever actions to make that happen. Writing all that logic in a shell script is not particularly trivial. Of course, it's not all perfect and sometimes you have to resort to scripting-like approach, but the…
> You typically tell them "I want X to be in Y state" and they will take whatever actions to make that happen. I had so many problems with this, because not all possibilities are tested on all distributions on all architectures with all libc's and compiler combinations. Much is implicit compared to Nix where only the kernel is implicit.
With some sane level of standardization (lets say less than 6 combinations) it's easy enough to test all and fix up the discrepencies.
The more declaritive you are, and the less you assume about the environment, the better this will work.
Ie. if you need a package, always install it. On some distros it may be there by default, but you'll run into issues if it's not. The good thing about being declaritive is that there's no harm in checking.
Earlier quoted context omitted.
It's a weird way of writing ssh -t user@example.com /bin/bash That is, take the contents of the local file 'my-setup-script.sh' and run them as commands on example.com as the 'user' user (using SSH to authenticate the user & transport the commands).
But that might fail half-way through the file, and the other one is all or nothing, might just report "argument list too long".
Oh, while transferring!
ssh -t user@example.org bash I replaced a home grown, written by someone else, bash configuration management tool with Salt. The difference was huge.
Configuration management tools give you built-in logging, state checking, return codes, template libraries, and access to very mature models to access things like the AWS api.
I realize people don't like the steep learning curve, but there is a reason for it.
I used to bootstrap a lot of VMs in development using shell scripts [1]. At a certain point Bash scripts become unmanageable. Ansible, Chef, Puppet have stricter syntax, battle-tested modules, large communities, proper multi-OS support, etc. Investing time to learn any of those tools certainly pays off in the long run. Bash is great for a quick setup or a one-off instance. However it requires discipline for anything…
so it is the scripting language used by ansible, chef, puppet that imposes the required "discipline"? methinks each of these must in fact call the shell to get things done or least system(3). if they are calling execve then i would be more interested. i would also be interested in ansible, chef, puppet if i knew the scripting languages they are written in or wanted to learn them. but other languages interest me more.…
Earlier quoted context omitted.
so it is the scripting language used by ansible, chef, puppet that imposes the required "discipline"? methinks each of these must in fact call the shell to get things done or least system(3). if they are calling execve then i would be more interested. i would also be interested in ansible, chef, puppet if i knew the scripting languages they are written in or wanted to learn them. but other languages interest me more.…
> no "host" or "guest". no virtual server Much of the time, virtualization is just a way to give you control over the whole machine. If virtualization is thin, you don't lose a lot of performance. It shouldn't be hard to make a Xen-backed VM administration interface. Then you can upload your MirageOS images (that you have tested on your local Linux, because MirageOS does that too) and it would work. You can't get rid…
some configuration is fixed, static. to change it one needs to change the image. this is intentional. hobbyist user wants this.
bootloader is on removable media user sends to provider. user is not using any provider software. user is paying for dedicated server and internet connection. that is all.
do not use linux, mirageos. do not need to. have rump. user can make own xen guest kernels and xen host kernels. anyway, this is tangent, irrelevant. user does not need virtualization necessarily and in any case not virtualization provided by third party.
simple requirements: want dedicated bare metal server. want hardware and internet connection. do not need/want provider software. will pay more for this.