Getting to Know GNOME

The GNOME desktop environment, created around the late 1990s, is very popular and found by default on Linux distributions such as CentOS and Ubuntu. Currently a large volunteer group that belongs to the GNOME Foundation maintains it. For more about the GNOME project, visit www.gnome.org.

GNOME 2 was a more traditional desktop user interface, and when GNOME 3 (now formally called GNOME Shell) was released in 2011, with its nontraditional interface, many users reacted strongly. This spurred a few GNOME project forks. However, over time and with a few changes, GNOME Shell gained ground. For those who still prefer the traditional GNOME 2 environment, the GNOME Classic desktop is available.

Figure 8.1 shows a GNOME Shell desktop environment on an Ubuntu distribution.

In Figure 8.1, notice the panel at the frame’s top, containing a clock and a system tray on the far right. The Activities button on the panel’s far left allows you to switch between windows and provides the Search bar. The favorites bar on the UI frame’s left side shows various application icons as well as a multi-dot icon, which is the Apps button. The Apps button displays various application icons that allow you to quickly access a desired program.

The best way to understand a graphical interface is try a desktop environment for yourself. However, to help you with memorizing the assorted components that make up these different desktops, we are providing tables. Some of the GNOME Shell’s various components are briefly described in Table 8.1.

An interesting feature of GNOME Shell is that the panel, which contains the system tray, is available on the Display Manager as well as within the GNOME Shell.

Probing KDE Plasma

The Kool Desktop Environment (KDE) got its start in 1996, with its first version released in 1998. Through time the name KDE was no longer just referring to a desktop environment, but instead it specified the project’s organization and the strong community that supported it. KDE had many additional software projects besides its famous desktop environment. Thus in 2009, KDE’s desktop environment was rebranded as KDE Plasma. For more about the KDE group, visit www.kde.org.

Figure 8.2 shows a KDE Plasma desktop environment on an openSUSE LEAP distribution.

In Figure 8.2, the panel is located at the primary UI frame’s bottom. This is a more traditional panel location used on older systems and one of the reasons KDE Plasma is known for being a good desktop environment for those who are new to Linux. On this panel, the system tray, which contains notifications, the time, and various other plasmoids (widgets), is located on the panel’s right side. The Application Menu, a launcher for various programs as well as containing the favorites bar, is on the panel’s far left side. Table 8.2 briefly describes some of the KDE Plasma components.

To help those users familiar with accessing files via folder icons, KDE Plasma offers a folder view. Folders appear in the default UI on the openSUSE Leap distribution in Figure 8.2. These icons on the primary desktop window allow you to launch the Dolphin file manager and jump straight to the directory named on the folder icon.

Considering Cinnamon

The Cinnamon desktop environment got its start in 2011, when many users reacted strongly to the release of GNOME 3 (now GNOME Shell). Developers of the Linux Mint distribution began creating Cinnamon as a fork of GNOME 3. It was officially “GNOME-free” as of late 2013. Cinnamon is still managed by the Mint development team, and you can find out more at their website, www.linuxmint.com.

Cinnamon, like KDE Plasma, is known for being a good UI for those who are new to Linux. Figure 8.3 shows a Cinnamon desktop environment on a Fedora Workstation distribution.

Notice the primary UI frame’s bottom panel on the right side. It has the system tray containing audio controls, the time, and various other widgets. The Menu, a launcher for various programs as well as containing the favorites bar, is on the panel’s far left. Note that the Cinnamon panel also contains icons for quick launching.

The Cinnamon desktop environment layout should be somewhat familiar because it is similar to the KDE Plasma default layout. They both have folder icons on the main UI windows. Table 8.3 briefly describes some of the Cinnamon components.

The Cinnamon Spices go beyond just applets and desklets for modifying your desktop environment. They also include themes and extensions that you can download and install to make your Cinnamon UI experience truly unique. The official Cinnamon Spices repository is at https://cinnamon-spices.linuxmint.com/.

Making Acquaintance with MATE

The MATE desktop environment also got its start in 2011, when GNOME 3 (now called GNOME Shell) was released. It was started by an Arch Linux distribution user in Argentina. Pronounced “ma-tay,” this desktop environment was officially released only two months after it was announced and was derived from GNOME 2. The desktop environment is available on a wide variety of Linux distributions, such as Arch Linux, Debian, Fedora, Ubuntu, Linux Mint, and so on.

If you’ve ever used the old GNOME 2 desktop environment, MATE will feel familiar. Figure 8.4 shows a MATE desktop environment on an Ubuntu Desktop distribution.

There are two panels in the MATE desktop environment: one is at the primary UI frame’s top, while the other is at its bottom. The system tray, which contains audio controls, the time, and various other widgets, is located on the top panel’s right side. The Applications, a menu-driven launcher for various programs, is on the top panel’s far-left side. Note that this top panel also contains icons for quick launching.

On the bottom panel of the MATE desktop environment, in the lower-left corner, is the Show Desktop Button icon. This is handy if you have several windows open in the main UI frame. Just click the Show Desktop Button, and all the windows currently open will be hidden to the lower panel. You can restore all the windows on the lower panel by clicking Show Desktop Button again. Table 8.4 briefly describes some of the MATE components.

You can add additional widgets to your MATE UI’s top panel. Just right-click the panel, and from the drop-down menu, select Add To Panel. This will open a window of applets you can install.

Understanding Unity

The Unity desktop environment got its name from the project’s goal, which was to provide a single UI experience for workstations, tablets, and mobile devices. The project was started by Canonical in 2010 and was the default desktop environment on Ubuntu distributions until 18.04 LTS. However, Unity is no longer being developed. It was announced in 2017 by Canonical that work would stop on the Unity desktop environment.

Even though Unity will eventually fade from our memory, you may still have some older Ubuntu systems supporting this desktop environment. Thus, it’s a good idea to be familiar with its configuration. Figure 8.5 shows Unity on an Ubuntu 14.04 LTS system.

There is a single panel in the Unity desktop environment, and it is at the primary UI frame’s top. The system tray is located on the right side of this panel. On the left side is a menu bar.

The favorites bar, called the Launcher, is located in a frame on the UI’s left side. At the Launcher’s top is a button called Dash. Clicking the Dash button displays all of your recently used files and applications. You can filter this display by clicking one of the window’s bottom buttons. These buttons are called lenses. At the top of the Dash display window is a search bar, which is similar to the search bar feature in GNOME Shell. Table 8.5 shows the basic components in a Unity UI.

Another sometimes confusing feature of the Unity desktop environment occurs when you open an application. You’ll see the common three buttons for application management: close, minimize, and restore. However, additional application menu features are available on the Unity UI’s top panel. To see them, you must hover your mouse over the top panel. In addition, if you restore an application that is already open, the application management buttons will move to the top panel.

Setting Up Accessibility

In a GUI environment, accessibility deals with a user’s ability to use the desktop environment. While the default desktop environment provided by a Linux distribution works for many people, accessibility settings accommodate all potential users. This includes individuals who may have vision impairment, challenges using the mouse, finger movement issues, and so on. It’s important to know the desktop environment configurations concerning these accommodations so that you can help to provide access for all.

Each desktop environment will provide slightly different methods for configuring accessibility. But most settings can be accomplished through desktop environment control panels, such as the Universal Access panel in GNOME Shell settings.

Figure 8.6 shows the Universal Access menu opened from the UI top panel. You can find more accessibility settings in the access control panel by searching for “universal access” in the GNOME Shell’s search feature.

For users with serious visual impairments or just poor eyesight, several accessibility settings may help. Table 8.6 describes the more common visual impairment settings.

If a blind user has access to a braille display, you can install the brltty package, which is available in most Linux distribution’s repositories. The BRLTTY operates as a Linux daemon and provides console (text mode) access via a braille display. You can find out more about this software at its official headquarters, http://mielke.cc/brltty/. Be aware that you can also use the Orca screen reader with a refreshable Braille display.

For users with hand and/or finger impairments, several accessibility settings allow full functional system use. The more common settings are listing in Table 8.7.

AccessX was a program that provided many of the options in Table 8.7. Thus, you will often see it referred to in the accessibility control panels, such as in the Typing Assist (AccessX) option. One interesting AccessX setting is Enable By Keyboard, which allows you to turn on or off accessibility settings via keystrokes on the keyboard.

Figuring Out Wayland

Wayland is a replacement for the X11 display server (described later). It is designed to be simpler, more secure, and easier to develop and maintain. Wayland specifically defines the communication protocol between a display server and its various clients. However, Wayland is also an umbrella term that covers the compositor, the windows server, and the display server.

The Wayland protocol was initially released back in 2009, and it is now used by many current Linux desktop environments, such as GNOME Shell and KDE Plasma. If you really want to dig down into Wayland, visit its website at https://wayland.freedesktop.org/.

The Wayland compositor is Weston, which provides a rather basic desktop experience. It was created as a Wayland compositor reference implementation, which is a compositor requirements example for developers who want to create their own Wayland compositor. Thus, Weston’s core focus is correctness and reliability.

Wayland’s compositor is swappable. In other words, you can use a different compositor if you need a more full-featured desktop experience. Several compositors are available for use with Wayland, including Arcan, Sway, Lipstick, and Clayland. However, you may not need to go out and get a Wayland compositor. Many desktop environments create their own Wayland compositors, which is typically embedded within their window manager. For example, Kwin and Mutter both fully handle Wayland compositor tasks.

If your UI is using Wayland but you are having GUI issues, you can try a few troubleshooting techniques. The following list steps through some basic approaches.

Try the GUI without Wayland. If your Linux distribution has multiple flavors of the desktop environment (with Wayland or with X11), log out of your GUI session and pick the desktop environment without Wayland. If your UI problems are resolved, then you know it has most likely something to do with Wayland.

If you do not have multiple flavors of the desktop environment and you are using the GNOME Shell user interface, turn off Wayland. Do this by using super user privileges and editing the /etc/gdm3/custom.conf file. Remove the # from the #WaylandEnable=false line and save the file. Reboot the system and log in to a GUI session and see if the problems are gone.

Check your system’s graphics card. If your system seems to be running fine under X11 but gets problematic when under Wayland, check your graphics card. Go to the graphics card vendor’s website and see if its drivers support Wayland. Many do, but there are a few famous holdouts that shall go unnamed.

Use a different compositor. If you are using a desktop environment’s built-in compositor or one of the other compositors, try installing and using the Weston compositor package instead. Remember that Weston was built for reliability. If Weston is not in your distribution’s software repository, you can get it from https://github.com/wayland-project/Weston. This site also contains helpful documentation. If using Weston solves your GUI problem, then you have narrowed down the culprit.

Examining X11

The X Window System (X for short) has been around since the 1980s, so it has endured the test of time. On Linux until 2004, the dominant server implementing X was XFree86, when a licensing change occurred. This change caused many Linux distributions to switch to the X.Org foundation’s implementation of X.

The X.Org’s server implements the X Window System version 11. Thus, you will see a wide variety of names concerning the Linux X display server, such as X.org-X11, X, X11, X.Org Server, and so on. We’ll use either X or X11 in this chapter.

Currently X11 is being rapidly replaced by Wayland. Not only does Wayland provide better security, but it is far easier to maintain. There are many old and obscure options in the older X11 configuration. However, you still may have distributions using X11, so it is important to understand its basics.

The X11 primary configuration file is /etc/X11/xorg.conf, though it sometimes is stored in the /etc/ directory. Typically this file is no longer used. Instead, X11 creates a session configuration on the fly using runtime auto-detection of the hardware involved with each GUI’s session.

However, in some cases, auto-detect might not work properly and you need to make X11 configuration changes. In those cases, you can create the configuration file. To do this, shut down the X server, open a terminal emulator, and using super user privileges, generate the file via the Xorg -configure command. The file, named xorg.conf.new, will be in your local directory. Make any necessary tweaks, rename the file, move the file to its proper location, and restart the X server.

The xorg.conf file has several sections. Each section contains important configuration information as follows:

• Input Device: Configures the session’s keyboard and mouse
• Monitor: Sets the session’s monitor configuration
• Modes: Defines video modes
• Device: Configures the session’s video card(s)
• Screen: Sets the session’s screen resolution and color depth
• Module: Denotes any modules, which need to be loaded
• Files: Sets file path names, if needed, for fonts, modules, and keyboard layout files
• Server Flags: Configures global X server options
• Server Layout: Links together all the session’s input and output devices

Keep in mind that many desktop environments also provide dialog boxes in their UI, which allow you to configure your GUI X sessions. Most likely you will have little to no need to ever create or tweak the X11 configuration file. However, if you really want to dig into the X11 configuration file’s details, view its man page via the man 5 xorg.conf command.

If you need to troubleshoot X problems, two utilities can help. They are xdpyinfo and xwininfo. The xdpyinfo command provides information about the X server, including the different screen types available, the default communication parameter values, protocol extension information, and so on.

The xwininfo utility is focused on providing window information. If no options are given, an interactive utility asks you to click the window for which you desire statistics. The displayed stats include location information, the window’s dimensions (width and height), color map ID, and so on.

Although Wayland is replacing X as the default display server on many Linux systems, the X server will be around for a while. Thus, understanding them both is invaluable not only for certification purposes but to work effectively as well.

Viewing VNC

Virtual Network Computing (VNC^®) was developed by the Olivetti & Oracle Research Lab. It is multiplatform and employs the Remote Frame Buffer (RFB) protocol. This protocol allows a user on the client side to send GUI commands, such as mouse clicks, to the server. The server sends desktop frames back to the client’s monitor. RealVNC Ltd, which consists of the original VNC project team developers, now trademarks VNC.

The VNC server offers a GUI service at TCP port 5900 + n, where n equals the display number, usually 1 (port 5901). On the command line, you point the VNC client (called a viewer) to the VNC server’s hostname and TCP port. Alternatively, you can use the display number instead of the whole TCP port number. The client user is required to enter a predetermined password, which is for the VNC server, not Linux system authentication. Once the client user has authenticated with VNC, the user is served up the desktop environment’s display manager output so system authentication can take place.

The VNC server is flexible in that you can also use a Java-enabled web browser to access it. It provides that service at TCP port 5800 + n. HTML5 client web browsers are supported as well.

The following are positive benefits when using VNC:

• It has lots of flexibility in providing remote desktops.
• Desktops are available for multiple users.
• Both persistent and static desktops are available.
• It can provide desktops on an on-demand basis.
• A SSH tunnel can be employed via ssh or a client viewer command-line option to encrypt traffic.

The following are potential difficulties or concerns with VNC:

• The VNC server only handles mouse movements and keystrokes. It does not deal with file and audio transfer or printing services for the client.
• VNC, by default, does not provide traffic encryption, so you must employ another means of protection, such as tunneling through OpenSSH.
• The VNC server password is stored as plain text in a server file.

Besides VNC, there are alternatives that implement the VNC technology. A popular implementation of VNC for Linux is TigerVNC. The TigerVNC website is at https://tigervnc.org/. It also works on Windows, so you can connect to either a remote Linux or remote Windows system. For installing the server on a Linux system, use the tigervnc-server package name. You’ll need to perform some setup to prepare for clients and configure the server to provide the proper client requirements. There are several excellent tutorials on the Web. If you want to install the VNC client, just use the tigervnc package name.

Once you have the TigerVNC server installed, you control it with the vncserver and vncconfig commands. After making the appropriate server firewall modifications, the client can use the vncviewer command to connect to the server system and get a remote desktop. For example, a server (example.com) has been configured properly to serve a remote desktop to you at display number 1. You would access the desktop from another system via the vncviewer example.com:1 command. Figure 8.8 shows a TigerVNC connection from a Fedora system into a CentOS server, which is providing the user a GNOME Shell desktop environment.

When configuring your VNC server, be sure to employ OpenSSH port forwarding for the VNC server ports (covered later in this chapter.) Also configure your firewalls to allow traffic through port 22 (or whatever port number you are using for SSH traffic).

Grasping Xrdp

Xrdp is an alternative to VNC^®. It supports the Remote Desktop Protocol (RDP). It uses X11rdp or Xvnc to manage the GUI session.

Xrdp provides only the server-side of an RDP connection. It allows access from several RDP client implementations, such as rdesktop, FreeFDP, and Microsoft Remote Desktop Connection.

Xrdp comes systemd ready, so you can simply install, enable, and start the server using the systemctl commands. The package name on Linux is xrdp. Note that it may not be in your Linux distribution’s standard repositories.

After installing and starting the Xrdp server, adjust the firewall so that traffic can access the standard RDP port (TCP 3389). Now direct your RDP client choice to the server via its hostname or IP address and, if necessary, provide the client with the RDP port number.

Depending on your RDP client, you may be presented with a screen that denotes that the server is not trusted. If this is the server you just set up, you are fine to continue on. You will need to enter the Linux system’s user authentication information, but the login screen depends on the Xrdp client software you are using. An example of Xrdp in action is shown in Figure 8.9.

Figure 8.9 shows a connection from a Windows 10 system to a CentOS 7 Linux server, which is running the Xrdp server. Notice the output from the commands run in the terminal emulator. You can see that an X11 session is being deployed.

The following are positive benefits of using Xrdp:

• Xrdp uses RDP, which encrypts its traffic using TLS.
• A wide-variety of open-source RDP client software is available.
• You can connect to an already existing connection to provide a persistent desktop.
• Xrdp server handles mouse movements and keystrokes as well as audio transfers and mounting of local client drives on the remote system.

You can determine the various Xrdp configuration settings in the /etc/xrdp/xrdp.ini file. An important setting in this file is the security_layer directive. If set to negotiate, the default, the Xrdp server will negotiate with the client for the security method to use. There are three methods available:

• tls provides SSL (TLS 1.0) encryption for server authentication and data transfer. Be aware that this falls short of the encryption level needed for compliance with the Payment Card Industry (PCI) standards.
• negotiate sets the security method to be the highest the client can use. This is problematic if the connection is over a public network and the client must use the Standard RDP Security method.
• rdp sets the security method to standard RDP Security. This method is not safe from man-in-the-middle attacks.

Xrdp is fairly simple to use. Also, because so many Windows-oriented users are already familiar with Remote Desktop Connection, it typically does not take long to employ it in the office environment.

Exploring NX

The NX protocol, sometimes called NX technology, was created by NoMachine at www.nomachine.com around 2001. NX is another remote desktop sharing protocol. Its v3.5 core technology was open source and available under the GNU GPL2 license. Yet, when version 4 was released, NX became proprietary and closed source.

However, several open-source variations are available based upon the NX3 technology, including FreeNX and X2Go. Both are available on various Linux distributions but not necessarily in their default software repositories.

The following are positive benefits of using NX products:

• They provide excellent response times, even over low-bandwidth connections that have high-latency issues.
• They are faster than VNC-based products.
• They use OpenSSH tunneling by default, so traffic is encrypted.
• They support multiple simultaneous users through a single network port.

NX technology compresses the X11 data so that there is less data to send over the network, which improves response times. It also heavily employs caching data to provide an improved remote desktop experience.

Studying SPICE

Another interesting remote connection protocol is Simple Protocol for Independent Computing Environments (SPICE). Originally it was a closed-source product developed by Qumranet in 2007. However, Red Hat purchased Qumranet in 2008 and made SPICE open source. Its website is at www.spice-space.org.

SPICE (sometimes written as Spice) was developed to provide a good remote desktop product that would allow connections to your various virtual machines. Now, typically Spice is used primarily for providing connections with KVM virtual machines, moving into VNC’s territory.

Spice is platform independent and has some nice additional features as well:

• Spice’s client side uses multiple data socket connections, and you can have multiple clients.
• It delivers desktop experience speeds similar to a local connection.
• It consumes low amounts of CPU so you can use it with various servers that have multiple virtual machines and not adversely affect their performance.
• It allows high-quality video streaming.
• It provides live migration features, which means there are no connection interruptions if the virtual machine is being migrated to a new host.

While Spice has a single server implementation, it has several client implementations. These include remote-viewer and GNOME Boxes.

Another benefit of employing Spice is its strong security features. Transmitted data can either be sent plain text or have its traffic encrypted using TLS. Authentication between the Spice client and remote Spice server is implemented using Simple Authentication and Security Layer (SASL). This framework allows various authentication methods, as long as they are supported by SASL. Kerberos is a supported method.

If you are still dealing with X11, you can use Xspice. X.Org-created Xspice acts as a stand-alone Spice server as well as an X server.

Local

Local port forwarding sends traffic from the OpenSSH client on your system to the client’s OpenSSH server. The client’s OpenSSH server then forwards that traffic onto the destination server via a secured tunnel. In other words, the outbound traffic is rerouted to a different outbound port and tunneled via OpenSSH prior to leaving the client system.

To enact this on the command line, the -L option of the ssh command is used along with some additional arguments. Concerning remote desktops, the command has the following syntax:

ssh -L local-port:127.0.0.1:remote-port -Nf user@destination-host

In the command’s syntax are the following arguments:

• The destination-host is the computer you are logging into in order to use the desktop environment residing there.
• The user is the desktop host username you wish to use to authenticate so that the secure tunnel can be established.
• The local-port is the application’s port number you are employing on the client side.
• The remote-port is the port where the application is listening on the destination host.
• The 127.0.0.1 designates that you are using a local SSH port forwarding method.

Keep in mind that this command only establishes the tunnel. It does not provide a remote desktop connection. Therefore, there are two additional important command options: the -N option lets OpenSSH know that no remote terminal process is desired, while the -f option indicates that after the user is authenticated to the server, the ssh command should move into the background. These two options allow the user to issue additional commands, such as a remote desktop command, after the secured tunnel is established.

A practical example can be described using VNC^®. Recall that VNC uses the port 5900 + n, where n equals the display number. Thus, if on the remote system, your desktop is available at display 2, you can issue the following command to use SSH port forwarding and forward your local VNC port 5901 to the remote hosts’ port 5902:

ssh -L 5901:127.0.0.1:5902 -Nf D[email protected]

Once the tunnel is established, you can use the VNC remote desktop commands to access and view your desktop environment on the remote host. Keep in mind that you will need to perform some firewall configurations to allow access to the remote host.

Fortunately TigerVNC provides a much simpler method for local SSH port forwarding. Just employ the -via localhost option on the vncviewer command, as shown in Figure 8.10.

The -via localhost option used in conjunction with the vncviewer command forces the connection to use local SSH port forwarding. The last command argument is the destination host’s IPv4 address (you could also use a hostname), followed by a colon and the remote desktop’s display number (1). This is far easier to use and certainly requires fewer commands and options.

Remote

The remote SSH port forwarding method starts at the destination host (server), as opposed to the remote client. Therefore, on the destination host, you create the remote desktop secure tunnel via the following command syntax:

ssh -R local-port:127.0.0.1:remote-port -Nf user@client-host

There are some important differences in this command from the local method:

• The -R option is used instead of the -L option.
• The client-host is the remote client’s IP address or hostname (where you will issue the remote desktop commands).
• The local-port is the port number you use on the client-host with the vncviewer command.
• The remote-port is on the remote desktop server.

Tunneling Your X11 Connection

Another method that provides remote GUI interactions within a secure tunnel is X11 forwarding. X11 forwarding allows you to interact with various X11-based graphical utilities on a remote system through an encrypted network connection. This method is also enacted using the OpenSSH service.

First you need to check and see if X11 forwarding is permitted. This setting is in the OpenSSH configuration file, /etc/ssh/sshd_config. The directive X11Forwarding should be set to yes in the remote system’s configuration file. If the directive is set to no, then you must modify it to employ X11 forwarding. In Listing 8.3, a check is performed on the configuration file for this directive on a CentOS distribution.

Listing 8.3: Checking the AllowTCPForwarding directive

# grep "X11Forwarding yes" /etc/ssh/sshd_config
X11Forwarding yes
#

Once you have made any necessary configuration file modifications, the command to use is ssh -X user@remote-host. Similar to earlier ssh command uses, the user is the user account that resides on the remote-host system. The remote-host has the GUI utilities you wish to employ and can be designated via an IP address or a hostname. Figure 8.11 shows connecting from a remote Fedora client to a CentOS server and using a graphical utility on that server.

It’s always a good idea to check your IP address to ensure that you have successfully reached the remote system. In Figure 8.11, the ip addr show command is employed for this purpose. Once you have completed your work, just type in exit to log out of the X11 forwarding session.