Suggestion to make remote recovery easier

[Justin M. Wray]

I see no reason why we can't (even with C) come up with a universal package, that other distros can use.  (Most programs are C, the diffrence is normally packaging).

But if we can complete this is shell code, there is the benifit of an expert being able to quickly change the code, without needing to recompile, etc.

Let me know how the dash adventure turns out.  We can then go from there.

Thanks,
Justin M. Wray

Sent via BlackBerry by AT&T

-----Original Message-----
From: Andrew Sayers <andrew-ubuntu-devel at pileofstuff.org>

Date: Wed, 07 May 2008 20:07:13 
To:ubuntu-devel-discuss at lists.ubuntu.com
Subject: Re: Suggestion to make remote recovery easier


We're certainly getting there!

I haven't yet given up hope of doing this with a shell script
(evidentiary question again).  The benefit of a shell script is that it
leaves open the possibility of packaging a "lite" version of the program
as a single architecture-neutral file, so that we can support users of
other unixoid systems that can download a script.

The reason I went for numbered rankings was that it makes it easy to
compare two modules that don't know anything about each other.  If every
module needs a greater than/less than function that knows about every
other module, that makes O(n^2) work for us every time we want to add a
new module.  Or more precisely, O(n^2) work for some poor expert we'll
never meet that happens to need a particular module for his special
case.  On the other hand, if you have a non-numeric solution with linear
complexity, I always like being proved wrong about these things :)

The choice of interface module needs to be made before the choice of
lower-level module, because not all interfaces have the same
requirements.  For example, VNC needs a TCP socket, which has to be
passed in the parameters to SSH.

Finally, I agree that a GUI would be a good default choice here,
although it needs to be written in such a way that the ncurses/plaintext
fallback looks quite natural to the user when everything goes wrong.
However, I don't really do GUI programming, so it's not something I
would be able to do myself.

I'm now going to download dash and see whether I can fight my way out of
that little box.  If not, C it is.

	- Andrew

Justin M. Wray wrote:
> I agree with your generalization, and ordering.  It provides fault tolerance, security, and usability.  Making the entire process esasier (the main goal of this project).
> 
> I am unsure if I feel adding a numeric value to each option is needed, when simple programming conditions can handle the tasks.  I think the numbers (bids) adds some uneeded complexity/confusion.
> 
> The robustness and power of the solution we are now talking about exceeds the power of simple shell scripts and code hacks, thus needing a higher level language.  But I personally see this as a good thing (speed, security, etc).
> 
> I think it would be best to go through each option as you have them listed, and try them, once.  If it works use it, if not move on.  Only prompt the user if we get to an insecure option.  But at the same time I think the "helpless user" should have the ability to over-ride the option, or the "helper" over-ride the option (with approval from the helpless) at start.
> 
> A GUI front-end would le such choices be easily made.  And an expert can easily tell the "helpless" to type --telnet at the end of the command.
> 
> One more note, if we do use something like 'c' we could easily add a socket into the app itself.  So we would have the following options, in said order:
> 
> 1) SSH
> 2) bash->socat->cryptcat
> 3) bash->socat->netcat
> 4) bash->socat
> 5) telnet
> 6) bash->socket
> 
> (I've changed the order around a bit, to what I think would more secure and sound.)
> 
> And after connection, having the following recovery options:
> 
> 1) A VNC-based GUI
> 2) An X-based GUI (for e.g. broken video cards)
> 3) A screen-based TUI (for those of us that love screen)
> 4) A pty-based TUI (so that editors like vi work)
> 5) A pipe-based TUI (for dire emergencies)
> 6) A non-interactive mechanism for swapping keys 
> 7) Custom command
> 
> (Which should have been selected when the recovery-command was first run.)
> 
> It seems like we are on track, what do you think?
> 
> Thanks,
> Justin M. Wray
> 
> Sent via BlackBerry by AT&T

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss at lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss