Re: [Netconsole-devel] status?

[Jim G. <ga...@ll...>]

Thanks,

I need to go read your archives, but I will toss out a few points that come 
to mind:

Sorry if my point#1 was confusing - I just want to be able to use this stuff
over networks that are not necessarily IP, such as CAN (control area network
used on the Meiko CS/2 for consoles), RS485, whatever.  Maybe I can make them 
look like UDP, but that sounds ugly.

On the architecture, it seems to me like the netcon server approach creates
a single point of failure where there doesn't need to be one.  The way
I did the elan consoles was I made a range of elancon tty "callout devices"
which can be virtually connected to the elancon tty console device on any 
node via an ioctl.  The client user-space software then just becomes minicom
with support for some new tty ioctls (because the connected callout device
looks just like /dev/ttyS0), and it is fully peer-to-peer.

For logging, one could preserve this peer-to-peer architecture and implement
a separate read-only connect for the logging daemon so it could concurrently
capture console output while console sessions come and go.  Support for
redundant logging servers could even be added.

Jim

On Wed, 21 Feb 2001, H. Peter Anvin wrote:

> 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
> 
> _______________________________________________
> Netconsole-devel mailing list
> Net...@li...
> http://lists.sourceforge.net/lists/listinfo/netconsole-devel
>