4 ms·

Of course I'm aware of `for` loops in shell. But note, that your solution lacks: valid termination of commands by `CTRL-C`, aggregated progress indication, pas

Of course I'm aware of `for` loops in shell. But note, that your solution lacks: valid termination of commands by `CTRL-C`, aggregated progress indication, password authentication, various fail modes (like try to connect to all servers first), elevating privileges from user account to sudo (which is must have when you're logging in using your username, not root), no integration into other unix-way tools. Also, you will little bit stuck trying to run `tail -f` via xargs ssh. So, that's the reason for writing production-grade tool.

deleted 10y ago
[deleted]
jamiesonbecker 10y ago
It's clear that you've put a lot of thought into this! If I was going for production grade as opposed to a quick ad hoc job, I'd probably automate with a script to handle failures and send logs somewhere (thus wouldn't need or want control-C or progress indicators) ---- * valid termination of commands by `CTRL-C` Good point. I'd probably use pkill for that, if my ad hoc job went haywire :) ---- * aggregated progress indication You are correct, this is missing in my solution (nicely aggregated, anyway) -- but again if I was going to do this in production (i.e., automated), I'd probably not be doing it like this anyway.. I'd write a bash script, check status codes, timeouts, etc. For example, delivering sorted output via log files: for host in host1 host2 host3 do rsync -rpae ssh /my/directory/ $host:/remote/directory/ > rsync-$host.log 2>rsync-host.err & done and to syslog (hopefully a remote loghost) for host in host1 host2 host3 do rsync -rpae ssh /my/directory/ $host:/remote/directory/ | logger -t "myscript-$host" 2>&1 & done (note: --tag parameters for logger vary between RHEL and Debian-based distributions.. see the man page for specifics.) ---- * password authentication Please never do that. We don't even provide that as an option at Userify (https://userify.com https://userify.com, SSH key management). SSH is one of the few places where passwords are completely obsolete. ---- * various fail modes (like try to connect to all servers first) That seems like a simple thing to accomplish; are you saying orgalog connects to all servers first before connecting to all servers again? ---- * elevating privileges from user account to sudo (which is must have when you're logging in using your username, not root) Sure, that's easy.. echo host1 host2 ... | xargs -d' ' -P2 -n1 -I{} ssh {} sudo uptime If that doesn't work for you, you're probably using a version of red hat with a broken sudoers file (which goes back nearly ten years!) but they're fixing it in the next release: https://bugzilla.redhat.com/show_bug.cgi?id=1020147 https://bugzilla.redhat.com/show_bug.cgi?id=1020147 In the meantime, just comment out the Defaults requiretty line to get the same fix. Also, for the tty-requiring solutions that you mention, SSH has a command-line switch already: ssh -t and/or ssh -tt. `man 1 ssh` for details. Userify configures sudo on remote systems, btw. (SSH key management, https://userify.com https://userify.com, blatant plug: CTO) ---- * no integration into other unix-way tools I don't quite understand what you are saying.. I'd suggest that it's completely integrated into other unix tools, because it uses them instead of inventing a monolithic framework.
- seletskiy 10y ago
  > That seems like a simple thing to accomplish; are you saying orgalog connects to all servers first before connecting to all servers again? orgalorg has two modes: either it will fail and do nothing if even one server fails; or it will skip all errors and continue to do whatever it can with the rest. It allows you to run orgalorg on all set of nodes, but specify different keys and access only subset of servers. > Please never do that [...] SSH is one of the few places where passwords are completely obsolete. You simply making declarative statement there without any underlying arguments. Please never do that. We have passwords as part of our computing infrastructures right now and there are lot of cases where you need to use passwords (e.g., legacy infrastructure). So, supporting valid way of vastly used authentication doesn't sound 'bad' for me. >> * elevating privileges from user account to sudo (which is must have when you're logging in using your username, not root) > Sure, that's easy.. I'm talking about rsync. Try to use non-root login whily syncing root-owned files. Orgalorg solves that trivially (just add `-x` flag and it's done). Of course, I'm aware that key-based authentication is way superior than password based. I'm trying using SSH keys whenever possible and have distributed solution for syncing them across all cluster (https://github.com/reconquest/shadowd https://github.com/reconquest/shadowd). I do not find GUI-based solutions to be productive in work, so I prefer to use dead simple tools which are fail-safe because of simplicity. Finally, > but again if I was going to do this in production (i.e., automated), I'd probably not be doing it like this anyway.. I'd write a bash script, check status codes, timeouts, etc. ... and you will write orgalorg in bash.
  - jamiesonbecker 10y ago
    >>>> * elevating privileges from user account to sudo (which is must have when you're logging in using your username, not root) > Sure, that's easy.. >> I'm talking about rsync. Try to use non-root login whily syncing root-owned files. Orgalorg solves that trivially (just add `-x` flag and it's done). Fair enough! FWIW, that's actually trivial with native rsync also: rsync --rsync-path="sudo rsync" (...) That calls rsync as 'sudo rsync' on the remote system.

deleted 10y ago

[deleted]

jamiesonbecker 10y ago

It's clear that you've put a lot of thought into this! If I was going for production grade as opposed to a quick ad hoc job, I'd probably automate with a script to handle failures and send logs somewhere (thus wouldn't need or want control-C or progress indicators) ---- * valid termination of commands by `CTRL-C` Good point. I'd probably use pkill for that, if my ad hoc job went haywire :) ---- * aggregated progress indication You are correct, this is missing in my solution (nicely aggregated, anyway) -- but again if I was going to do this in production (i.e., automated), I'd probably not be doing it like this anyway.. I'd write a bash script, check status codes, timeouts, etc. For example, delivering sorted output via log files: for host in host1 host2 host3 do rsync -rpae ssh /my/directory/ $host:/remote/directory/ > rsync-$host.log 2>rsync-host.err & done and to syslog (hopefully a remote loghost) for host in host1 host2 host3 do rsync -rpae ssh /my/directory/ $host:/remote/directory/ | logger -t "myscript-$host" 2>&1 & done (note: --tag parameters for logger vary between RHEL and Debian-based distributions.. see the man page for specifics.) ---- * password authentication Please never do that. We don't even provide that as an option at Userify (https://userify.com https://userify.com, SSH key management). SSH is one of the few places where passwords are completely obsolete. ---- * various fail modes (like try to connect to all servers first) That seems like a simple thing to accomplish; are you saying orgalog connects to all servers first before connecting to all servers again? ---- * elevating privileges from user account to sudo (which is must have when you're logging in using your username, not root) Sure, that's easy.. echo host1 host2 ... | xargs -d' ' -P2 -n1 -I{} ssh {} sudo uptime If that doesn't work for you, you're probably using a version of red hat with a broken sudoers file (which goes back nearly ten years!) but they're fixing it in the next release: https://bugzilla.redhat.com/show_bug.cgi?id=1020147 https://bugzilla.redhat.com/show_bug.cgi?id=1020147 In the meantime, just comment out the Defaults requiretty line to get the same fix. Also, for the tty-requiring solutions that you mention, SSH has a command-line switch already: ssh -t and/or ssh -tt. `man 1 ssh` for details. Userify configures sudo on remote systems, btw. (SSH key management, https://userify.com https://userify.com, blatant plug: CTO) ---- * no integration into other unix-way tools I don't quite understand what you are saying.. I'd suggest that it's completely integrated into other unix tools, because it uses them instead of inventing a monolithic framework.

seletskiy 10y ago
> That seems like a simple thing to accomplish; are you saying orgalog connects to all servers first before connecting to all servers again? orgalorg has two modes: either it will fail and do nothing if even one server fails; or it will skip all errors and continue to do whatever it can with the rest. It allows you to run orgalorg on all set of nodes, but specify different keys and access only subset of servers. > Please never do that [...] SSH is one of the few places where passwords are completely obsolete. You simply making declarative statement there without any underlying arguments. Please never do that. We have passwords as part of our computing infrastructures right now and there are lot of cases where you need to use passwords (e.g., legacy infrastructure). So, supporting valid way of vastly used authentication doesn't sound 'bad' for me. >> * elevating privileges from user account to sudo (which is must have when you're logging in using your username, not root) > Sure, that's easy.. I'm talking about rsync. Try to use non-root login whily syncing root-owned files. Orgalorg solves that trivially (just add `-x` flag and it's done). Of course, I'm aware that key-based authentication is way superior than password based. I'm trying using SSH keys whenever possible and have distributed solution for syncing them across all cluster (https://github.com/reconquest/shadowd https://github.com/reconquest/shadowd). I do not find GUI-based solutions to be productive in work, so I prefer to use dead simple tools which are fail-safe because of simplicity. Finally, > but again if I was going to do this in production (i.e., automated), I'd probably not be doing it like this anyway.. I'd write a bash script, check status codes, timeouts, etc. ... and you will write orgalorg in bash.
- jamiesonbecker 10y ago
  >>>> * elevating privileges from user account to sudo (which is must have when you're logging in using your username, not root) > Sure, that's easy.. >> I'm talking about rsync. Try to use non-root login whily syncing root-owned files. Orgalorg solves that trivially (just add `-x` flag and it's done). Fair enough! FWIW, that's actually trivial with native rsync also: rsync --rsync-path="sudo rsync" (...) That calls rsync as 'sudo rsync' on the remote system.