The `screen` package is deprecated and not included in RHEL8.0.0.
Environment
- Red Hat Enterprise Linux (RHEL) 8
- Red Hat Enterprise Linux (RHEL) 7
- screen
Issue
- How to install the
screenpackage in RHEL8.0.0? - The
screenpackage is not available in RHEL8.
Resolution
After careful consideration, the decision was made to deprecate the screen package and instead recommend the tmux package. The screen utility has an old code base that is not easy to maintain and with little activity in the upstream community. The tmux package was viewed as having a better code base to maintain and build new features upon. Maintaining both within RHEL was becoming increasingly unfeasible when considering keeping up with CVE security errata, government security certifications, and similar requirements. For those concerned with DISA STIG requirements, tmux satisfies the requirement as an alternative to screen.
The screen utility was marked as deprecated with the release of RHEL 7.6 and was not included as part of RHEL 8.0.
In appreciation for the friction of change this imposes on RHEL users, work is underway on a transition guide to help users switch. For example, screen bindings for tmux are available, and a community supported version of screen exists in EPEL 8 repository1.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
28 Comments
What do you recommend for serial connections, since tmux does not support opening a serial device the way that screen did?
e.g.
I'm in the same situation; I used
screena lot to connect to various serial ports (switches, APC PDUs, UPS, etc...). It looks likeminicomis available in the RHEL8 repos as an alternative for us. I'm going to try and describe my initial setup, since it's a little different thanscreen.First,
minicomhas a system-wide default configuration defined in /etc/minirc.dfl. Changing the defaults and creating additional profiles/configurations which have unique ports, bitrates, stopbits, parity, etc... can be done interactively by runningminicom -sorminicom --setup. At a minimum, you probably want to make changes in the "Serial port setup" and "Modem and dialing" menus. N.B. The Init/Reset strings appear empty, but in fact have generated data in them. You may want to edit those values, and make sure they are empty. Finally, you can save your changes as the new defaults (Save setup as dfl) or as a named profile which can be loaded from the command-line viaminicom someConfigNameWhen you want to disconnect / exit from minicom you use the screen-like keyboard commands of Control-A + X. A list of all of the commands can be found in the man pages.
Update: I recently read a nice article about using "tio" from EPEL to access serial devices. https://opensource.com/article/20/5/tio-linux
Can we get an up-to-date version of tmux? RHEL7 uses tmux 1.8, but the latest version is 3.1 (https://github.com/tmux/tmux/wiki).
Red Hat should definitely provide a more up-to-date version. Meanwhile you can use repository I maintain with the current release, details here: https://anni.galaxy4.net/?page_id=39
so screen is outdated? but rhel 7 provides screen 4.1.0 (some time around 2013) and then tmux v1.8 (also 2013) How is tmux an improvement in security? The latest screen is 4.8 (2020) Sounds like there are too many "meetings" going on at Red Hat... How about updating your Satellite software packages?
Uninstalled tmux. Put back Screen.
Could not find the logging functionality that I could with screen -L, by using the tmux.Any recommendation ?
I don't know how to do it with tmux, but as a workaround, you can log everything that happens in a shell session with the 'script' command (part of util-linux package.) To use it, type "script myoutput.txt", and it'll return right away. Now, everything you run in the new shell will be logged to myoutput.txt. When you're done, type "exit" (or hit Ctrl-D) to leave the script shell. It's not exactly the same as screen's -L use case, but might work for what you need.
From the man page
man tmuxI found that running tmux with -vv will create an output log file. Does this work for you?And later you can review the output by looking at the tmux output log file. The log file is created with the process id (PID) that tmux ran as.
I use this method in .tmux.conf to override the default command when creating new windows, creating a separate log for each (naturally you should change ksh to your preferred shell):
Could not find the logging functionality that I used to do with ' screen -L' in the new tmux. Any recommendation?
I am frequently having to help colleagues, and find that "screen -x" is extremely useful. Takes a lot less effort, bandwidth, and time than using Webex or Gotomeeting. Does tmux have an equivalent feature? Thanks in advance.
(I am not oppsed to tmux, if I can achieve the same results. But, my interim solution was simply to download the most recent screen source (Feb 2020) and build it. There were zero problems...)
I also found
screen -xto be very useful. With tmux, I use this process instead. First create the tmux "session", then attach two or more clients to that session. Please note that I'm using the long names (e.g. new-session / attach-session) instead of the abbreviations (e.g. new / attach)Thank you. We will give it a try. Not quite as simple as the "-x" option, but I am happy there is a path here.
If you only plan on running a single
tmux, session then you can just use these two commands. The first command will create a new session. The second command will attach to the only available session.then
This is a weird and annoying change.
screenis a tiny component and a very popular tool. There is no conflict or issue with having both available, and removing it entirely, instead of just recommendingtmux, seems like a rather obnoxious decision. The fact that there's a "solution" posted here about it suggests that there are many customers (like me and most of my coworkers) who feel it should be included.Additionally, the "explanation" here is seriously weak tea. It's a bad attempt at "we dropped the package because it was 'too hard'", despite the fact that screen then showed up in EPEL and seems to be managed easily enough there. I have a lot of trouble believing that RH engineers aren't competent enough to manage screen.
The whole thing feels a lot like there's someone within Red Hat that doesn't like screen for some reason, and who has enough clout enforce their opinion, and they just decided they wanted to dump it from RHEL. The comments here, and in various other forums, make it quite clear that many customers disagree with this poor decision.
the most viable solution I found to tmux was to uninstall and put back Screen.
Yet another decision where the customers come last. Another bad move in a long series of bad moves on RedHat's part.
From Not Don Ortinau but Ralph Siegler:
tmux doesn't quite cut it, hilarious you picked stinky old version of tmux while saying screen codebase is old as excuse. Don't make decisions in a vacuum based on laziness, ask the paying customers!
Hear hear. Completely agree.
from Ralph Siegler not Don O.
been running with screen compiled from latest source, works wonderfully and is not ancient like Red Hat tmux.
Like you, I put 4.9.0 on mine from src, and removed tmux from the servers. Nobody where I work wants tmux.
Add me to the list of people who use screen ALOT. Never was a fan of tmux really.
I'm very confused by the statement in the article related to
screenbeing outdated:Let's see...
tmux 3.2abundled with RHEL9 was released on Jun 2021 whilescreen 4.8in EPEL9 was released on Feb 2020. As to latest releases they are one year apart.What gives?
That's a good question. What this article doesn't quite cover is the history. When it was first deprecated, the current release of screen was about two years old (4.6.2), and there wasn't clear activity/responses by maintainers regarding security issues. RedHat's response, for better or worse, was to just pivot to another project that offered similar functionality. This action sparked some activity with the project, so hopefully screen receives swift maintenance in the future.
We've adapted by using screen from EPEL. Thank you to the screen project and EPEL build maintainers!
After a careful review of RHEL 7.6 release notes and
screendeveloper mailing list I have to disagree on all points.Maybe the reason that there's no upstream activity is because it just works, maybe? You don't have to be constantly fiddling with something for it to be current and relevant. This is the most stupidest idea...especially in the middle of doing upgrades with all sorts of repos enabled and disabled, I now have neither screen not tmux! Thanks Red Hat.