Re: [Netconsole-devel] status?

[H. P. A. <hp...@tr...>]

Jim Garlick wrote:
> 
> Sounds great.  So I take it a rough design has already been proposed?
> I'd like to get my $0.02 in on the requirements:
> 
> 1. well defined, simple interface for the communication layer so ethernets,
>    CAN (I maintain the Meiko CS/2 linux port), and cluster interconnects can
>    plug in.
> 
> 2. in my world of clusters, the network is assumed to be physically
>    secure and root on any node is equiv to root on any other node.  Ideally,
>    console mangement would be peer-to-peer and root-only within that space.
>    Outside of that space, access should be unavailable or sufficiently
>    protected.
> 
> 3. ability to "broadcast" to some set of consoles, i.e. you open a display
>    full of console windows talking to various nodes, and you have a separate
>    window where everything typed is sent to all those nodes' consoles
> 
> 4. ability to force a panic remotely, esp when node is half way hung, like
>    interrupts work but processes don't run
> 
> 5. console "stealing" protocol, i.e. joe has a console open and goes home,
>    sue should be able to tell joe has the console open and usurp it, causing
>    joe's session to report sue as the culprit.
> 
> 6. I already mentioned the problem of preserving connect state across a reboot.
> 
> I have 2-5 covered with my elan implementation, and I'd really like to get
> #1 defined so I can take advantage of anything this group comes up with.
> #6 is maybe a linuxbios issue - allocating bits of the system NVRAM.
> 
> I also have a minicom-like client program that manages the sessions (including
> "stealing" and broadcasts) and a separate console logging/session management
> system for serial consoles (lots of serial consoles connected to a digiboard).
> I had planned to put these all together in one package so you get the same
> interface no matter how the consoles are connected.
> 
> Do you think some collaboration is possible here?
> 

We have already covered most of this.  I have discussed #2 with crypto
people, and it pretty much boils down to the equivalent of spoofing DHCP;
in other words, until someone comes up with a security standard for DHCP,
it's pretty pointless to do anything in that vein.

I can't tell what the heck you're talking about in #1.  The idea is to
define a UDP protocol, so if you can use IP over it it should work.

#4 pretty much boils down to supporting SysRq/Stop-A/BREAK remotely. 
That's definitely planned.

We're planning a client/server/UI architecture, from a previous message:

--------------------

I'd like to see an architecture like this:


+-------------+
| Netcon user |
|    agent    |
+-------------+
       |
 TCP protocol
       |
+-------------+
|    Netcon   |
|    server   |
+-------------+
       |
Netcon protocol
       |
+-------------+
|    Netcon   |
|    client   |
+-------------+


The purpose of the netcon server is to provide session management and
(optionally) logging support.  The netcon user agent is what an admin
uses to plug into a session.  By isolating the UI from the session
management, we allow connecting and disconnecting to sessions.

Note that this is a useful capability in itself, and we may want to
consider (later, please!) the netcon server to talk to a serial port or
PTY session as well as to a netcon client.

Although the current assumption is that Netcon Protocol is a UDP
protocol, it will provide a logical bidirectional stream capability.

I really want to define a specific terminal emulation for this protocol. 
I definitely believe we do need more than a basic terminal, and having a
specific terminal emulation is key.  The only logical such terminal is
some ANSI/DEC VT subset.  Character set is yet another issue; I don't
think I have the guts to mandate UTF-8 over this stream.

-----------------

Your points #3 and #5 are defined by the Netcon server protocol. 
Basically what you're saying is that more than one user agent should be
able to connect to the same client session; this is indeed important.

We're addressing #6 at the protocol level; this is in fact *the* main
reason for going with a UDP protocol rather than using TCP.

It would be great if someone, such as yourself, would start coding up the
UI <-> server connection system.  In the meantime, we're hashing out the
protocol details.

One of the biggest open questions right now is whether or not Netcon
Protocol should be a stream-based protocol in both directions (simulating
a serial console) or a virtual screen protocol (simulating a CRT.)  Both
have advantages and disadvantages.

	-hpa

-- 
<hp...@tr...> at work, <hp...@zy...> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt