[systemd-devel] vt220 default for serial console still relevant?

Tue Jul 14 21:15:12 UTC 2020

> About your other comments, systemd sits in user space and can query
(depend
> upon) terminfo.  Then, it should be able to support "whatever" terminfo
has
> defined.... which could include custom terminals by the way that an end
user has
> added.  And while all of that sounds incredibly ancient/old, I was on a
project
> post 2000 that had to do exactly that (of course, even that might sound
too old).

Interestingly enough, systemd's colors work even when TERM is set to vt220,
probably because it uses ansi escape codes regardless of the TERM setting.
I think there's probably lots of applications doing this except for ls in
coreutils which has an explicit list of terminals with color support
encoded in the dircolors configuration file.  If TERM isn't one of those,
you don't get colors. There's probably others that do this as well. I don't
think changing the default in systemd is a good idea since it might break
other stuff. I'm going to submit a mkosi PR instead that adds an option
that overrides serial-getty at ttyS0 with whatever terminal the user wants.
Colors won't work out of the box but at least it shouldn't be too hard to
find out how to get them to work when using mkosi.

Thanks for all the info as well. It's always fun to read how stuff was done
back in the early days.

Daan

On Tue, 14 Jul 2020 at 21:04, Christopher Cox <ccox at endlessnow.com> wrote:

> On 7/14/20 1:48 PM, Daan De Meyer wrote:
> > I just tried vt241 and didn't get colorized output in konsole. I looked
> around a
> > bit and it doesn't really seem supported at all by terminal emulators
> (or at
> > least none that I found). I also tried TERM=xterm-256color with 8
> different
> > terminal emulators and got colors with all of them. My workflow is
> simply "mkosi
> > qemu -nographic" (with a modified mkosi that adds console=ttyS0 and
> overrides
> > TERM for serial-getty at ttyS0 in the vm)." That connects my terminal
> emulator to
> > the serial console of the vm. I then execute "ls -l --color /" in the vm
> and get
> > colored output every time in whatever terminal emulator that I try.
> >
> > I'm probably missing something but I'm wondering what an example
> terminal
> > emulator would be where xterm-256color would not work at all (even st
> worked
> > perfectly and that is supposed to be pretty barebones afaik). Or is it
> just that
> > color is a commonly supported subset of xterm and stuff breaks down with
> other
> > escape codes instead? Or maybe qemu is doing some kind of translation
> that
> > magically makes every TERM setting work in whatever terminal emulator I
> try?
> > Apologies if this seems ignorant, I have no experience at all with this
> domain.
>
> So, some info (not necessarily direction).  Old guys like to talk...
>
> So, speaking of things of old, but not ancient old, when handling server
> equipment via serial, you normally do three things.  You route the BIOS
> (legacy)
> out the serial port, you send the kernel boot messages out the serial port
> and
> you establish a getty for login on the serial port.
>
> Just being honest, the "server world" decided everything was Microsoft
> Hyperterminal (up to Windows XP, what many considered to be "ansi", 80x25)
> during the PC revolution.
>
> So.. Windows doesn't come with Hyperterminal anymore, which makes sense
> since
> PCs in general don't have serial ports (apart from USB-serial dongles).
>
> So, can you, or should you adopt a serial console solution (ansi, 80x25)?
> IMHO,
> this is still interesting.  Especially in the Linux world.  Consider that
> network equipment still speaks serial for console, the concept (still,
> even
> though this in a old concept) of using, for example, ssh to serial console
> controllers for full out of band access might still be appealing.
>
> Why?  Well, for many reasons.  Cabling is much less (that is, less dense)
> as you
> can use flat velum for quite some distance for serial.  Since you're
> having to
> somehow deal with network devices anyway, by have all done serially, you
> have
> "one stop" shopping for out of band (more on this in a bit) console access.
>
> Bonus, no high cost of licensing, for example, iLO or iDrac ent.  But
> noting
> that you don't get virtual media with a serial console head solution
> either.
>
> But still, if running remote facilities and you need true out of band, and
> by
> that I mean the ability to reconfigure everything, including the network,
> it
> could be just the thing you need.
>
> But ssh? Network reconfigure?  That's not going to work.  Often times
> those same
> ssh to serial console devices have additional serial support usually with
> a
> option of a modem (yep... old school I know).  Back in the day, using a
> callback
> modem (added security) your infrastructure could reach out to you and you
> could
> indeed reconfigure the whole datacenter, soup to nuts.  Something lacking
> in
> general today.
>
> About your other comments, systemd sits in user space and can query
> (depend
> upon) terminfo.  Then, it should be able to support "whatever" terminfo
> has
> defined.... which could include custom terminals by the way that an end
> user has
> added.  And while all of that sounds incredibly ancient/old, I was on a
> project
> post 2000 that had to do exactly that (of course, even that might sound
> too old).
>
> Btw, as weird as it sounds, where I work today, and I'm not the network
> admin,
> the network admin has purchased a ssh to serial console controller with
> callback
> modem.  And he's in his early 30's.
>
> Btw, when I used to help manage an entire datacenter (same time as
> contract
> below) with those ssh to serial controllers, I just let the the linux TERM
> remain as it was mostly compatible with the ANSI from the host BIOS (at
> least
> I'm pretty sure).
>
> With regards to that post 2000 project, I was interfacing with an old
> accounting
> package called datamodes.  Company wanted a solution where by people at
> home
> could ssh into this character based gui, have all the key sequences (and I
> do
> mean all, every Fn, Ctrl, Shift, Alt combo) and have the ability to print
> to
> their local printers from that ssh terminal session.  All of this was
> doable
> with good old fashioned terminal handling from the ancient of days.  But I
> did
> have to craft my own terminfo entry.  Loosely based off the scoansi
> terminal
> (one of the most complete terminal definitions out there, but not totally
> complete).  The end users were already running a terminal emulator that
> had a
> SCO ansi mode.
>
> (even back then, datamodes had a "Windows" solution, but for the company I
> was
> contracting to, it was too expensive)
>
> >
> > Daan
> >
> > On Tue, 14 Jul 2020 at 18:22, Christopher Cox <ccox at endlessnow.com
> > <mailto:ccox at endlessnow.com>> wrote:
> >
> >     On 7/14/20 3:19 AM, Lennart Poettering wrote:
> >      > On Mo, 13.07.20 18:16, Christopher Cox (ccox at endlessnow.com
> >     <mailto:ccox at endlessnow.com>) wrote:
> >      >
> >      >>> No vt220 does not support colour. I used to work on one and it
> is
> >      >>> monochrome hardware.
> >      >>> Xterm and konsole support extensions beyond vt220 that add in
> the
> >     colour support.
> >      >>
> >      >> Not sure how much (offtopic) history we want to get into.  I
> used the VT240
> >      >> in my college graphics class.  The VT241 was the color variant.
> >      >>
> >      >> See: http://terminals-wiki.org/wiki/index.php/DEC_VT240
> >      >>
> >      >> I still meet programmers what hard code ansi sequences rather
> than querying
> >      >> termcap/terminfo.  You know what they say about those who
> "assume".
> >      >
> >      > Hmm, if vt241 is a bettre featured terminal type, and both xterm
> and
> >      > the Linux console a superset of it, and the terminal widely
> available
> >      > in termcaps and stuff we can certainly change our default TERM to
> be
> >      > vt241.
> >      >
> >      > Daan, if this all is the case, could you prep a PR?
> >
> >     I would think shooting for something low is actually good.  Let the
> individual
> >     configure for something "better".
> >
> >     I'm not sure I'm ready to say monochrome is obsolete.  There can be
> beauty in
> >     simplicity and function.  My preference, aim low, and allow easy
> configuration
> >     upward.  You could take the opposite stance of course, it's just
> that it could
> >     cause some frustration.
> >
> >     Just my opinion though.  I'm old and I think about a lot of things
> like
> >     terminals, "proxies" and callback modems... things of value, but
> most do not
> >     understand or care about anymore.
> >
> >
> >     _______________________________________________
> >     systemd-devel mailing list
> >     systemd-devel at lists.freedesktop.org <mailto:
> systemd-devel at lists.freedesktop.org>
> >     https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> >
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200714/8d65efc2/attachment.htm>