Skip to content

cdba: Add option to run cdba-server locally without ssh and without timeout #85

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Feb 21, 2025

Conversation

stephan-gh
Copy link
Contributor

I use CDBA for booting remote boards, but also sometimes to boot locally attached boards. In that case, the SSH tunnel is pointless (and I don't have a SSH server set up on my laptop). Add an option to start the cdba-server locally without SSH if the host is omitted.

Also add an option to disable the total timeout (-t 0). I also sometimes use CDBA to power on a personal board remotely. Without specifying a boot.img, it boots into my installed Linux distro and then I access it via SSH. In that case, I don't want the board to power off while still being logged in.

See commit log for details.

Copy link
Collaborator

@lumag lumag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've mixed feelings regarding this PR. Some time ago I implemented cdba-power for exactly the same reason - to control local boards (e.g. for the sake of reflashing the rootfs). What prevents you from installing SSH server locally?

The <boot.img> option is optional in cdba. If omitted, cdba falls back to
falls back to running "fastboot continue" to boot the installed operating
system.
Use execlp() instead of execl() to search the PATH for the ssh binary. This
avoids problems in case the ssh binary is installed in a different path.
cdba is mainly intended for remote usage, but it also works well for
controlling devices that you just need occasionally and then directly
connect to your local laptop instead of a remote server.

Another use case is if you just use cdba to power up a standard distro on a
remote board and then SSH into it remotely. To avoid interruptions, it's
better to start cdba locally on the server in a tmux session. That way,
temporary disconnections do not power down the board.

From a protocol perspective, everything is transferred through STDIN and
STDOUT. It makes no difference if we have ssh piping the data to a remote
server, or if the data is directly passed to the cdba-server binary started
locally. The functionality works exactly the same.

Add an option for this in the cdba client. If the -h <host> option is
omitted, cdba-server is started locally.
If cdba is run with "-t 0", then disable the timeout completely and keep
running until manually interrupted. This is useful for non-shared boards,
e.g. when cdba is just used to power up the board remotely and you then SSH
into a standard Linux distro installed on the board.
@stephan-gh
Copy link
Contributor Author

I've mixed feelings regarding this PR. Some time ago I implemented cdba-power for exactly the same reason - to control local boards (e.g. for the sake of reflashing the rootfs).

I'm also using cdba-power sometimes, but most of the time I still want to have the UART log, key combos and so on. With the ftdi_gpio-based debug boards it's hard to do anything without going through CDBA.

What prevents you from installing SSH server locally?

I could I guess, but to be honest I wouldn't want to. It's just overhead in this use case, a potential security hole without proper configuration, and you always need to unlock SSH keys etc. What are your concerns with launching cdba-server directly? It's quite elegant I think, since everything works exactly as for the remote case.

@lumag lumag enabled auto-merge February 21, 2025 17:22
@lumag lumag merged commit 5bade34 into linux-msm:master Feb 21, 2025
46 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants