4 ms·

> No, it's not. Then come up with something better. It will need the same or better ease-of-use for non-programmers, should function as a shell (so that their

by _jal 6y ago

> No, it's not. Then come up with something better. It will need the same or better ease-of-use for non-programmers, should function as a shell (so that their everyday use also teaches them scripting), with the same flexibility that lets people who don't care about typing or other fancy programmer stuff and just need to get work done. If your first instinct is to say "python", you don't understand the problem.

linuxftw 6y ago
While I agree with the sentiment that bash is not the solution for an ansible-like thing, I also agree with what you're saying. I consider myself an accomplished system engineer and software developer. I use bash all the time. Not writing bash scripts is like saying not to use the terminal, it's just cacophony.
q3k 6y ago
You are misunderstanding or misrepresenting what I said. If it wasn't obvious, I meant that bash scripting is not okay _for this sort of complex work/projects_.
- rejatak 6y ago
  Hello
- _jal 6y ago
  I fail how to see how I could be doing either. "[W]e need to stop it with the stringly-typed, footgun-filled madness that is bash scripting" is pretty categorical.
- scrooched_moose 6y ago
  On paper I agree with you, but that has not been our experience in practice. Bash "just works" with some very well understood limitations. Every one of these "better" solutions introduces 10x the complexity with 10x the limitations (always undocumented). After spending dozens of hours configuring them thanks to terrible documentation, generally taking multiple support tickets (if there's anyone to talk to at all), we get it working. Then, after using it for a period of time, they fall flat on their face in far worse ways than bash. Granted I'm only managing hundreds of servers, not thousands or more, but more often than not a for i in {000..199}; do ssh machine$i "some command"; done is more reliable, with better error handling, than all of the other solutions. Edit: As long as linux/unix maintains the "everything is a (plaintext) file" approach, I have trouble picturing a better solution than text/string based interface like Bash. You can build more front-end complexity on top of it, but you're always going to end up back in the same place.
  - notyourday 6y ago
    > Granted I'm only managing hundreds of servers, not thousands or more, but more often than not a > for i in {000..199}; do ssh machine$i "some command"; done is more reliable, with better error handling, than all of the other solutions. This is absolutely not the case: From the top of my head: there is a network error that hits while running this against 5% of machines. What is the state of those servers? If one is managing more than a few machines, one should absolutely use something like Puppet/Ansible/Salt/Chef with a repo to ensure that nothing is ever lost.
    - scrooched_moose 6y ago
      And all of those tools (at least the ones I've looked at) use SSH internally as well and are just as susceptible to network errors, except they tend to fail with less feedback than the raw ssh command. I never take it on blind faith either: for i in {000..199}; do ssh machine$i "echo new_setting > /file"; done for i in {000..199}; do ssh machine$i "grep new_setting /file"; done for i in {000..199}; do ssh machine$i "reload service"; done for i in {000..199}; do ssh machine$i "verify reload"; done As I was taught "never make a change without verifying it". All changes are documented as well.
      - notyourday 6y ago
        > SSH internally as well and are just as susceptible to network errors, except they tend to fail with less feedback than the raw ssh command. Maybe some. Puppet, for example, fetches a manifest and applies it on the server. Failure to apply a manifest triggers re-running the manifest. In small installations it will be asking puppetmater(s). Large installation run masterless, where they fetch the repo and run it. I would be highly surprised if Ansible did not have this mode even if it is not a popular way of doing it. > for i in {000..199}; do ssh machine$i "echo new_setting > /file"; done > for i in {000..199}; do ssh machine$i "grep new_setting > /file"; done > for i in {000..199}; do ssh machine$i "reload service"; done > for i in {000..199}; do ssh machine$i "verify reload"; done You are running this sequentially and by hand?! What happens when the server is dead and you need a new one? You provision it by hand and go through the stages to get it into the state where it can accept the same cattle command?
benbristow 6y ago
A Python script is (generally) easier to read, easier to write, easier to modify/maintain, easier to debug and easier to test. Bash programming is not easy and full of loads of gotchas. Useful for running multiple commands but when you start to need to do programming things like conditionals/loops/variables then using an actual programming language makes more sense.

by _jal 6y ago

linuxftw 6y ago

While I agree with the sentiment that bash is not the solution for an ansible-like thing, I also agree with what you're saying. I consider myself an accomplished system engineer and software developer. I use bash all the time. Not writing bash scripts is like saying not to use the terminal, it's just cacophony.

q3k 6y ago

You are misunderstanding or misrepresenting what I said. If it wasn't obvious, I meant that bash scripting is not okay _for this sort of complex work/projects_.

rejatak 6y ago
Hello
_jal 6y ago
I fail how to see how I could be doing either. "[W]e need to stop it with the stringly-typed, footgun-filled madness that is bash scripting" is pretty categorical.
scrooched_moose 6y ago
On paper I agree with you, but that has not been our experience in practice. Bash "just works" with some very well understood limitations. Every one of these "better" solutions introduces 10x the complexity with 10x the limitations (always undocumented). After spending dozens of hours configuring them thanks to terrible documentation, generally taking multiple support tickets (if there's anyone to talk to at all), we get it working. Then, after using it for a period of time, they fall flat on their face in far worse ways than bash. Granted I'm only managing hundreds of servers, not thousands or more, but more often than not a for i in {000..199}; do ssh machine$i "some command"; done is more reliable, with better error handling, than all of the other solutions. Edit: As long as linux/unix maintains the "everything is a (plaintext) file" approach, I have trouble picturing a better solution than text/string based interface like Bash. You can build more front-end complexity on top of it, but you're always going to end up back in the same place.
- notyourday 6y ago
  > Granted I'm only managing hundreds of servers, not thousands or more, but more often than not a > for i in {000..199}; do ssh machine$i "some command"; done is more reliable, with better error handling, than all of the other solutions. This is absolutely not the case: From the top of my head: there is a network error that hits while running this against 5% of machines. What is the state of those servers? If one is managing more than a few machines, one should absolutely use something like Puppet/Ansible/Salt/Chef with a repo to ensure that nothing is ever lost.
  - scrooched_moose 6y ago
    And all of those tools (at least the ones I've looked at) use SSH internally as well and are just as susceptible to network errors, except they tend to fail with less feedback than the raw ssh command. I never take it on blind faith either: for i in {000..199}; do ssh machine$i "echo new_setting > /file"; done for i in {000..199}; do ssh machine$i "grep new_setting /file"; done for i in {000..199}; do ssh machine$i "reload service"; done for i in {000..199}; do ssh machine$i "verify reload"; done As I was taught "never make a change without verifying it". All changes are documented as well.
    - notyourday 6y ago
      > SSH internally as well and are just as susceptible to network errors, except they tend to fail with less feedback than the raw ssh command. Maybe some. Puppet, for example, fetches a manifest and applies it on the server. Failure to apply a manifest triggers re-running the manifest. In small installations it will be asking puppetmater(s). Large installation run masterless, where they fetch the repo and run it. I would be highly surprised if Ansible did not have this mode even if it is not a popular way of doing it. > for i in {000..199}; do ssh machine$i "echo new_setting > /file"; done > for i in {000..199}; do ssh machine$i "grep new_setting > /file"; done > for i in {000..199}; do ssh machine$i "reload service"; done > for i in {000..199}; do ssh machine$i "verify reload"; done You are running this sequentially and by hand?! What happens when the server is dead and you need a new one? You provision it by hand and go through the stages to get it into the state where it can accept the same cattle command?

benbristow 6y ago

A Python script is (generally) easier to read, easier to write, easier to modify/maintain, easier to debug and easier to test. Bash programming is not easy and full of loads of gotchas. Useful for running multiple commands but when you start to need to do programming things like conditionals/loops/variables then using an actual programming language makes more sense.