The original readme was written in 2016 and reflected my frustration with Ansible. It tries to explain the motivation/design philosophy, provide a full reference, and serve as a tutorial with examples - all at once, and as an effect it doesn't do any of the three too well.

Perhaps it can be split up for these three purposes: the readme can still serve as an introduction; an actual (installable!) man page would be good as a reference; and the examples could be elaborated on, with some actual real-world scripts I've accumulated over the past 6 years.

The general problems are avoiding boilerplate, bootstrapping/setting up the environment, abstracting over OS- or distro-specific details, or providing a library of common functions for other scripts to use.

It might be useful to allow executing a series of commands/scripts over the selected hosts, while retaining the remote working directory contents in between:

judo \
    -s scripts/bootstrap \
    -s scripts/common \
    -s scripts/install-python \
    -c "python --version" \
    some-hosts

Here, scripts/common can rely on scripts/bootstrap having been completed successfully, and scripts/install-python can include a function library exported by scripts/common, for example by running . scripts/common/$(uname) or so.

TODO elaborate

Hit C-c and got this, oops

panic: close of closed channel

goroutine 14 [running]:
main.(*Proc).CloseStdin(...)
	/Users/kamil/go/pkg/mod/github.com/rollcat/[email protected]/proc.go:49
main.(*Host).StartMaster.func1()
	/Users/kamil/go/pkg/mod/github.com/rollcat/[email protected]/transport.go:207 +0x25c
created by main.(*Host).StartMaster
	/Users/kamil/go/pkg/mod/github.com/rollcat/[email protected]/transport.go:188 +0x168

$ judo -v
0.6

Considering a better place to copy scripts ($HOME?).

It should be possible to specify some default env var values per each host, or group of hosts.

Currently env vars can be specified on the command line for each run:

judo -e ANSWER=42 -c 'echo $ANSWER' localhost

However this doesn't scale well if different host groups need different values:

judo -e ANSWER=42 -c 'echo $ANSWER' hitchhikers
judo -e ANSWER=47 -c 'echo $ANSWER' trekkies

In addition to all the error-prone repetition, it fails to take advantage of concurrent execution between the two groups.

Perhaps we could use an envdir-like scheme, where per-host and/or per-group directories can reside under an env hierarchy:

env/
    hitchhikers/
        ANSWER
    trekkies/
        ANSWER

$ cat env/hitchhikers/ANSWER
42

This would also require for hosts to actually track which groups they belong to; there is groups []string in host definition but it's currently not populated. It's also a bit of a trap, since a host can only know that it's a part of a group, if the group has been explicitly targeted on the command line.

I'm getting "there was no master to stop" messages logged when running the hello.sh Hello World.

Running: [ahost bhost]
ahost: HELLO FROM ahost!
ahost: there was no master to stop
bhost: HELLO FROM bhost!
bhost: there was no master to stop
Success: [bhost ahost]

Problem appears to be due to how Proc's IsAlive() is written:

// IsAlive reports whether the process is still running.
func (proc Proc) IsAlive() bool {
	return proc.cmd == nil
}

I think the equality test should be an inequality test?

If proc.cmd == nil, the process is not alive.

It appears that since v0.4 there were some useful updates to the handling of the SSH control master.

I love judo's approach and aesthetic. Targeting a specific SSH file is a welcome feature. It's not uncommon (in an Ansible project, for instance) to have an SSH config that's used for all operations. Being able to assert a configuration value like this for the project (e.g. ssh_config = ./ssh/config) would support a very flexible strategy for capturing host configuration, while keeping the command line invocations very lightweight. I propose a config file (like ansible.cnf) for two reasons:

1. this can be captured in version control, allowing a team to coordinate groups and ssh config relatively transparently
2. a configuration file would permit capturing other command line settings that are consistent for a given project

If I were to implement this, I would probably default the location to ./judo.conf, and override it with the value of JUDO_CONFIG in the environment, if present. Let me know if you would be open to a PR of this nature, or if this is the incorrect forum for feature requests like this. Thanks for this tool!

Currently the privilege escalation story is quite poor:

• We can pretend we don't need to be another user on the remote machine (limits usefulness).

• We can SSH in directly as root (bad idea, don't do this).

• We can SSH in as a regular user that has password-less sudo/doas, and ask the user either to re-exec the script if UID is not 0, or prefix each privileged command with sudo/doas.

  This is cumbersome, requires boilerplate, also not ideal if you prefer to have a sudo/doas password in interactive sessions (such as when you're managing a machine that also serves as a workstation).

  Some people would argue this is equivalent to SSH'ing in directly as root, but at least with remote syslog or chflags+securelevel you can get an audit trail. So this is what we currently recommend.

Some bad ideas to improve upon this:

• We could pretend to be typing into the sudo password prompt, which sounds very brittle and probably can do a lot of harm. It also opens the question of storing the passwords securely on the controller.
• We could auto-install a setuid helper on the remote host, in some "bootstrap phase". This breaks the promise of not requiring any clientside components, so perhaps it can be opt-in. Probably should be a separate project. Also sounds like a rootkit.

I stumbled across judo while writing basically the same thing as a shell script and I am very happy someone else did the work already, awesome job!

I have one question that, in my opinion, should either be addressed in the readme.md or added as a feature: How to handle different usernames on remote hosts?

Typically my hosts have a user account (root or something else) different from my personal user account on my local machine. This is guaranteed to be true when sharing devops tasks with team members, since we do not create an account for every team member on each host.

A workaround (if it is a workaround) has been to just put

[email protected]

into the group files, however this results in root@ being part of $HOSTNAME:

$ judo -c 'echo Hi from ${HOSTNAME}' all
Running: [[email protected]]
[email protected]: Hi from [email protected]
Success: [[email protected]]

I am aware that I could configure the user using an SSH config, but I would rather keep all the necessary connection info (sans private keys) in one place - is this something that could become part of judo?