> Encryption doesn't buy anything if the data is predictable. And boot > messages are very predictable.
One can add randomisers and compress. > Also be very clear there are 2 cases. > 1) Having console over ethernet where the normal console assumptions > apply (i.e. you have a crossover cable plugged into your ethernet > port and plugged into a machine you trust) > > 2) Using a console over ethernet protocol in a normal network situation. > You have to lock it down at least to remove being able to send > any characters. And possibly disable it all together. We *were* talking about multicast and 1000s of machines. :) The important thing is that anything which copes with (2) copes with (1), so let's consider (2), but implement (1) as the first pass. > > But... this gets me thinking. Why just reproduce a TTY? The question was: why *just* a TTY? I didn't say NOT a TTY. > For quick debugging. For a trivial model that is generally useful. Absolutely, we're agreeing that something extra is needed - raw text alone isn't enough to convey the Vulcan Death Grips (Magic SysRq, Ctrl-Alt-Del and the like) that consoles have traditionally used for grabbing the system's attention. All I'm saying is embed the stdout in a protocol which allows for VDGs and other things rather than start with a text stream and then embed magic text. However, as long the protocol does both, I'm happy. I certainly agree that once a system is running DHCP, SNMP, ssh are the right tools for the job. Oh, and I'd like to be able to have "virtual consoles" in much the same way that the VGA device is organised to separate the output of different subsystems...
